[MerciHanrim]

v0.28.4 — starting and finishing a connection responds faster

While a connection or an end grip is dragged every node mounts its face handles, so the drop can choose a side, and when the drag ends it unmounts the unused ones — every node, in the same commit. Each node then measured its handles on its own: one React Flow updateNodeInternals call per node, each a store update run through every subscriber (the 63-node gacha banner Template has 848 handles mid-drag). Share note 58 holds the investigation, the four measured arms (main / batch the measurement / re-render only the handles / both) and Lumi's corrections to the method. Four commits: the change, the release, the wording after Lumi's review of the report and the measurement record, and a fix found in the code review (section 1b).

1. The change (66ad42b, src/components/nodes/faceBatch.ts, nodes.tsx)

• The first node whose layout effect sees the drag state change in a commit measures EVERY node in one updateNodeInternals call; the others skip.
• At the start at once: React applies the whole commit's DOM before any layout effect runs, so every node's new handles are in the DOM, nothing is painted, and React Flow's edges (a passive effect) have not caught up — the moment each node measured itself in before.
• At the end on the next animation frame (the end only removes handles), as a node's own removal is; the React Flow 008 order of fix(nodes): a connection moved to an unused face has its handle measured before it is drawn (React Flow 008) #356 is kept.
• A new drag cancels an end's measurement still waiting, so it never lands on the next drag.
• Every other change of a node's mounted faces (selection, keyboard focus, a document change) is measured by that node alone, as before. docs/edge-routing.md §ER17.1 states the rules.
• This is the measured arm "batch the measurement" with the batch moved into its own module; re-rendering only the handles added nothing measurable on its own, and both together 1–9 % over the batch alone, so the component split is not taken.

1b. The fix from the code review (6380755)

• Lumi's points for the code review: the state per canvas, and a waiting measurement on restart, document replacement and unmount. In my own review of the diff against them: the first version kept one module-wide flag "this drag is measured", cleared by an end a node reported. With every node gone during a drag (its insert undone with Ctrl+Z, or the node structure switched) no node reports the end, the flag stays on, and the next drag's start was taken as already measured — no node's faces measured, so a drop could not find an unused face. Reproduced in a unit test and an e2e before the fix.
• Now a drag also ends when React Flow's connection.inProgress goes false (a store subscription, one per canvas); the end seen by the store and by the nodes is one measurement.
• The state is each canvas's, keyed by the store's own getState. useStoreApi() gives every component its own { getState, setState, subscribe } wrapper, so a key on the wrapper gives every node its own state: a first attempt keyed that way merged nothing (counted: all 63 gacha nodes measured 61 times per start) and was about 3 times slower at a start and 6 times at a release than main; it was never committed, and a unit test now pins that the wrappers of one store are one canvas.
• Unchanged: a start measures every node at once, an end on the next frame, and a start cancels an end's frame that has not run. A frame is not cancelled when the canvas goes away: it runs, finds no domNode (React Flow resets its store on unmount) and measures nothing.
• Counted again after the fix: one measurement of every node per start and per release.

2. Measured (share note 58; production build, one machine, medians of eight drags, input event to the second animation-frame callback — a comparison measure, not the paint)

Gacha banner	main	this change
start, CPU × 1	100.9–116.7 ms	68.7–82.0 ms
release, CPU × 1	115.1–132.1 ms	77.1–88.2 ms
start, CPU × 4	795.1–848.8 ms	371.3–463.5 ms
release, CPU × 4	674.2–712.4 ms	279.7–365.8 ms

