fix(native): release resolved-style entries, and compute a derived observable once per change

[YevheniiKotyrlo]

Stacked on #434. Its commit is the first of the seven here, so review that one first — everything below is the diff against it, not against main.

GitHub's stacked pull requests do not support cross-fork stacks, so this has to target main and carries #434's commit as its first. To give you the layered view anyway I stacked the two branches in my fork: PR #2 there shows only the six new commits — 6 commits, 14 files, based on #434's branch — and that is the diff to review. (Plain compare if you would rather not leave a diff view.) If #434 lands first, this rebases onto it with nothing left over.

#434 made the resolved-style cache share correctly. This one makes it shrink, and fixes the reason it was cheap to leave growing: every consumer was recomputing its styles from scratch on every render anyway.

The cache was designed to release, and nothing reached the release

stylesFamily's factory already carries it — cleanup deletes the family entry once nothing observes the observable. The mechanism is correct and was unreachable:

// useNativeCss.ts — both effects share one Set
const observers = new Set<Effect>();
const ruleEffect: Effect = { observers, run: … };
const styleEffect: Effect = { observers, run: … };

// …and only one is ever detached
useEffect(() => () => cleanupEffect(state.ruleEffect), [state.ruleEffect]);

cleanupEffect removes the effect it was handed from each observable, then clears the shared set. The sibling is now unreachable and still registered on every observable it ever read. The observer count never reaches zero, so the entry is never deleted — and the dead component's run, which closes over its setState, stays reachable from the observable graph.

Running this PR's three release tests against #434's code, printing the count instead of asserting it:

	after mount	after unmount
one element	1	1
two elements sharing one entry	1	1
one element, 12 re-renders with an inline vars()	13	13

With this PR: 1 → 0, 1 → 1 → 0 (refcounted, so a shared entry survives its first leaver), and 13 → 1 → 0.

The third row is the one that matters in an app. vars() returns a fresh object per call, so style={vars({…})} hands the cache a new weak key on every render. Each render supersedes the last and every superseded entry is unobserved immediately — 13 entries for one element that was only ever mounted once.

Four things had to be true for the release to work:

• Each effect owns its dependency set, and both are detached on unmount. Sharing saved one allocation per component and made detaching unexpressible.
• updateRules detaches both. It passed only ruleEffect, so a component moving to a new observable left the old one holding an observer.
• cleanup drops the reverse edge, or a component that superseded its entry still lists it as a dependency and its unmount walks back to release an entry it no longer uses — possibly one another component has since joined.
• The delete is by identity, not by hash. deleteIf(hash, entry) — the hash may since map to a different observable, and deleting by hash alone destroys somebody else's live entry.

A derived observable recomputed on every read

if (!didInit) { value = init(getter, undefined); }

Nothing set didInit for a derived observable — only the static-init branch and set did. So a computed value was recomputed per read rather than per change. For stylesFamily that is calculateProps — the whole style resolution — on every render of every styled element, which is exactly the work the cache exists to avoid.

Latching it after the first compute is the whole change. Twenty reads of a derived observable: 21 computes before, 1 after. Recomputation on change is a different path and is untouched — a dependency notifies, effect.run re-runs the read function and re-assigns, subscribers are notified from there. The memo only removes the redundant work between those.

Timed at the library's own entry point rather than through a render, because an end-to-end render bench had a wider run-to-run spread than the entire contribution: getStyledProps 1952ns → 488ns, 4.0×, stable to about 5% across nine repetitions either side. That figure is Node — the repo's own jest environment — so treat the ratio as indicative and the compute count as the claim. On any engine the removed work is one full calculateProps per read.

Why the memo cannot ship on its own

A batch is a Set, and iterating one does not revisit a member it has already passed. An effect notified a second time during a drain — because a derived observable it depends on recomputed after the effect ran — was dropped.

That was survivable while every get recomputed: whenever the effect ran, it pulled fresh values out of its dependencies. It stops being survivable the moment a derived observable memoises, because the effect then reads the value its dependency held before the recompute and nothing runs it again. The stale value is permanent, not a transient glitch.

The reachable shape is vw → { stylesObs, rootVariables } → stylesObs — a style that reaches a viewport unit directly through the unit resolver and again through a root variable whose media query tests a width. Ordinary CSS:

