ClintchizandClaude Opus 5
e898929193
Two faults found by driving the island demo in a real browser. Both were
silent: the markup, every asset, and all 48 island tests were correct
either way.
An island renders nothing until it mounts, so its placeholder is
zero-height, and IntersectionObserver does not treat a zero-area target
consistently -- client:visible islands mounted on one load and not the
next. Visibility for those is now decided from the element's own rect,
driven by scroll and resize; a placeholder with real size still uses the
observer. The strategy had no test at all, which is why this shipped.
After an island source edit the browser kept running the old code. The
rebuild worked and the file was refetched, but the loader imports a URL
that does not change, and the browser caches modules by URL. Remounts now
carry a generation the dev loader folds into the request.
Verified in the browser: mounts with start={3} as a number, clicks reach
React (3 -> 5), and an edit to Counter.tsx now shows the new text and
stays interactive.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@wrnexus/react
Opt-in React islands for WRNexusJS: mount npm React components inside server-rendered .wrn pages without adopting React as the framework's rendering model.
Import a .tsx component in a .wrn script block and use it as an element. The compiler emits a data-wrn-island placeholder instead of a server render, and this package's runtime mounts it in the browser with createRoot. Islands are client-only, each mounts inside its own error boundary, and roots are disposed on client-side navigation.
react and react-dom are optional peer dependencies, so apps that use no islands ship no React. A route with no islands still ships zero framework JavaScript.
Use useWrnStore(name, selector?) to read a WRNexus store from inside an island and useWrnActions(name) to write to it. Writes belong in event handlers or effects, never during render.