Repository navigation
registry.wizards is built for every useForm consumer, including apps that never call useWizard #667
Description
createRegistry builds registry.wizards (a shallowReactive Map), wizardConsumers, pendingWizardEvictions, cancelPendingWizardEviction and trackWizardConsumer for every consumer, including an app that never calls useWizard.
Measured: 80 B gz eager, independently reproduced. That is 35% of the wizard's entire eager seam (229 B), paid by useForm-only apps.
The only readers are inject-wizard.ts:57,62,69 and use-wizard.ts:1985-1994, and the second exists purely to populate the registry for the first. So the whole structure serves keyed injectWizard resolution and nothing else.
injectWizard stays. Its own module is opt-in and only loads when imported. The proposal is to move the registry into the wizard module and attach it to the registry object on first useWizard, the way historyPlugin already attaches a module to the form store.
The constraint that makes this delicate, and it is not a byte concern. registry.ts documents that each SSR request builds its own registry so cross-request state cannot leak. The wizards Map is safe today because it is constructed inside createRegistry, which is per-request. A relocation that puts it in module scope would hold wizard handles across requests, which is a data-leak shape rather than a performance one.
Any implementation must attach onto the per-request registry object, and must land with a test that renders two sequential SSR requests and asserts the second sees none of the first's wizards. Without that test this change should not merge.
Also confirm kAttaformWizardActiveStepResolver (provided by the Nuxt plugin so server and client compute the same initial step) is still reachable before any component setup after the move.
Found in the 2026-09-18 feature audit (main@b4a64ef9, eager baseline 33,204 B gz). Every byte figure is a measured ablation, not an estimate.
🤖 Generated with Claude Code
Activity