Show the digitize response stats in the success toast (stitch count, color count, processing time) #127

New issue

Closed

opened 2026-10-03 02:49:16 +00:00 by Mark · 1 comment

Mark commented

2026-10-03 02:49:16 +00:00

Owner

Finding

The service returns DigitizeStats.totalStitches and DigitizeStats.colorCount in every digitize response. The client ignores both and derives its own counts from response.stitchObjects. The "Auto-digitize complete!" toast says "ready for editing" — it never tells the user the actual stitch count or color count of the design.

Where

Response type: src/lib/easystitch-client.ts:54-58
Consuming code: src/components/workspace/useWorkspace.ts:690-740 (the digitize handler)
Toast: same handler emits addToast('success', 'Auto-digitize complete! Design ready for editing.')

Suggested fix shape

After digitize() returns, surface the stats in the success toast:

Auto-digitize complete! 4,723 stitches in 5 colors.
For processingMs: append Took 3.2s. when processingMs > 1000 (skip sub-second noise).
Keep the existing derived counts in the state for downstream consumers (the stitch count is used for the right-panel "Object List" row labels, and we should not change that data flow).

The processing-time number is a useful UX signal — the user knows whether a slow digitize is normal for their image or a sign something went wrong.

Discovered by

Gap analysis (2026-10-02) of unreached service response data.

#114 (closed) — verified the digitize → export flow end-to-end. The verification didn't include checking whether the stats fields were actually surfaced.

## Finding The service returns `DigitizeStats.totalStitches` and `DigitizeStats.colorCount` in every digitize response. The client ignores both and derives its own counts from `response.stitchObjects`. The "Auto-digitize complete!" toast says "ready for editing" — it never tells the user the actual stitch count or color count of the design. ## Where - Response type: `src/lib/easystitch-client.ts:54-58` - Consuming code: `src/components/workspace/useWorkspace.ts:690-740` (the digitize handler) - Toast: same handler emits `addToast('success', 'Auto-digitize complete! Design ready for editing.')` ## Suggested fix shape After `digitize()` returns, surface the stats in the success toast: - `Auto-digitize complete! 4,723 stitches in 5 colors.` - For `processingMs`: append `Took 3.2s.` when `processingMs > 1000` (skip sub-second noise). - Keep the existing derived counts in the state for downstream consumers (the stitch count is used for the right-panel "Object List" row labels, and we should not change that data flow). The processing-time number is a useful UX signal — the user knows whether a slow digitize is normal for their image or a sign something went wrong. ## Discovered by Gap analysis (2026-10-02) of unreached service response data. ## Related - #114 (closed) — verified the digitize → export flow end-to-end. The verification didn't include checking whether the stats fields were actually surfaced.

Mark added the

feature-request

triage-approved

labels

2026-10-03 02:49:16 +00:00

Mark referenced this issue from a commit

2026-10-03 02:54:12 +00:00

feat(workspace): surface DigitizeStats in the success toast (#127)

Mark commented

2026-10-03 02:54:29 +00:00

Author

Owner

Fixed in c109a76 (pushed to main).

Toast now reads:
Auto-digitize complete! 4,723 stitches in 5 colors. Took 3.2s.

processingMs is omitted when <= 1000 so sub-second local digitizes do not print a meaningless "Took 0.1s.".

The derived stitch/color counts elsewhere in state (right-panel Object List row labels) are unchanged — the suggestion explicitly asked not to alter that data flow.

Closes #127.

Fixed in c109a76 (pushed to main). Toast now reads: Auto-digitize complete! 4,723 stitches in 5 colors. Took 3.2s. processingMs is omitted when <= 1000 so sub-second local digitizes do not print a meaningless "Took 0.1s.". The derived stitch/color counts elsewhere in state (right-panel Object List row labels) are unchanged — the suggestion explicitly asked not to alter that data flow. Closes #127.

Mark closed this issue

2026-10-03 02:54:32 +00:00

Mark referenced this issue

2026-10-03 04:24:12 +00:00

Fabric Type and Stabilizer dropdowns are wired in the UI but never reach the service — Help page claim "this affects underlay and density recommendations" is unmet #146

Mark referenced this issue

2026-10-03 17:33:47 +00:00

Editor header shows filename but no stitch count or path count — the user can't see totals without switching back to the Workspace #171