Editor's `handleSendToWorkspace` (per #207) also hardcodes `hoopSize: '4x4'`, `fabricType: 'medium'`, etc. — same bug as #238/#239 in a separate code path, the user's settings are not preserved when sending the design to the Workspace #252

New issue

Closed

opened 2026-10-04 03:35:44 +00:00 by Mark · 1 comment

Mark commented

2026-10-04 03:35:44 +00:00

Owner

Finding

src/pages/Editor.tsx's handleSendToWorkspace (per #207) at line 1148 also hardcodes designSettings:

const designSettings: DesignSettings = {
  fileName: filename,
  hoopSize: '4x4',          // hardcoded
  fabricType: 'medium',     // hardcoded
  stabilizer: 'cut-away',   // hardcoded
  machineProfile: 'brother-pr1050x',  // hardcoded
};

This is the same code smell as #238 and #239 but in a different code path. The "Open in Workspace" button (per #207) sends the editor's current paths to the workspace for re-digitization, with these hardcoded design settings.

A user who:

Edited a design intended for a 5x7 hoop
Clicks "Open in Workspace" to re-digitize
The workspace loads the design with hoopSize: '4x4'
The user has to re-set the hoop size in the workspace's right panel

Where

handleSendToWorkspace: src/pages/Editor.tsx:1148
Same literal '4x4' as #238 and #239
The design settings source: there's no useDesignSettings hook yet (per #238's suggested fix)

Suggested fix shape

Same as #238/#239: read the design settings from a shared source (a useDesignSettings hook, or a context, or local state in the editor's useState).

The hook is the right answer because BOTH handleSave AND handleSendToWorkspace need the same values. One source, two consumers.

// In a new useDesignSettings.ts
export function useDesignSettings() {
  const [settings, setSettings] = useState<DesignSettings>(() => 
    loadInitialDesignSettings() || DEFAULT_DESIGN_SETTINGS
  );
  return { settings, setSettings };
}

// In Editor.tsx
const { settings: designSettings } = useDesignSettings();
const handleSave = useCallback(() => {
  // ...use designSettings, not hardcoded
  const result = saveDesignToGallery({
    // ...
    designSettings,
  });
}, [..., designSettings]);

The right panel or Settings modal exposes the form to set designSettings. The hook persists to localStorage so the values survive a refresh.

Severity

Medium. Same as #238/#239. The user can re-set the values in the workspace after they land there.

Discovered by

Code review (2026-10-02) of handleSendToWorkspace.

#238 (open) — Editor hardcodes hoopSize. Same file, same hardcoded value.
#239 (open) — Editor hardcodes fabricType, stabilizer, machineProfile. Same file, sibling issue.
#207 (closed) — Open in Workspace. The button is wired; this issue is the design settings carried in the wire payload.

## Finding `src/pages/Editor.tsx`'s `handleSendToWorkspace` (per #207) at line 1148 also hardcodes `designSettings`: ```ts const designSettings: DesignSettings = { fileName: filename, hoopSize: '4x4', // hardcoded fabricType: 'medium', // hardcoded stabilizer: 'cut-away', // hardcoded machineProfile: 'brother-pr1050x', // hardcoded }; ``` This is the same code smell as #238 and #239 but in a different code path. The "Open in Workspace" button (per #207) sends the editor's current paths to the workspace for re-digitization, with these hardcoded design settings. A user who: - Edited a design intended for a 5x7 hoop - Clicks "Open in Workspace" to re-digitize - The workspace loads the design with `hoopSize: '4x4'` - The user has to re-set the hoop size in the workspace's right panel ## Where - `handleSendToWorkspace`: `src/pages/Editor.tsx:1148` - Same literal `'4x4'` as #238 and #239 - The design settings source: there's no `useDesignSettings` hook yet (per #238's suggested fix) ## Suggested fix shape Same as #238/#239: read the design settings from a shared source (a `useDesignSettings` hook, or a context, or local state in the editor's `useState`). The hook is the right answer because BOTH `handleSave` AND `handleSendToWorkspace` need the same values. One source, two consumers. ```ts // In a new useDesignSettings.ts export function useDesignSettings() { const [settings, setSettings] = useState<DesignSettings>(() => loadInitialDesignSettings() || DEFAULT_DESIGN_SETTINGS ); return { settings, setSettings }; } // In Editor.tsx const { settings: designSettings } = useDesignSettings(); const handleSave = useCallback(() => { // ...use designSettings, not hardcoded const result = saveDesignToGallery({ // ... designSettings, }); }, [..., designSettings]); ``` The right panel or Settings modal exposes the form to set `designSettings`. The hook persists to localStorage so the values survive a refresh. ## Severity Medium. Same as #238/#239. The user can re-set the values in the workspace after they land there. ## Discovered by Code review (2026-10-02) of `handleSendToWorkspace`. ## Related - #238 (open) — Editor hardcodes hoopSize. Same file, same hardcoded value. - #239 (open) — Editor hardcodes fabricType, stabilizer, machineProfile. Same file, sibling issue. - #207 (closed) — Open in Workspace. The button is wired; this issue is the design settings carried in the wire payload.

Mark added the

bug

triage-approved

labels

2026-10-04 03:35:44 +00:00

Mark referenced this issue from a commit

2026-10-04 09:49:06 +00:00

test(#252): pin that Editor's Open-in-Workspace bridge honours the user-selected design pickers

Mark commented

2026-10-04 10:00:00 +00:00

Author

Owner

Fixed by the sibling-hook reads that landed in commit ab05462 (fix #239). At HEAD, handleSendToWorkspace (src/pages/Editor.tsx, around line 1441) reads from designHoopSize / designFabricType / designStabilizer / designMachineProfile — the four editor picker hooks #238/#239 introduced — and threads them into the tc_load_design_snapshot envelope.

The issue body quotes an old line number (1148) where the function used to live when the literals were hardcoded; the file has shifted since #239, but the hook reads have been in place for the full #252 reporting window.

To pin this so a future refactor cannot silently revert to hardcoded literals, I added issue-252.test.tsx (commit 26fbe03) which exercises handleSendToWorkspace through the same picker-mocking harness issue-239 uses. Seven tests, all passing locally:

defaults match the pre-#239 literals (4x4 / medium / cut-away / brother-pr1050x)
each picker threads through the bridge envelope when set in isolation
all four user-selected values survive the round-trip when set together (the original repro)
navigate('/workspace') still fires after the bridge write

No production code change needed — closing.

Fixed by the sibling-hook reads that landed in commit ab05462 (fix #239). At HEAD, `handleSendToWorkspace` (src/pages/Editor.tsx, around line 1441) reads from `designHoopSize` / `designFabricType` / `designStabilizer` / `designMachineProfile` — the four editor picker hooks #238/#239 introduced — and threads them into the `tc_load_design_snapshot` envelope. The issue body quotes an old line number (1148) where the function used to live when the literals were hardcoded; the file has shifted since #239, but the hook reads have been in place for the full #252 reporting window. To pin this so a future refactor cannot silently revert to hardcoded literals, I added **issue-252.test.tsx** (commit 26fbe03) which exercises `handleSendToWorkspace` through the same picker-mocking harness issue-239 uses. Seven tests, all passing locally: - defaults match the pre-#239 literals (4x4 / medium / cut-away / brother-pr1050x) - each picker threads through the bridge envelope when set in isolation - all four user-selected values survive the round-trip when set together (the original repro) - `navigate('/workspace')` still fires after the bridge write No production code change needed — closing.

Mark closed this issue

2026-10-04 10:00:22 +00:00