Editor uses hardcoded THREAD_COLORS (10 colors) instead of the thread library — custom colors added in Settings don't appear in Editor's thread picker #140

New issue

Closed

opened 2026-10-03 04:07:30 +00:00 by Mark · 1 comment

Mark commented

2026-10-03 04:07:30 +00:00

Owner

Finding

The Editor uses its own hardcoded THREAD_COLORS const (src/components/editor/constants.ts:3-7) with 10 colors. The thread library (post-#120, post-#126 work-in-progress) is the actual source of truth for thread colors in the Workspace, the Right Panel, the Bottom Thread Bar, and the Export Dialog.

The Editor's thread picker uses neither the thread library nor the service catalog. A user who adds a custom color in Settings will see it everywhere except the Editor. The Editor's EditorThreadBar.tsx (closed #94 was a fix for its disconnected rendering) reads from the hardcoded THREAD_COLORS array, not from useThreadLibrary().

Where

Hardcoded list: src/components/editor/constants.ts:3-7 (10 colors)
Editor consumer: src/components/editor/EditorThreadBar.tsx
Editor consumer: src/pages/Editor.tsx:111 (const paletteColor = library[threadIndex % library.length] ?? library[0]; — library here is the thread library parameter, but the fallback uses THREAD_COLORS and the index is bounded to THREAD_COLORS.length)

The Editor's thread picker shows 10 colors from the hardcoded const, ignoring both the user's custom library AND the service's 61-color catalog.

Suggested fix shape

Add a useThreadLibrary() call at the Editor page level (src/pages/Editor.tsx) and pass colors to EditorThreadBar and EditorRightPanel as a prop (matching the pattern that the Workspace uses post-round-5).
Replace the THREAD_COLORS import with the prop. The THREAD_COLORS const stays for demo data (the DEMO_PATHS array uses it) but production thread references use the library.
The Editor's currentThreadIndex (bumped by the user picking a color) needs to be reindexed against the live library length, not the hardcoded 10.

Severity

Medium. The Editor is the place a user spends the most time refining their design. Showing 10 hardcoded colors when they have 30 in their library is a real UX gap.

Discovered by

Gap analysis (2026-10-02) of editor / library integration.

#120 (closed) — replaced the hardcoded const with the CRUD library. Workspace and Bottom Thread Bar use it. Editor does not.
#126 (open) — service-sourced catalog. The Editor is the last holdout; this issue covers the editor-side wire-up.

## Finding The Editor uses its own hardcoded `THREAD_COLORS` const (`src/components/editor/constants.ts:3-7`) with 10 colors. The thread library (post-#120, post-#126 work-in-progress) is the actual source of truth for thread colors in the Workspace, the Right Panel, the Bottom Thread Bar, and the Export Dialog. **The Editor's thread picker uses neither the thread library nor the service catalog.** A user who adds a custom color in Settings will see it everywhere except the Editor. The Editor's `EditorThreadBar.tsx` (closed #94 was a fix for its disconnected rendering) reads from the hardcoded `THREAD_COLORS` array, not from `useThreadLibrary()`. ## Where - Hardcoded list: `src/components/editor/constants.ts:3-7` (10 colors) - Editor consumer: `src/components/editor/EditorThreadBar.tsx` - Editor consumer: `src/pages/Editor.tsx:111` (`const paletteColor = library[threadIndex % library.length] ?? library[0];` — `library` here is the thread library parameter, but the **fallback** uses `THREAD_COLORS` and the **index** is bounded to `THREAD_COLORS.length`) The Editor's thread picker shows 10 colors from the hardcoded const, ignoring both the user's custom library AND the service's 61-color catalog. ## Suggested fix shape 1. Add a `useThreadLibrary()` call at the Editor page level (`src/pages/Editor.tsx`) and pass `colors` to `EditorThreadBar` and `EditorRightPanel` as a prop (matching the pattern that the Workspace uses post-round-5). 2. Replace the `THREAD_COLORS` import with the prop. The `THREAD_COLORS` const stays for demo data (the `DEMO_PATHS` array uses it) but production thread references use the library. 3. The Editor's `currentThreadIndex` (bumped by the user picking a color) needs to be reindexed against the live library length, not the hardcoded 10. ## Severity Medium. The Editor is the place a user spends the most time refining their design. Showing 10 hardcoded colors when they have 30 in their library is a real UX gap. ## Discovered by Gap analysis (2026-10-02) of editor / library integration. ## Related - #120 (closed) — replaced the hardcoded const with the CRUD library. Workspace and Bottom Thread Bar use it. Editor does not. - #126 (open) — service-sourced catalog. The Editor is the last holdout; this issue covers the editor-side wire-up.

Mark added the

feature-request

triage-approved

labels

2026-10-03 04:07:30 +00:00

Mark referenced this issue from a commit

2026-10-03 05:55:42 +00:00

fix(#140): Editor uses live thread library for picker, swatch, and new paths

Mark commented

2026-10-03 05:56:17 +00:00

Author

Owner

Fixed in commit 09239cb on main (pushed).

The Editor's thread picker, current-thread swatch, and freshly-created path color now read from the live useThreadLibrary() palette instead of the hardcoded 10-color THREAD_COLORS const:

loadInitialPaths(library) maps snapshot hexes against the live library (with DEFAULT_THREAD_LIBRARY fallback) instead of indexing the hardcoded array.
pathsToStitchObjects / pathsToThreadStops clamp the per-path threadIndex against the live library length.
currentThreadColor preview and handleFinishPath's threadColor write both read from threadLibrary[clamped index], so the Editor's preview swatch and the new path's stored hex always match the user's library.
A new useEffect re-clamps currentThreadIndex whenever the library length changes (Settings add/remove), so removing a color never leaves the preview pointing past the end of the palette.

DEMO_PATHS still uses THREAD_COLORS for its demo seed.

Tests: typecheck clean, lint clean (no new warnings), Editor.test.tsx / EditorCanvas.test.tsx / EditorRightPanel.test.tsx all green (24/24).

Fixed in commit 09239cb on main (pushed). The Editor's thread picker, current-thread swatch, and freshly-created path color now read from the live `useThreadLibrary()` palette instead of the hardcoded 10-color `THREAD_COLORS` const: - `loadInitialPaths(library)` maps snapshot hexes against the live library (with `DEFAULT_THREAD_LIBRARY` fallback) instead of indexing the hardcoded array. - `pathsToStitchObjects` / `pathsToThreadStops` clamp the per-path `threadIndex` against the live library length. - `currentThreadColor` preview and `handleFinishPath`'s `threadColor` write both read from `threadLibrary[clamped index]`, so the Editor's preview swatch and the new path's stored hex always match the user's library. - A new `useEffect` re-clamps `currentThreadIndex` whenever the library length changes (Settings add/remove), so removing a color never leaves the preview pointing past the end of the palette. `DEMO_PATHS` still uses `THREAD_COLORS` for its demo seed. Tests: typecheck clean, lint clean (no new warnings), `Editor.test.tsx` / `EditorCanvas.test.tsx` / `EditorRightPanel.test.tsx` all green (24/24).

Mark closed this issue

2026-10-03 05:56:17 +00:00

Mark referenced this issue from a commit

2026-10-04 04:20:14 +00:00

fix(#217): Editor thread bar gets a '+ Add' affordance with a catalog popover