ClintchizandClaude Opus 5
f6993e6cdb
Two mechanisms tried and rejected while testing this against the live
showcase, both failing the same way on a second history step:
- synthesising a click on the matching tab: a re-render replaces the tab
buttons, and clicking a freshly replaced node that has not been bound
does nothing at all
- tracking the last applied value in the runtime: that state drifts out of
step with the component and silently swallows real changes
The runtime is now stateless. It announces the value the URL names via a
wrnexus:tabs:restore event and the component applies it, comparing against
its own selection rather than a DOM attribute a re-render owns.
Nav submenus are anchored so the viewport clamp keeps them on screen.
Comments in the runtime template trimmed to stay inside the size budget
rather than raising the ceiling again.
Known limitation: a second consecutive back/forward does not update the
selection, because the re-render replaces the component root without
rebinding its declarative listeners. That is a framework defect, not a Tabs
one, and needs its own fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WRNexus UI component showcase
The showcase is generated from packages/ui/component-reference.json. It stays
synchronized with the current component source rather than maintaining a second
hand-written catalog.
bun run --cwd examples/component-showcase dev
Open http://localhost:3000.
Detail-page coverage
Every current UI component receives a dedicated detail page with:
- an interactive server-rendered playground for every declared prop
- typed boolean, number, array, and object controls
- public component-tag syntax with single-quoted dynamic WRN expressions
- component-specific production use cases when a profile exists
- responsive fallback examples for every remaining component
- copyable
.wrnsource beside every live preview - complete props, slots, and explicitly declared public events
- live
event.detailoutput for interactive components - previous and next component navigation
The specialized profiles for new and recently repaired components live in:
scripts/showcase-profiles.mjs
Update that file to add product-quality examples or public enum options. Do not infer allowed prop values from implementation comparisons; unrestricted values such as icon classes, labels, IDs, and URLs must remain free-form inputs.
Generated files
The generator creates:
app/layouts/showcase.wrn
app/layouts/document.wrn
app/pages/*.wrn
app/pages/components/*.wrn
showcase-manifest.json
showcase-manifest.json records component, category, demo, prop, slot, and event
coverage and is used by the test suite. Do not hand-edit generated pages.
Validation
After changing UI components, metadata, profiles, the playground, or showcase styles, run:
bun run scripts/generate-ui-component-reference.mjs
bun run --cwd examples/component-showcase generate
bun run --cwd examples/component-showcase test
bun run --cwd examples/component-showcase build
The complete local check is:
bun run --cwd examples/component-showcase check
Review representative component pages at mobile, tablet, and desktop widths and in light, dark, keyboard-only, and reduced-motion modes before publishing.