@media (prefers-color-scheme: dark) and (min-width: 600px) { :root { --gap: 16 } }
:root { --gap: 8 }
.box { width: 50vw; padding: var(--gap) }

After a resize the box keeps padding: 8 until the next viewport change — and because stylesFamily hands one memoised object to every consumer, a component mounted after the rotation gets the stale value too.

Both drains — the Dimensions handler and StyleCollection.inject — now call one exported drainObservableBatch, which removes a member before running it, so a re-notification re-enqueues rather than landing on an entry the iteration has passed. Mutation-proven: with the previous for (const effect of batch) the diamond test observes 2,10; with the work list, 2,20.

This is why the six commits are one PR. The memo is the win, the drain fix is what makes the memo correct, and the release is what makes the cache bounded. Landing any of them alone is worse than landing none.

A read that throws leaves the observable as it found it

get registered the caller before computing, so a read function that throws — resolve does, on an unknown function — left the caller subscribed to an observable that never initialised: on the list, owed nothing, counted by every "does anyone observe me" question. Computing first means a failure leaves the observable exactly as the call found it.

Found by fuzzing rather than by reading: across 40 000 randomised operation sequences the previous ordering left 5 subscribers attached to an observable that never initialised, and this ordering leaves none.

The cap is a backstop, not the mechanism

family takes an optional maxSize, and stylesFamily passes 2048. Releasing on unmount is what keeps the cache proportional to what is on screen; the cap is what makes exhaustion unrepresentable if a future path ever leaks again. It sits far above any real screen — a 150-control stress screen measures 271 entries on a device — so a correctly-behaving app never reaches it.

Eviction is safe by construction rather than by policy: a miss re-derives the value from the rules the caller brought, so the worst an evicted entry costs is the work of rebuilding it, and a consumer still holding a previously-returned value keeps a live reference and is unaffected.

A bounded family evicts the least recently read, not the oldest. That ordering is the point here: the workload that fills this cache is a churn of single-use keys arriving beside a small set read on every render, and insertion order would discard exactly the entries worth keeping. Renewing on a hit costs a delete plus a set on the read path — ~23ns against a ~265ns key derivation, under a tenth of the work it protects. Omitting maxSize keeps a family unbounded, which is what every other call site does, so nothing else changes behaviour.

Tests

Twenty-eight across nine files, each written red first.

• style-cache-release.test.tsx — release on unmount; a shared entry survives its first leaver; a superseded entry goes while the component stays mounted.
• style-cache-release-reactive.test.tsx — the entry still updates through media queries, variables and colour scheme after the release wiring changed.
• style-cache-release-safety.test.tsx — an animated viewport-unit class survives a dimension change; unmounting never deletes another component's live entry; a superseded component never deletes the entry it left behind.
• style-cache-stress.test.tsx — mounting and unmounting a tree repeatedly returns the cache to empty; an entry shared across many siblings survives until the last one goes; per-render key churn stays flat and drains completely.
• observable-memo.test.ts — computes once across twenty reads; still recomputes on change (pinning the count, not toBeGreaterThan, which the old behaviour also satisfied); a conditional dependency is picked up the first time its branch is taken; a static observable is unaffected.
• observable-batch-drain.test.ts — the diamond above; an empty drain is a no-op.
• observable-init-failure.test.ts — a read that throws registers no observer; a successful read still registers.
• native-style-mapping-idempotence.test.tsx — draining a cached entry twice produces the same props.
• family.test.ts — eviction order, deleteIf identity semantics, and that an unbounded family is unchanged.

Verification

yarn typecheck and yarn lint both exit 0. Full suite (yarn test), same runner, measured against #434's head:

	#434 (152b5ad)	this branch
passed	1067	1095
failed	3	3
skipped	21	21

Exactly +28, all passing. The 3 failures are identical on both sides and on unmodified main: they are the babel import-plugin's relative-import cases, which are the Windows backslash-vs-forward-slash path defect I reported in #390 and are green on Linux and macOS. Nothing outside src/__tests__/babel/ fails.

Beyond the suite, this branch is running in my app: the full patch renders a 150-control stress screen on a physical Android device (Xiaomi Mi MIX 3) with no exceptions, composed with 26 other local contributions to this library.