Add native meta-framework support for client <-> server communication (SolidStart, SvelteKit, Nuxt, TanStack Start, Next.js, Astro, etc.)

[fabian-hiller]

This is planned for Formisch v2. We look for experts in all meta-frameworks who help us implement and validate it. Feel free to reach out here or join our Discord: https://discord.gg/w5mRTETqzv

[cr101]

React Router Framework Mode would be useful to include in this work. We are planning a migration from Conform to @formisch/react 1.0.0 in a React Router 8.3 application.

The server integration we need is:

• Formisch performs submit-first client validation and input revalidation.
• A client-valid submission is handed to the React Router route action without bypassing React Router navigation and pending state.
• The route action reconstructs and validates the payload again, then returns server-owned field or form errors to the active Formisch store.
• The rendered form retains native method and action semantics so submission and server-rendered validation still work without JavaScript.
• Nested and repeatable fields use Formisch's JSON path names, so server-side decoding needs defined malformed-path, conflicting-structure, repeated-value, checkbox, sparse-array, and prototype-pollution behavior. This appears related to Explanation behind path and why it is a JSON string #7.

The current Formisch <Form> contract deliberately calls preventDefault() and sets noValidate, so the likely v1 bridge is a Formisch submit handler that delegates successful submissions to React Router, with application-owned synchronization for action errors and React Router's useNavigation for the server pending state.

Is that the v1 integration pattern you would recommend, or is a different seam planned for the v2 meta-framework support? We can report back with implementation and bundle findings once our migration is complete.

[cr101]

Following up now that our migration is complete: the proposed v1 React Router bridge works, including for a nested repeatable form.

Implementation findings

• Formisch performs submit-first client validation as expected. Invalid submissions do not create a React Router action request.

• For client-valid input, our bridge is:

  <FormischForm
    method="post"
    of={form}
    onSubmit={(_output, event) =>
      routeSubmit(event.target as HTMLFormElement)
    }
  />

  useSubmit hands the form to the route action, while useNavigation remains the source of server submission and pending state.

• Retaining native method, action, and encType semantics preserves no-JavaScript submission to the same route action. Since Formisch renders noValidate, progressive enhancement here means authoritative server-rendered validation rather than native constraint validation.

• Every action payload is reconstructed and validated again. Action-owned business errors are returned as field errors and synchronized into Formisch with setErrors; submitted values are restored with reset when needed.

• Server error synchronization is the most involved part of the bridge. We had to ensure that editing a field clears that field's server error while local revalidation does not erase unrelated server errors.

• Formisch field-array operations worked well for the repeatable form. Insert, move, remove, and composite selection updates are synchronous, retain stable item identities, and issue no intent requests. This let us remove the prior response-race lock and navigation bookkeeping.

• JSON-path field names require a server decoder. Ours reconstructs nested objects and contiguous arrays, collects repeated names as arrays, and rejects malformed paths, sparse arrays, conflicting scalar/object/array structures, excessive depth or indexes, and prototype-pollution keys. Its result remains untrusted and passes through route-owned Valibot validation.

• The generic decoder cannot infer schema cardinality or HTML control semantics. Routes still normalize single-versus-repeated values and checkbox values before schema validation.

• End-to-end coverage passed for local validation without action requests, React Router pending feedback, action-owned errors, no-JavaScript submission, tampered payloads, keyboard error recovery, stable repeatable-row identity, and primitive IDs from composite controls.

Production bundle findings

This is measured application output, not a package-size microbenchmark. We compared production builds of the same two journeys before and after replacing Conform/Zod with exactly pinned @formisch/react 1.0.0 and valibot 1.4.2.

Emitted boundary	Before raw	Before gzip	After raw	After gzip	Raw delta	Gzip delta
Semantic form route	4,785	1,765	6,314	2,346	+1,529	+581
Repeatable relationships route	20,975	6,762	21,278	6,957	+303	+195
Shared fields chunk	94,014	26,044	23,596	6,615	-70,418	-19,429
Affected client total	119,774	34,571	51,188	15,918	-68,586	-18,653
Server bundle	147,595	32,084	160,554	35,186	+12,959	+3,102

The affected client output is 57.3% smaller raw and 54.0% smaller gzip. The server bundle grew because the application now owns nested FormData reconstruction and route-side Valibot validation. All established raw and gzip budgets still pass.

Environment: Windows x64, Node 26, npm 11.8.0, Vite 8.2.1, with zlib.gzipSync for gzip measurements.

For React Router support in v2, the highest-value standardized seams from our experience would be:

1. Delegating a client-valid Formisch submission to the framework submission/navigation API.
2. Server decoding for Formisch JSON-path names.
3. Mapping action errors and submitted values back into the active store.
4. Preserving native form semantics for no-JavaScript requests.

[fabian-hiller]

Hey Cristian. Sorry for my late reply. I was taking a short break after the v1 release.

Formisch v1 already exports decodeFormData from @formisch/core. It uses the Valibot schema to rebuild JSON-path fields and restore numbers, booleans, dates, arrays, repeated values, and unchecked checkboxes. It also protects against prototype pollution and very large array indexes. The result should still be validated on the server, as you already do.

Your four proposed seams match what we want native meta-framework support to cover. These real-world findings are very helpful—thank you!

I am happy to collaborate when building the native React Router package for Formisch.