0.2.1-beta

Released 2026-05-14 · Bug-fix release

Two form-layer correctness fixes in @dashforge/forms, both surfaced while building this documentation site's live examples. No public API change, no behavior change for any other prop.

Affected packages

---

All seven packages bumped to 0.2.1-beta (lockstep). The only source change is in @dashforge/forms:

Fixed — DashForm dropped the resolver prop

---

DashForm destructured its config props (engine / defaultValues / debug / mode / reactions) and spread the rest (...formProps) onto the underlying <form> element. resolver was not in the destructured list, so it fell through into ...formProps and was spread onto the raw <form> DOM node. Two consequences:

1. React rejected it — "Invalid value for prop resolver on form tag".
2. More importantly, the resolver never reached React Hook Form. Schema-based validation via <DashForm resolver={...}> silently validated nothing.

The fix adds resolver to the destructured props and forwards it to DashFormProvider — which already accepted and wired it correctly. DashFormProvider was never affected; only the DashForm convenience wrapper had the gap.

Fixed — DashFormProvider skipped useForm() during SSR

---

DashFormProvider wrapped React Hook Form's useForm() in an isClient ? useForm() : { ...stub } ternary to dodge a "Cannot read properties of null (reading 'useRef')" crash seen during server-side rendering. That was wrong on two counts:

1. it violated the Rules of Hooks — useForm is a hook and must run unconditionally on every render; and
2. the SSR stub exposed control: {}, which silently broke useFieldArray (and therefore useDashFieldArray) under SSG with "control._getFieldArray is not a function".

useForm() is now called unconditionally — it is SSR-safe by design. The original useRef crash is a dual-React-instance symptom; the cure is deduping react / react-dom in the consumer's bundler (Vite: resolve.dedupe), not skipping the hook. useDashFieldArray now works under SSR / SSG — which is exactly how the Field Arrays demo in these docs is pre-rendered.

Added

---

A regression test suite (forms/src/components/DashForm.test.tsx, 4 tests) locks the fix in:

• the rendered <form> carries no resolver attribute,
• submitting the form actually invokes the resolver,
• resolver errors block the onSubmit handler,
• children render inside the form.

Test totals

---

• @dashforge/forms — 137 / 137 passing (+4 from the new DashForm regression suite).
• @dashforge/ui — 484 / 485 passing, 1 skipped (unchanged).
• @dashforge/rbac — 264 / 264 passing (unchanged).

Upgrade notes

---

If <DashForm resolver={...}> appeared to do nothing on 0.2.0-beta — this is why. Upgrade to 0.2.1-beta and it works with no code change. If you worked around the bug by using <DashFormProvider resolver={...}> directly, that path was always correct and continues to work.

The live Zod resolver example in these docs runs on 0.2.1-beta, so you can see it working.