test(joint-react): specify how many events useOnElementsMeasured delivers

[kumilingus]

Description

A specification, written as tests, for when useOnElementsMeasured delivers an event. No fix. Ten of the sixteen cases fail on purpose.

The hook exists so an application can run a layout once element sizes are known. That only works if one settled change delivers exactly one event: a layout must not run while an element is still waiting to be measured, and it must not run several times for the same change.

An element is pending only when something is actually going to measure it. That is real here, not simulated. A plain element renders as an SVG <rect>, nothing measures it, and it is settled the moment it is added whatever its size. A pending element renders through <HTMLHost>, which calls useMeasureElement and registers the node with the store's observer, so it genuinely stays outstanding until a measured size arrives. jsdom's ResizeObserver is a no-op mock, so the measured size is then written with the autoSize option, exactly as the observer pipeline does.

Results

case	expected	actual
seed pass	1	1
add an element nothing measures	1	1
add an element waiting to be measured, before it is measured	0	1
the same element, after it is measured	1 total	2 total
add two elements nothing measures	1	1
add two elements that both wait	0, then 1	1, then 1
add a plain element and a waiting one together	0, then 1	1, then 1
isInitial reported once	1	1
reset the graph	isInitial: true	false
reset with elements that wait, before measuring	0	1
isInitial once per reset	1	0
application resizes an element nothing measures	0	1
application sizes an element that is waiting	0, then 0, then 1 when measured	1, then 0, then 1
seed pass with a zero-sized element in the graph	1	1
add a batch containing a zero-sized element	1	1
later batches once a zero-sized element is in the graph	0, then 1	1, then 1

Same result under React 19 and React 18.

Most failures are one defect. The store bumps its measure state whenever any element has a size, rather than when nothing is left outstanding. So a consumer is told sizes are ready while a newly added element is still waiting, and told again once it arrives. A layout driven by this hook therefore runs twice, the first time on an element with no size.

The mixed batch is the case that matters most in practice. A plain element and one that waits, added together, is one change and should be one event, delivered once the second is measured.

A graph reset has the same shape plus one of its own. A reset replaces the diagram, so the next pass is that diagram's first one and a consumer that fits the paper on isInitial has new contents to fit. The flag never comes back, because the hook only restarts its history when the effect re-runs, and a reset leaves both the paper and the graph identity untouched.

That is also why isInitial is not the signal it looks like. It means at least one element has a size, not that measurement has finished.

Sizes written by the application

A size the application writes never produces an event, in either situation. If the element is settled already, nothing about readiness changed, which is the re-entrant layout of #3514. If it is waiting to be measured, the measurement is still owed and will overwrite the write, which warnResizeOnAutoSizedElement already warns about.

Both cases are pinned so that a fix cannot satisfy one by breaking the other. The second also pins the shape of the predicate: after the write the element has a positive size, so a store that gates on "every element has a size" would report settled while the measurement is still outstanding.

An element that stays zero-sized

Zero is a legal final size. A layout anchor marks a position without drawing anything, so nothing measures it and nothing will ever report a size for it. Zero size is not the same as waiting to be measured, and a gate that treats it as such never opens again.

The three cases pin that from the other side of the same predicate: a zero-sized element must not suppress the seed pass, the batch that adds it, or any batch after it. All three pass on dev today, apart from the third failing on the shared pending-element defect above.

Relationship to #3518

I re-ran the spec with #3518 applied.

It fixes the pending-element and reset failures, which is what it is for. It breaks one case: add a batch containing a zero-sized element goes from 1 event to 0, and stays at 0 for every batch after it.

The cause is that #3518 infers "waiting to be measured" from the size value: a zero-sized element enters unmeasuredElements and nothing ever takes it out, because no measurement is coming — no autoSize write, no markElementRendered. The gate is shut permanently.

This is not hypothetical. In the ci-pipeline-editor/react demo the layout runs 3 times on load with published 4.3.6, 3 times on dev, and 0 times with #3518. GroupEndModel declares size: { width: 0, height: 0 } deliberately; instrumenting deliverMeasurement prints OUTSTANDING end#jobs,end#poll forever.

The gate needs a positive signal that a measurement is actually coming — the element registered a measurer — not an inference from the size value.

Notes

• The signal the store is missing already half exists: observer.has(id) is true once an element has registered for measurement, and it is used today only for a dev warning. The gap is the window between a cell being added and its portal mounting, during which an element that will be measured has not registered yet.
• Each event is recorded as just its isInitial flag, not the whole payload, so a failure prints one boolean instead of the entire paper.
• The probe is mounted beside <Paper>, not inside renderElement. The existing paperRenderElementWrapper puts its children inside renderElement, which mounts one hook instance per element, so adding an element adds an instance and their separate events look like repeats from one subscriber.
• Jest 30 here, so these can be it.failing(...) instead if you would rather the suite stayed green and flipped when the behaviour is fixed. Left as plain failures since the point is to make the gap visible.
• No changeset: tests only, nothing releasable.
• Targets dev, which has no CI, so the suite was run locally under both React versions.

🤖 Generated with Claude Code