@dashforge/tw: dev warning for standalone form widget without value/onChange (G-29)

[kensaadi]

Symptom

When a @dashforge/tw form widget (TextField, NumberField, Textarea, Switch, Checkbox, RadioGroup, Select) is rendered:

• Outside a DashFormProvider (so useContext(DashFormContext) === undefined and isFormMode === false)
• AND without value + onChange props

... the component silently renders as an uncontrolled input that never emits changes. No error, no warning, no visual hint — the input just doesn't work. Extremely hard to diagnose.

Context

Filed in Blueprint's dogfood report as G-29, added 2026-07-08 alongside the G-26 reclassification. Runtime verification confirmed that @dashforge/tw form widgets DO work as standalone controlled inputs (via InputHTMLAttributes<HTMLInputElement> inheritance) when value + onChange are provided. The problem is the failure mode when a consumer forgets BOTH the provider AND the controlled props.

Why this is worth fixing

• Silent no-op is the worst possible failure mode — no signal that the widget is broken
• Very common consumer mistake: mounting <TextField> in a shell that isn't a form and forgetting to add value + onChange
• Cheap fix: single dev-only warning in a shared helper, no runtime cost in production

Acceptance

• Shared helper detects the condition (!isFormMode && userValue === undefined && userOnChange === undefined) once per widget mount
• console.warn in dev mode only (guard on process.env.NODE_ENV !== 'production') — silent in prod
• Warning message: "[@dashforge/tw] <TextField name=\"X\"> is not inside a DashFormProvider and no value/onChange were provided. Did you forget the provider, or intend controlled mode? See docs on controlled vs bridge mode."
• Same helper applied to all form widgets (TextField, NumberField, Textarea, Switch, Checkbox, RadioGroup, Select)
• Docs page in dashforge-docs-lab documents "controlled vs bridge mode" explicitly so the warning message links somewhere useful

Related

• Adjacent to (but does NOT depend on) the G-26 reclassification in Blueprint's dogfood report — the widgets already work standalone; this is a paper-cut fix on top of that discovery

[kensaadi]

Shipped in e5ae785.

What landed:

• New shared hook useStandaloneFieldWarning at libs/dashforge/tw/src/hooks/useStandaloneFieldWarning.ts. Guards on process.env.NODE_ENV !== 'production' and warns once per mount via a useRef (StrictMode-safe). Zero runtime cost in production.
• Wired into all six affected widgets: TextField, NumberField, Textarea, Switch, Checkbox, RadioGroup. Hook is called before the visibility / access early-returns to keep hook ordering consistent across renders.
• Select was listed in the original issue but does not exist in @dashforge/tw — it stays in the Deferred bucket on [1.2.0] Component Defaults System — theme.components + slotProps (Option C) #60 (🟡 DECIDE — G-25 Blueprint dogfood flag) and will pick up the same guard whenever it lands.

Warning message format:

[@dashforge/tw] <TextField name="X"> is not inside a DashFormProvider and
no value/onChange were provided. Did you forget the provider, or intend
controlled mode? The widget will render but never emit changes upward.
See the "Controlled vs bridge mode" docs.

Tests: 11 unit tests on the hook covering the full truth table (standalone triggers, bridge mode suppresses, controlled value suppresses, controlled onChange suppresses, value=null treated as controlled, value=false treated as controlled, warns at most once across re-renders, no-op in production, message composition for each of the 6 wired widget names, missing/empty name renders <Component> without a broken name="" segment).

Regression check: full @dashforge/tw suite — 109 files / 1676 tests pass, 1 skipped, 0 fail (was 108 / 1665 before). Delta is exactly the new hook spec (+1 file, +11 tests); pre-existing widget specs untouched.

Not covered here (out of scope for this issue):

• The docs-lab "Controlled vs bridge mode" page mentioned in the acceptance criteria — tracked separately as a docs task.