Remember colors when switching assets in same type

[bluecarrot16]

Unless I'm missing something, when you pick a new hairstyle (for example), you have to pick a new color too. Could we allow switching the asset and keeping the color same (could open the color picker but default to same color selected)? I haven't wrapped my head around the new recoloring system to understand how feasible that is.

[jrconway3]

Remembering colors already exists, you can see in the preview and i'm pretty sure once the modal opens, that palette is the default color. But yeah the modal always opens and you must choose in the modal to select the item I think.

Originally I had it set that you had to click only the palette buttons to open the modal, but clicking anywhere else on the item selected the item without opening the modal using the current color (and if you already had a color chosen for the existing type, that color was kept). That was changed with feedback before it was released.

This is partly why I wanted additional feedback before releasing! :P

[jrconway3]

I'll create a preview PR to show off this in action and then share the link here for people to test it out. Maybe not today, but later this week.

[bluecarrot16]

IMO, ideally when you select a different asset of same type, it would immediately enable that asset with the same color selected, and also open the popover so you could optionally pick a different color.

[Gaurav0]

Proposed approach, matching @bluecarrot16's preferred UX:

when you select a different asset of same type, it would immediately enable that asset with the same color selected, and also open the popover so you could optionally pick a different color.

@jrconway3 already confirmed colors are remembered in the preview; the gap is that the modal opens without calling selectItem, so the character does not change until the user picks a color again.

Current vs desired

Today, both the preview row and swatch in sources/components/tree/ItemWithRecolors.ts only set showPaletteModal. selectItem runs only from the modal's onSelect.

getMultiRecolors / fixMissingRecolor in sources/state/palettes.ts already map the previous type's recolor onto the clicked item (including keys like red → all.lpcr.red). getPaletteOptions exposes that as selectedColors. The preview uses it; selection does not.

Desired click on an unselected item of a type that already has a selection:

1. Call selectItem with the mapped remembered color(s) so the asset enables immediately.
2. Still open the popover so the user can change color.

Click rules

Click	Behavior
Different asset, same type, remembered color maps	Select that asset with the mapped color(s), open popover
Different asset, same type, color does not map	Still select the new asset using the primary palette's first variant, open popover (click must not be a no-op)
This asset already selected	Open popover only (do not toggle off)
First pick of this type (nothing selected)	Open popover only, same as today — no invented color
Incompatible item	Do not call selectItem; still open popover if palette is ready (keeps current open-modal behavior)

Swatch clicks use the same apply rules; they only differ by which modal index opens (idx vs 0).

For multi-recolor items (e.g. hair + hair_tie on sheet_definitions/hair/xlong/hair_long_band.json), apply every slot that selectedColors already resolved, using the same selectItem(itemId, recolor, false, opt.type_name ? idx : null) signature as the existing modal onSelect. Apply index 0 first so parent selection exists before sub-slots.

Sequence: tests first, then implementation

Do not change production click handlers until the new specs exist and fail for the right reason (preview/swatch click opens the modal but does not call selectItem).

1. Write proposed tests

Extend tests/components/tree/ItemWithRecolors_spec.js (already registered in tests/tests.js). Add fixtures for two same-type recolor items plus a mapped-key pair and a multi-slot hair pair. Use the existing Testem pattern: click, then m.render(...) again so Mithril copies component state onto the new vnode.

Proposed cases (these should fail today except “already selected” / “first pick” / “incompatible”, which already match current modal-only behavior):

• Switch item A (red) → click B preview: state.selections.clothes.itemId === B, recolor === "red", .palette-modal present. Fails today.
• Switch via swatch click: same selection assert, modal opens. Fails today.
• Click already-selected preview: selection unchanged, modal opens. Passes today.
• First pick (no type selection): modal opens, state.selections unchanged. Passes today.
• Incompatible click: selection unchanged. Passes today.
• Switch when the remembered key needs mapping (reuse the red → all.lpcr.red pattern from tests/state/palettes_spec.js). Fails today.
• Multi-slot: remembered hair + hair_tie both move to the new item. Fails today.
• Switch when the remembered color does not map: new item selected with the primary palette's first variant, modal opens. Fails today.

Run the ItemWithRecolors browser specs and confirm the switch/mapping/multi-slot cases fail before touching ItemWithRecolors.ts.

2. Implement until those tests pass

In sources/components/tree/ItemWithRecolors.ts, add a small helper (module-level, not a new file) used by the ready-state preview and swatch onclick handlers:

function applyRememberedColorsOnSwitch(
  itemId: string,
  meta: ItemMerged,
  paletteOptions: PaletteOption[],
  selectedColors: Record<string, string>,
  isSelected: boolean,
  isCompatible: boolean,
): void

• Early-return when isSelected or !isCompatible.
• Early-return when state.selections[getSelectionGroup(itemId)] is missing (first pick).
• Otherwise loop paletteOptions: selectItem with selectedColors[group]; if the primary slot has no mapped color, fall back to meta.recolors[0].variants[0].
• Then set showPaletteModal as today.

Do not change PaletteSelectModal.ts or selectItem itself. Color mapping stays in existing getMultiRecolors / fixMissingRecolor.

3. Re-verify

• Re-run the ItemWithRecolors browser specs (all new cases pass; previously passing cases still pass)
• npm run type-check
• npm run lint on touched files

No sheet/palette definition or docs changes; this is click UX only.