Editor's Path Properties has 'Path length' but no 'path direction' visualization — user with a closed circular path can't tell which way the path goes (clockwise vs counter-clockwise) without zooming in #380

New issue

Closed

opened 2026-10-04 04:00:21 +00:00 by Mark · 2 comments

Mark commented

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

Owner

Finding

grep -rn 'pathDirection\|directionVisual' src/components/editor/ returns 0. The editor has no direction visualization.

This is similar to #329 but the implementation might differ.

A user with a closed path:

Doesn't know if the path goes clockwise or counter-clockwise
The direction matters for stitch appearance

The fix is a small arrow on the path's first segment.

Where

canvasRenderer: src/components/editor/canvasRenderer.ts (where the path is drawn)
No direction: grep -rn 'pathDirection' src/components/editor/ returns 0

Suggested fix shape

Render: on the first segment of each closed path, draw a small arrow:

if (p.isClosed) {
  // Draw arrow on first segment
  const start = p.nodes[0];
  const next = p.nodes[1];
  drawArrow(ctx, start, next);
}

Settings: a "Show path direction" toggle (per #329).
Use cases:

The user wants to verify the direction
The user is comparing two paths

Severity**

Low. The user can infer visually. Power users notice.

Discovered by

Gap analysis (2026-10-02) of editor path visualization.

#329 (open) — Direction indicator. Same surface.
#316 (open) — Reverse path. The action is the response.
Figma's path direction arrow is the parallel.

## Finding `grep -rn 'pathDirection\|directionVisual' src/components/editor/` returns 0. The editor has no direction visualization. This is similar to #329 but the implementation might differ. A user with a closed path: - Doesn't know if the path goes clockwise or counter-clockwise - The direction matters for stitch appearance The fix is a small arrow on the path's first segment. ## Where - canvasRenderer: `src/components/editor/canvasRenderer.ts` (where the path is drawn) - No direction: `grep -rn 'pathDirection' src/components/editor/` returns 0 ## Suggested fix shape 1. **Render**: on the first segment of each closed path, draw a small arrow: ```ts if (p.isClosed) { // Draw arrow on first segment const start = p.nodes[0]; const next = p.nodes[1]; drawArrow(ctx, start, next); } ``` 2. **Settings**: a "Show path direction" toggle (per #329). 3. **Use cases**: - The user wants to verify the direction - The user is comparing two paths ## Severity** Low. The user can infer visually. Power users notice. ## Discovered by Gap analysis (2026-10-02) of editor path visualization. ## Related** - #329 (open) — Direction indicator. Same surface. - #316 (open) — Reverse path. The action is the response. - Figma's path direction arrow is the parallel.

Mark added the

feature-request

triage-approved

labels

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

Mark commented

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

Author

Owner

Closing as duplicate of #329 — both filed as 'path direction visualization.' Same fix (a small arrow on the first segment of closed paths). Keeping #329 as the umbrella.

Mark closed this issue

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

Mark referenced this issue from a commit

2026-10-05 18:04:38 +00:00

feat(#380): closed-path direction arrow — always-on CW/CCW indicator

Mark commented

2026-10-05 18:04:53 +00:00

Author

Owner

Closed by feat(#380) — commit 33d3d14 on origin/main. Adds drawClosedPathDirectionArrow (canvasRenderer.ts) and wires it unconditionally into EditorCanvas.tsx, sitting on top of #329's per-segment overlay.

Visible behavior: every closed path now shows a single amber arrow on its first segment (nodes[0] → nodes[1]), pointing along the direction of travel — so a user can read CW vs CCW at a glance with no toggle to discover. Open paths are unaffected.

Visual stack (top → bottom of foreground): centerline → node handles → snap indicator → #380 amber arrow → #329 slate arrows → satin band. The amber rgba(180,83,9,0.95) and the larger 10×4px arrowhead read as a directional cue distinct from #329's slate text-pill arrows so a power user with both overlays on can tell them apart.

Tests: 8 new unit cases in canvasRenderer.test.ts pin the per-element contract (one arrow per closed path, zero on open, visible+node-count guards, empty-list + no-closed-path early-outs, rotate count, fillStyle); 3 new wiring cases in EditorCanvas.test.tsx pin the always-on contract (fires with showDirection on, off, and omitted). Total: 11 new cases.

Back-compat: path.closed already exists on StitchPath (since #209) — no new persisted fields. The marker is rendered on every visible closed path regardless of snapSettings.showDirection, so designs persisted before #329 (which omit showDirection) get the marker too.

Closed by feat(#380) — commit 33d3d14 on origin/main. Adds `drawClosedPathDirectionArrow` (canvasRenderer.ts) and wires it unconditionally into EditorCanvas.tsx, sitting on top of #329's per-segment overlay. **Visible behavior:** every closed path now shows a single amber arrow on its first segment (`nodes[0]` → `nodes[1]`), pointing along the direction of travel — so a user can read CW vs CCW at a glance with no toggle to discover. Open paths are unaffected. **Visual stack (top → bottom of foreground):** centerline → node handles → snap indicator → #380 amber arrow → #329 slate arrows → satin band. The amber `rgba(180,83,9,0.95)` and the larger 10×4px arrowhead read as a directional cue distinct from #329's slate text-pill arrows so a power user with both overlays on can tell them apart. **Tests:** 8 new unit cases in `canvasRenderer.test.ts` pin the per-element contract (one arrow per closed path, zero on open, visible+node-count guards, empty-list + no-closed-path early-outs, rotate count, fillStyle); 3 new wiring cases in `EditorCanvas.test.tsx` pin the always-on contract (fires with showDirection on, off, and omitted). Total: 11 new cases. **Back-compat:** `path.closed` already exists on StitchPath (since #209) — no new persisted fields. The marker is rendered on every visible closed path regardless of `snapSettings.showDirection`, so designs persisted before #329 (which omit `showDirection`) get the marker too.