Ranges over the arm runs and the committed-code runs (four sittings in all). The fixed code (6380755) was timed once more against main in a fifth, faster sitting: gacha start 86.8–92.2 → 62.8–62.9 ms and release 85.3–87.6 → 61.6–64.4 ms at CPU × 1, 502.7–506.0 → 285.6–291.1 ms and 438.4–471.3 → 213.4–228.1 ms at × 4; Coffee not slower. Coffee roastery operations flow: not slower in any row. Counted in a separate diagnostic run (counters in scratch copies, never in a timing run): measurement calls per start / release 61–62 → 1; React Flow store updates in those windows 64–65 → 4 and 75–81 → 15 (React Flow's own updates remain). Face handles mid-drag 636 / 189 and after the release 80 / 13, as on main.

3. Tests

• src/components/nodes/faceBatch.test.ts (11): the requests of a drag's start are ONE measurement holding every node on the canvas, at once, also when they come in separate tasks; an end is one measurement on the next frame, whether React Flow or the nodes report it; a new drag cancels a waiting end; a drag whose end no node reported is over when React Flow ends it; the wrappers of one store are one canvas; two canvases apart; the nodes are the canvas's when it runs. It pins the measurement calls, not React Flow's store update count. The module-wide first version fails 6 of them, a per-task variant 3, the wrapper-keyed variant 1.
• e2e/connection-draw-faces.spec.ts (6), dev build (008 prints only there): one drag lands on an unused face of every node (React Flow's connectingto comes from its measured bounds; leaving one node out of the measurement → 4 of 5 fail); a drag released and started again in one task (before the end's frame) and five drags back to back, then a drop on a face — made on that face, ending on its handle, its line in the DOM on every frame, the faces back afterwards; a refused drawing (a repeat of a connection drawn the same way) then the next connection; Esc on an end grip drag then the next connection; every node gone during a drag (a module insert undone while dragging, then redone) and the next drag still measures every node (fails on the first version); no 008 in the console. In that last test a click on the empty pane after the redo did not clear the restored selection — not traced, left open — so the test clears it through the store.
• Esc: drawing a new connection has no Esc cancel (no handler in the app, none in React Flow); the end grip drag does, and that is what is tested.

4. Release (c287eb3, wording a792442)

• 0.28.4: .changes/draw-start-batch.json (user-facing), CHANGELOG v0.28.4, README Latest. Release date 2026-10-17, to be checked on the merge day.
• Three What's new lines in 18 languages (the validator asks for 3 to 5 per release), English and Korean in Lumi's words: starting to draw a connection responds faster, with a larger improvement in large diagrams; releasing a connection drag on the empty canvas also responds faster; while drawing a connection, handles on every side of every node remain available. Only the drag released on the empty canvas was timed: a release that makes a connection and an end grip drag take the same path and were checked to work, not timed, so the lines do not claim them (the first draft did; corrected after Lumi's review).
• The translation contract tests pass: evidence of the catalogs' structure and terms, not a review of how the lines read. The other 16 had no native-speaker review.

Verification, by head

Head	What ran	Result
6380755	PR CI, run 39010191849	success: checks, e2e shards 1–6, production bundle (dist), PWA
6380755	Unit (vitest, full); tsc; lint; check:e2e-shards, check:control-bytes; the new spec and the 9 related specs, dev, fresh server; production timing against main	3 603 passed, 1 skipped; lint 0 errors; all pass; 110 passed; see section 2
a792442	PR CI, run 39007472022	success (before the fix; not evidence for it)
a792442	Unit (vitest, full); tsc; lint; check:change-declaration, check:i18n, check:i18n-surface, check:control-bytes, check:isolate-arguments, check:icu-arguments, check:locale-lists, check:functional-glyphs; whats-new.spec.ts on a fresh dev server	3 598 passed, 1 skipped; lint 0 errors; all pass; 96 passed
c287eb3	PR CI, run 39006275586	success: checks, e2e shards 1–6, production bundle, PWA
c287eb3	Full local e2e, --workers=1 --retries=0 (chromium, mobile, portable)	2 201 passed, 0 failed, 10 skipped (54.6 min)
c287eb3	dist config, then pwa config, run separately	16 passed; 19 passed
c287eb3	Unit (vitest, full); tsc; lint; check:change-declaration, check:i18n, check:i18n-surface, check:control-bytes, check:isolate-arguments, check:icu-arguments, check:locale-lists, check:functional-glyphs, check:e2e-shards, check:snapshot-policy, check:form-direction, check:content-direction, check:no-pseudo-locales	3 598 passed, 1 skipped; lint 0 errors; all pass
66ad42b	The new spec and 9 related specs (face handles, ends, reverse, undo / redo, small and Coffee structure, modules, lock, keyboard move), dev, fresh server	109 passed

The wording commit changes only release-note strings, README and the CHANGELOG; the full local e2e was not rerun for it.

Not covered

A phone (the diagram is read-only there, so no drag reaches this path; the mobile project ran in the full e2e), MMO, a real GPU display, the moment of paint.

[cloudflare-workers-and-pages]

Deploying cozy-loop-studio with    Cloudflare Pages

Latest commit:	6380755
Status:	✅  Deploy successful!
Preview URL:	https://af29d737.cozy-loop-studio.pages.dev
Branch Preview URL:	https://perf-draw-start-batch.cozy-loop-studio.pages.dev

View logs