Skip to content

fix(react-form): support defaulted fields and declaration-safe exports - #224

Open
andrewzolotukhin wants to merge 1 commit into
developmentfrom
fix/react-form-defaulted-fields
Open

fix(react-form): support defaulted fields and declaration-safe exports#224
andrewzolotukhin wants to merge 1 commit into
developmentfrom
fix/react-form-defaulted-fields

Conversation

@andrewzolotukhin

@andrewzolotukhin andrewzolotukhin commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Original request

Unblock the Framework beta adoption in Xpenser PR #94, and publish the changes through PRs so they can be reviewed before the next beta is released.

What changed

  • Widen react-form's property-schema bounds to include the schema THasDefault flag. Defaulted strings, enums, booleans, numbers, dates, arrays, and nullable properties remain correctly typed through form.useField() and typed Field.
  • Keep the legacy context hook usable when only the root schema type is specified; supplying the property schema type still preserves precise field inference.
  • Add named TypedFormSystem<R> and TypedFieldComponent<R> exports so shared UI libraries can emit declarations for both an inferred registry and an exported system.Field.
  • Add runtime tests for validation defaults, reset, headless updates, and submission; strict type tests for valid and invalid values/variants/callbacks; and a compiler-based consumer fixture that emits declarations against the built public package.
  • Document default application versus reset semantics, declaration-safe exports, and explicit callback parameter types when value kinds share a variant name.
  • Include a patch changeset for @cleverbrush/react-form.

Reasoning

The beta used SchemaBuilder<any, any, any>, which implicitly fixes its fourth THasDefault generic to false. Real consumer schemas with defaults therefore failed even though runtime behavior was valid. Widening the bound preserves the actual property's type instead of removing defaults or requiring consumer assertions.

The generic factory's anonymous return type also exposed an internal schema symbol during consumer declaration emission. Named public return/callable types retain the registry contract across package boundaries. Runtime validation, default application, and submission behavior are unchanged; the fix stays application-agnostic.

Blog post

Skipped: internal published-library type compatibility fix, not a new public product feature.

Screenshots / preview evidence

Not applicable: this PR changes TypeScript contracts and documentation, not UI rendering. The declaration-emission consumer fixture and runtime tests provide reproducible evidence. Framework has no per-PR deployment job in its CI configuration.

Xpenser preview testing will follow after this PR is merged, the corrected beta is published, and Xpenser #94 consumes that version. Neither PR is merged or released by this work.

Validation

  • npm run lint: passed.
  • npm run build: passed.
  • npm test: passed — 4,267 tests across 178 files; no type errors.
  • npm run typecheck:schema-site: passed.
  • npm run typecheck:docs-site: passed.
  • git diff --check: passed.
  • Dependent consumer compatibility: all seven Xpenser workspace typechecks and the shared UI declaration build passed using these candidate .d.ts files. The published beta files were restored byte-for-byte afterward; no local library patch is shipped.
  • GitHub Lint, Build & Test (Node 24): passed (install, lint, build, both site typechecks, and tests).
  • E2e/preview and SigNoz: not applicable to this type-only library fix; dependent Xpenser preview remains blocked by its published beta.
  • PR-ready notification: skipped; this library PR has no deployment/environment URL. The dependent Xpenser notification remains gated on a working preview.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant