Latest Results
Keep React context objects stable across hot updates (#7071)
* Keep React context objects stable across hot updates
The generated utils/context.js created every React context with
createContext() at module scope. Vite re-executes that module on each hot
update of it, and every state default change rewrites it, so a consumer
refreshed after the update read a different context object than the
provider still mounted from before. With no shared object the consumer's
useContext returned null and the page crashed.
Move all context objects into a static utils/context-registry.js that
imports only React, so no compiler output can invalidate it. The
generated module re-exports the fixed contexts and builds StateContexts
through getStateContext(name), keeping every existing importer and
generated call site unchanged.
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Rename news fragment for PR #7071
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Stop the static runtime from importing the generated context module
state.js and react-theme.js imported initialState, state_name, and the
color mode from the generated context.js. Vite re-executes every module
between a changed file and a refresh boundary, so each compile re-ran the
whole runtime and replaced its module-level singletons: refs, token,
ThemeContext, and the addEvents dispatcher slot. Mounted components kept
the old instances while refreshed ones read the new, empty ones, which
dropped clicks and made ref-based events no-ops during the overlap.
Invert the dependency. The generated module now calls registerApp() with
its data, and the runtime reads it from the registry at call time. The
event loop dispatchers live in the registry too. Nothing the compiler
writes sits below the runtime any more, so a compile only re-executes
generated files and components.
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Test runtime stability during interleaved hot updates
* Emit the context module as .jsx so fast refresh registers its providers
Vite's React plugin skips the refresh transform for a .js file without
JSX, so the generated context module was never registered. Every
re-execution produced brand-new provider component types and React
remounted the whole provider subtree on each compile: the websocket was
torn down and reopened, client state reset, and a second update applied
in the same window closed a socket that was still connecting.
Write the module as context.jsx. The refresh runtime now maps the new
provider functions onto the mounted ones, so a compile re-renders the
providers in place. A stale context.js is removed so extensionless
resolution of $/utils/context cannot pick it over the .jsx file.
The provider module now self-accepts and invalidates its importers from
the client, so a refresh cannot apply while an earlier one is pending.
The overlap integration test therefore loads a route by navigation while
the root refresh is held, which is how a consumer really meets a newer
context instance than the mounted provider.
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Drop string-matching unit tests; the HMR integration test covers the change
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Remove the stale context.js only on a real compile
A dry run returned before writing but had already unlinked the old
module. The unlink now sits with the other post-dry-run pruning.
The ColorModeContext fallback exposes rawColorMode, the key the
color_mode var reads.
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q
* Add news fragment for the reflex package
Claude-Session: https://claude.ai/code/session_01T7KbvgyqeruWJetigu4e6Q Latest Branches
+5%
FarhanAliRaza:lighthouse-pr4-pr5 +5%
claude/fix-rehydrate-without-router-data +3%
claude/fix-rehydrate-missing-onload-substate © 2026 CodSpeed Technology