# Formisch The lightweight, schema-first, and fully type-safe form library for React, Solid, Vue, Svelte and more. ## Get started (guides) ### Introduction Formisch is a schema-based, headless form library for React. It manages form state and validation. It is type-safe, fast by default and its bundle size is small due to its modular design. Try it out in our playground! #### Highlights - Small bundle size starting at 2.5 kB - Schema-based validation with Valibot - Type safety with autocompletion in editor - Open source and fully tested with 100 % coverage - It's fast – re-renders only if necessary - Minimal, readable and well thought out API - Supports all native HTML form fields #### Example Every form starts with the `useForm` hook. It initializes your form's store based on the provided Valibot schema and infers its types. Next, wrap your form in the `
` component. It's a thin layer around the native `` element that handles form validation and submission. Then, you can access the state of a field with the `useField` hook or the `` component to connect your inputs. ```tsx import { Field, Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function LoginPage() { const loginForm = useForm({ schema: LoginSchema, }); return ( console.log(output)}> {(field) => (
{field.errors &&
{field.errors[0]}
}
)}
{(field) => (
{field.errors &&
{field.errors[0]}
}
)}
); } ``` In addition, Formisch offers several functions (we call them "methods") that can be used to read and manipulate the form state. These include `focus`, `getAllErrors`, `getErrors`, `getInput`, `handleSubmit`, `insert`, `move`, `remove`, `replace`, `reset`, `setErrors`, `setInput`, `submit`, `swap` and `validate`. These methods allow you to control the form programmatically. #### Comparison What makes Formisch unique is its framework-agnostic core, which is fully native to the framework you are using. It works by inserting framework-specific reactivity blocks when the core package is built, giving you native performance for any UI update. A modular methods API keeps bundles starting at just ~2.5 kB by only including the methods you import, and end-to-end type safety covers deeply nested paths and field arrays with TypeScript inference that stays fast even as forms grow. For a side-by-side look at how Formisch compares to React Hook Form and TanStack Form, see the comparison guide. #### Vision My vision for Formisch is to create a framework-agnostic platform similar to Vite, but for forms — a shared core that lets the same mental model and codebase work natively across every modern UI framework. #### Feedback Find a bug or have an idea how to improve the library? Please fill out an issue. Together we can make forms even better! #### License This project is available free of charge and licensed under the MIT license. ### Installation Below you will learn how to add Formisch to your project. #### TypeScript If you are using TypeScript, we recommend that you enable strict mode in your `tsconfig.json` so that all types are calculated correctly. > The minimum required TypeScript version is v5.0.2. ```ts { "compilerOptions": { "strict": true, // ... } } ``` #### Install Valibot Formisch uses [Valibot](https://valibot.dev/) for schema-based validation. You need to install it first because it is a peer dependency. ```bash npm install valibot # npm yarn add valibot # yarn pnpm add valibot # pnpm bun add valibot # bun deno add npm:valibot # deno ``` #### Install Formisch You can add Formisch to your project with a single command using your favorite package manager. ```bash npm install @formisch/react # npm yarn add @formisch/react # yarn pnpm add @formisch/react # pnpm bun add @formisch/react # bun deno add npm:@formisch/react # deno ``` Then you can import it into any JavaScript or TypeScript file. ```ts import { … } from '@formisch/react'; ``` #### For AI Agents We provide agent skills that teach AI agents the correct patterns for working with Valibot and Formisch. You can install them by running the following command in your terminal: ```bash npx skills add open-circle/agent-skills ``` You can learn more about the Valibot and Formisch agent skill [here](https://github.com/open-circle/agent-skills). ### Comparison Formisch is one of several form libraries available for React. The two most common alternatives are [React Hook Form](https://react-hook-form.com) and [TanStack Form](https://tanstack.com/form/latest). This page is meant as a quick reference for picking the right tool. For a deeper explanation of the architectural differences and the reasoning behind each row of the table below, see our long-form comparison article. #### At a glance | | **Formisch** | React Hook Form | TanStack Form | | ---------------------- | --------------------------------------- | ----------------------------------- | --------------------------------------- | | Type source | Inferred from schema | Generic you declare | Inferred from `defaultValues` | | Validation location | Defined in schema | Per-field or resolver | Per-validator config | | Validation timing | Form-wide `validate` / `revalidate` | Form-wide `mode` option | Per-validator trigger | | Async validation | Built-in via schema | Manual loading state | Built-in `isValidating` | | Re-render scope | Automatic per signal | Manual via `watch` / `useFormState` | Automatic per subscription | | Schema libraries | Valibot | Any via resolvers | Standard Schema | | Bundle size (min+gzip) | From ~2.5 kB | ~12 kB | ~15 kB | | Framework support | React, Preact, Solid, Svelte, Vue, Qwik | React | React, Vue, Solid, Svelte, Lit, Angular | The table is intentionally short. It only covers the dimensions that most often drive a library choice in practice. Other differences such as devtools, ecosystem maturity, and community size are real but tend to matter less than how each library handles types, validation, and re-renders. #### Why Formisch? Three reasons to pick Formisch over the alternatives above: **One schema, no second source of truth.** A single Valibot schema is everything the form needs: the runtime validator, the source of types, and the description of the form's structure — all at once. There is no separate TypeScript generic to declare, no `defaultValues` object to keep aligned with the schema, no resolver to configure. When the schema changes, every part of the form follows — at compile time and at runtime. **The smallest bundle, by a wide margin.** Formisch starts at ~2.5 kB and grows only as you import additional methods like `focus`, `getInput`, and `reset`. That is several times smaller than the alternatives in the table above — and it stays that way because the core is intentionally small and the library is fully tree-shakable, so methods you don't import don't end up in your bundle. **Type safety that stays fast.** Types flow from the schema through every API, including deeply nested paths and field arrays. The inference is structured to keep TypeScript editor performance from degrading as schemas grow — which matters in large codebases where heavily-generic form libraries become a friction point. #### Which library should you use? **React Hook Form** is a mature, well-documented choice with a large community and years of production usage. For simple to moderately complex forms, it remains a reasonable default. The tradeoffs only become visible as forms grow: types and schema drift out of sync, validation rules spread across components, and re-render scope becomes your responsibility. **TanStack Form** is a good fit when you need fine-grained control over validation timing and built-in async validation handling without building that infrastructure yourself. It is also the natural choice if your team is already invested in the TanStack ecosystem and values a consistent mental model across data fetching, routing, and forms. **Formisch** makes the most sense for new projects in TypeScript-heavy codebases, especially when you expect forms to grow in complexity. The schema-first design means there is a single source of truth for types, runtime validation, and form structure, so there is less to keep aligned over time. The main consideration is that Formisch currently supports only [Valibot](https://valibot.dev) as the schema library. #### Migrating from React Hook Form Migrating from React Hook Form to Formisch is a genuine rewrite of the form layer, not a drop-in replacement. The mental model is different: instead of starting from a component and attaching form behavior to it, you start from a schema and build the component around it. The two libraries can coexist in the same application, so you can migrate one form at a time. For a side-by-side mapping of common React Hook Form APIs to their Formisch equivalents, see the migration section of the comparison article. #### Next steps If you have decided that Formisch is a good fit, install it via the installation guide and start building by defining your form. ### LLMs.txt If you are using AI to generate forms with Formisch, you can use our LLMs.txt files to help the AI better understand the library. #### What is LLMs.txt? An [LLMs.txt](https://llmstxt.org/) file is a plain text file that provides instructions or metadata for large language models (LLMs). It often specifies how the LLMs should process or interact with content. It is similar to a robots.txt file, but is tailored for AI models. #### Available routes We provide several LLMs.txt routes. Use the route that works best with your AI tool. - [`llms.txt`](/llms.txt) contains a table of contents with links to all Markdown files - [`llms-react.txt`](/llms-react.txt) contains a table of contents with links to React related files - [`llms-react-full.txt`](/llms-react-full.txt) contains the Markdown content of the entire React docs - [`llms-react-guides.txt`](/llms-react-guides.txt) contains the Markdown content of the React guides - [`llms-react-api.txt`](/llms-react-api.txt) contains the Markdown content of the React API reference > We also provide a Markdown version of every documentation page. You can access it by replacing the trailing slash (`/`) in the URL with `.md`. For example, `/react/guides/installation/` becomes `/react/guides/installation.md`. #### For AI Agents Our [`SKILL.md`](https://github.com/open-circle/agent-skills/blob/main/skills/formisch/SKILL.md) contains specialized instructions for AI agents to build forms and manage state. #### How to use it To help you get started, here are some examples of how the LLMs.txt files can be used with various AI tools. > Please help us by adding more examples of other AI tools. If you use a tool that supports LLMs.txt files, please [open a pull request](https://github.com/fabian-hiller/valibot/pulls) to add it to this page. ##### Cursor You can add a custom documentation as context in Cursor using the `@Docs` feature. Read more about it [here](https://docs.cursor.com/context/@-symbols/@-docs). ## Main concepts (guides) ### Define your form Creating a form in Formisch starts with defining a Valibot schema. The schema serves as the blueprint for your form, outlining the structure, data types, and validation rules for each field. #### Schema definition Formisch is a schema-first form library built on top of [Valibot](https://valibot.dev/). When you create a form with `useForm`, TypeScript types are automatically inferred from your schema, giving you full autocompletion and type safety throughout your form without needing to write any manual type definitions. ##### Example schema The following schema defines a form with two required string fields. The `email` field must be a valid email format, and the `password` field must be at least 8 characters long. Each validation includes custom error messages that will be displayed when validation fails. > For more complex schema examples, check out the schemas of our playground. ```ts import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe( v.string('Please enter your email.'), v.nonEmpty('Please enter your email.'), v.email('The email address is badly formatted.') ), password: v.pipe( v.string('Please enter your password.'), v.nonEmpty('Please enter your password.'), v.minLength(8, 'Your password must have 8 characters or more.') ), }); ``` #### Schema validation Your schema definition should reflect exactly the data you expect when submitting the form. For example, if the value of a field is optional and will only be submitted in certain cases, your schema should reflect this information by using `v.optional(…)`. ```ts import * as v from 'valibot'; const ProfileSchema = v.object({ name: v.pipe(v.string(), v.nonEmpty()), bio: v.optional(v.string()), // <- Optional field }); ``` Formisch validates your form values against the schema before submission, ensuring that your form can only be submitted if it matches your schema definition. #### Next steps Now that you understand how to define your form schema, continue to the create your form guide to learn how to initialize your form with `useForm`. ### Create your form Formisch consists of hooks, components and methods. To create a form you use the `useForm` hook. #### Form hook The `useForm` hook initializes and returns the store of your form. The store contains the state of the form and can be used with other Formisch hooks, components and methods to build your form. ```tsx import { Field, Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function App() { const loginForm = useForm({ schema: LoginSchema, }); return
{/* Form fields will go here */}
; } ``` ##### Configuration options The `useForm` hook accepts a configuration object with the following options: - `schema`: Your Valibot schema that defines the form - `initialInput`: Initial values for your form fields (optional) - `validate`: When validation first occurs (optional, defaults to `'submit'`) - `revalidate`: When revalidation occurs after initial validation (optional, defaults to `'input'`) ```tsx const loginForm = useForm({ schema: LoginSchema, initialInput: { email: 'user@example.com', }, validate: 'initial', revalidate: 'input', }); ``` Formisch tracks two inputs for every field: the **initial input** (baseline for dirty tracking) and the **current input** (what the user is editing). In many apps, the initial input represents the server state while the current input represents the client state. `isDirty` becomes `true` when a field's current input differs from its initial input. Use `setInput` to update the current input (client state), and use `reset` to update the initial input (baseline) when your server data changes or is refreshed. ##### Multiple forms When a page contains multiple forms, you can create separate form stores for each one: ```tsx import { Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); const RegisterSchema = v.object({ username: v.pipe(v.string(), v.minLength(3)), email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function App() { const loginForm = useForm({ schema: LoginSchema }); const registerForm = useForm({ schema: RegisterSchema }); return ( <>
{/* … */}
{/* … */}
); } ``` #### Next steps Now that you know how to create a form, continue to the add form fields guide to learn how to connect your input elements to the form using the `Field` component. ### Add form fields To add a field to your form, you can use the `Field` component or the `useField` hook. Both are headless and provide access to field state for building your form UI. #### Field component The `Field` component has two mandatory properties: `of` which accepts the form store, and `path` which specifies which field to connect. If you use TypeScript, you get full autocompletion for the path based on your schema. ##### Children prop As a child, you pass a function to the `Field` component that returns JSX. The function receives the field store as its parameter, which includes the current value, error messages, and props to spread onto your input element. ```tsx import { Field, Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function App() { const loginForm = useForm({ schema: LoginSchema, }); return (
{(field) => } {(field) => ( )}
); } ``` > **Important:** The event handlers in `field.props` read the value from the DOM as a string. Fields with a non-string schema like `v.number()` or `v.date()` therefore need to be controlled to store the value with the correct type. See the controlled fields guide to learn more. > **Important:** If you plan to set initial values with `initialInput` or programmatically control field values using methods like `setInput` or `reset`, you must make your fields controlled by setting the appropriate attributes (like `value`, `checked`, or `selected`). See the controlled fields guide to learn more. ##### Headless design The `Field` component does not render its own UI elements. It is headless and provides only the data layer of the field. This allows you to freely define your user interface. You can use HTML elements, custom components or an external UI library. ##### Path array The `path` property accepts an array of strings and numbers that represents the path to the field in your schema. For top-level fields, it's simply the field name wrapped in an array: ```tsx {(field) => } ``` For nested fields, the path reflects the structure of your schema: ```tsx // For a schema like: v.object({ user: v.object({ email: v.string() }) }) {(field) => } ``` ##### Type safety The API design of the `Field` component results in a fully type-safe form. For example, if you change your schema, TypeScript will immediately alert you if the path is invalid. The field state is also fully typed based on your schema, giving you autocompletion for properties like `field.input`. #### useField hook For very complex forms where you create individual components for each form field, Formisch provides the `useField` hook. It allows you to access the field state directly within your component logic. ```tsx import { useField } from '@formisch/react'; import type { FormStore } from '@formisch/react'; import * as v from 'valibot'; type EmailInputProps = { form: FormStore>; }; function EmailInput(props: EmailInputProps) { const field = useField(props.form, { path: ['email'] }); return (
{field.errors &&
{field.errors[0]}
}
); } ``` ##### When to use which - **Use `Field` component**: When defining multiple fields in the same component. It ensures you don't accidentally access the wrong field store. - **Use `useField` hook**: When creating field components for single fields. It allows you to access field state in your component logic. The `Field` component is essentially a thin wrapper around `useField` that allows you to access the field state within JSX code. #### Field store The field store provides access to the following properties. They are plain values, but because Formisch wires into React's rendering, your components re-render when they change. - `props`: JSX props to spread onto your input element (includes event handlers, ref callback, name attribute, and `autoFocus` to automatically focus fields with errors). - `input`: The current input value of the field. - `errors`: The current array of error messages if validation fails. - `isTouched`: Whether the field has been touched. - `isDirty`: Whether the current input differs from the initial input. - `isValid`: Whether the field passes all validation rules. - `onChange`: Sets the field input value programmatically. Use this when the field cannot be connected to a native HTML element (e.g., complex custom inputs or component libraries that don't expose the underlying element). #### Next steps Now that you know how to add fields to your form, continue to the input components guide to learn about creating reusable input components for your forms. ### Input components To make your code more readable, we recommend that you develop your own input components if you are not using a prebuilt UI library. There you can encapsulate logic to display error messages, for example. > If you're already a bit more experienced, you can use the input components we developed for our playground as a starting point. You can find the code in our GitHub repository here. #### Why input components? Currently, your fields might look something like this: ```tsx {(field) => (
{field.errors &&
{field.errors[0]}
}
)}
``` If CSS and a few more functionalities are added here, the code quickly becomes confusing. In addition, you have to rewrite the same code for almost every form field. Our goal is to develop a `TextInput` component so that the code ends up looking like this: ```tsx {(field) => ( )} ``` #### Create an input component In the first step, you create a new file for the `TextInput` component and, if you use TypeScript, define its properties. ```tsx import type { FieldElementProps } from '@formisch/react'; interface TextInputProps extends FieldElementProps { type: 'text' | 'email' | 'tel' | 'password' | 'url' | 'date'; label?: string; placeholder?: string; input: string | undefined; errors: [string, ...string[]] | null; required?: boolean; } ``` ##### Component function In the next step, add the component function to the file. We can destructure props directly and spread the remaining props. ```tsx import type { FieldElementProps } from '@formisch/react'; interface TextInputProps extends FieldElementProps { /* ... */ } export function TextInput({ label, input, errors, ...props }: TextInputProps) { // Component implementation } ``` ##### JSX code After that, you can add the JSX code to the return statement. ```tsx import type { FieldElementProps } from '@formisch/react'; interface TextInputProps extends FieldElementProps { /* ... */ } export function TextInput({ label, input, errors, ...props }: TextInputProps) { const { name, required } = props; return (
{label && ( )} {errors &&
{errors[0]}
}
); } ``` ##### Next steps You can now build on this code and add CSS, for example. You can also follow the procedure to create other components such as `Checkbox`, `Slider`, `Select` and `FileInput`. ##### Final code Below is an overview of the entire code of the `TextInput` component. ```tsx import type { FieldElementProps } from '@formisch/react'; interface TextInputProps extends FieldElementProps { type: 'text' | 'email' | 'tel' | 'password' | 'url' | 'date'; label?: string; placeholder?: string; input: string | undefined; errors: [string, ...string[]] | null; required?: boolean; } export function TextInput({ label, input, errors, ...props }: TextInputProps) { const { name, required } = props; return (
{label && ( )} {errors &&
{errors[0]}
}
); } ``` #### Using component libraries When using component libraries that don't expose their underlying native HTML elements, you cannot spread `field.props` directly. Instead, use `field.onChange` to update the value programmatically: ```tsx import { DatePicker } from 'some-component-library'; {(field) => ( field.onChange(newDate)} /> )} ; ``` The `field.onChange` method updates the field value and triggers validation. For more details, see the controlled fields guide. #### Next steps Now that you know how to create reusable input components, continue to the handle submission guide to learn how to process form data when the user submits the form. ### Handle submission Now your first form is almost ready. There is only one little thing missing and that is the data processing when the form is submitted. #### Submit event To process the values on submission, you need to pass a function to the `onSubmit` property of the `Form` component. The first parameter passed to the function contains the validated form values. ```tsx import { Field, Form, useForm } from '@formisch/react'; import type { SubmitHandler } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function App() { const loginForm = useForm({ schema: LoginSchema, }); const submitForm: SubmitHandler = (values) => { // Process the validated form values console.log(values); // { email: string, password: string } }; return (
{/* Form fields will go here */}
); } ``` The `SubmitHandler` type ensures type safety for your submission handler, automatically inferring the types of validated values from your schema. If you need access to the submit event, use `SubmitEventHandler` instead. ##### Prevent default When the form is submitted, `event.preventDefault()` is executed by default to prevent the window from reloading so that the values can be processed directly in the browser and the state of the form is preserved. ##### Loading state While the form is being submitted, you can use `loginForm.isSubmitting` to display a loading animation and disable the submit button: ```tsx ``` The form store also provides other reactive properties like `isSubmitted`, `isValidating`, `isTouched`, `isDirty`, `isValid`, and `errors` for tracking form state. Note that `errors` only contains validation errors at the root level of the form — to get all errors from all fields, use the `getAllErrors` method. ##### Async submission The submit handler can be asynchronous, allowing you to perform API calls or other async operations: ```tsx const submitForm: SubmitHandler = async (values) => { try { const response = await fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(values), }); if (response.ok) { // Handle successful login console.log('Login successful!'); } else { // Handle error console.error('Login failed'); } } catch (error) { console.error('Error during submission:', error); } }; ``` ##### Trigger submission If you want to trigger submission programmatically from outside the form, you can use the `submit` method. It calls `requestSubmit()` on the underlying form element: ```tsx import { submit } from '@formisch/react'; ; ``` #### Submit without \
In some cases, you may not be able to wrap your fields in a `` element — for example, when your form is rendered inside another form, since nesting `` elements is invalid HTML. In these situations, you can use the `handleSubmit` method directly to submit the form programmatically without the `Form` component. The returned function accepts no arguments and can be called from anywhere — for example, from a button's `onClick` handler: ```tsx import { Field, handleSubmit, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function App() { const loginForm = useForm({ schema: LoginSchema, }); const submitForm = handleSubmit(loginForm, (values) => { // Process the validated form values console.log(values); }); return (
{/* Form fields without a wrapper */}
); } ``` #### Next steps Congratulations! You've learned the core concepts of building forms with Formisch. To learn more about advanced features, check out the form methods guide to discover how to programmatically control your forms. ### Form methods To retrieve the values of your form or to make changes to the form, Formisch provides you with several methods. These apply either to the entire form or to individual fields. #### Reading values To retrieve values from your form, you can use: - `getInput`: Get the current value of a specific field - `getErrors`: Get error messages for a specific field - `getAllErrors`: Get all error messages across the entire form Formisch plugs into React's render cycle, so reading values with these methods inside components stays reactive. When the form state changes, components that rely on these values automatically re-render without manual subscriptions. #### Dirty state To work with the dirty state of your form, Formisch provides three methods: - `getDirtyInput`: Get the dirty parts of the form input - `getDirtyPaths`: Get the paths of dirty fields - `pickDirty`: Filter an externally-supplied value down to its dirty parts using the form's dirty mask See the dirty fields guide for when to reach for each. #### Setting values To manually update form values or errors, use: - `setInput`: Manually update the value of a specific field - `setErrors`: Manually set error messages for a specific field > When you have access to a field store (from `useField` or `Field`), you can use `field.onChange(value)` to update the value directly. This is especially useful for custom inputs or component libraries that don't expose native HTML elements. > If you need to update the form because the initial data has changed (e.g., remote data was refreshed), use `reset` with a new `initialInput` instead of `setInput`. The `reset` method properly reinitializes the form state, while `setInput` only changes the current input values without updating the initial state. #### Form control To control the form programmatically, use: - `handleSubmit`: Create a submit event handler that validates the form and calls your handler on success - `reset`: Reset the form to its initial state or update initial values - `validate`: Manually trigger validation for the entire form or specific fields - `submit`: Programmatically trigger form submission - `focus`: Focus on a specific field #### Array operations For working with field arrays, Formisch provides: - `insert`: Insert a new item into a field array - `remove`: Remove an item from a field array - `move`: Move an item to a different position in a field array - `swap`: Swap two items in a field array - `replace`: Replace an item in a field array #### API design All methods in Formisch follow a consistent API pattern: the first parameter is always the form store, and the second parameter (if necessary) is always a config object. This design makes the API flexible and consistent across all methods. Once you understand this pattern, you basically understand the entire API design. Here are some examples: ```tsx // Get the value of a field const emailInput = getInput(loginForm, { path: ['email'] }); // Reset the form with new initial values reset(loginForm, { initialInput: { email: '', password: '' } }); // Move an item in a field array move(loginForm, { path: ['items'], from: 0, to: 3 }); ``` #### API reference You can find detailed documentation for each method in our API reference. ## Advanced guides (guides) ### Special inputs As listed in our features, the library supports all native HTML form fields. This includes the HTML `` element. > In our playground you can take a look at such fields and test them out. #### Checkbox A simple checkbox represents a boolean and is `true` when checked or `false` otherwise. ```tsx {(field) => ( )} ``` However, you can also use multiple checkboxes to represent an array of strings. For this you simply have to add the `value` attribute to the HTML `` element. ```tsx { [ { label: 'Bananas', value: 'bananas' }, { label: 'Apples', value: 'apples' }, { label: 'Grapes', value: 'grapes' }, ].map(({ label, value }) => ( {(field) => ( )} )); } ``` #### Radio A group of radio buttons, while similar to an array of checkboxes, will only allow you to select one of the options based on which button is checked. ```tsx {(field) => ( <> {[ { label: 'Red', value: 'red' }, { label: 'Green', value: 'green' }, { label: 'Blue', value: 'blue' }, ].map(({ label, value }) => ( ))} )} ``` #### Select An HTML ` {[ { label: 'React', value: 'react' }, { label: 'Solid', value: 'solid' }, { label: 'Qwik', value: 'qwik' }, ].map(({ label, value }) => ( ))} )} ``` However, if you set the `multiple` attribute, multiple options can be selected making the field represent an array of strings. ```tsx {(field) => ( {/* Set "multiple" to "true" */} )} ``` #### File For the HTML `` element it works similar to the HTML `} ``` With the `multiple` attribute, users can select multiple files: ```tsx {(field) => } ``` ### Controlled fields By default, all form fields are uncontrolled because that's the default behavior of the browser. For a simple login or contact form this is quite sufficient. #### Why controlled? As soon as your forms become more complex, for example you set initial values or change the values of a form field via `setInput`, it becomes necessary that you control your fields yourself. For example, depending on which HTML form field you use, you may need to set the `value`, `checked` or `selected` attributes. ##### Text input example For a text input field you simply add the `value` attribute and pass the field's input value: ```tsx {(field) => } ``` ##### Exception for files The HTML `` element is an exception because it cannot be controlled. However, you have the possibility to control the UI around it. For inspiration you can use the code of our `FileInput` component from our playground. #### Numbers and dates Fields defined with a `v.number()` or `v.date()` schema need extra steps to be controlled, because the `` element natively understands only strings as value. ##### Number input example An `` only reads and writes strings. So if you spread `field.props` onto it, `field.input` holds a string like `"123"`, even though it is typed as `number`. To store a real number, override the change handler with one that converts the value via `valueAsNumber` and forwards it to `field.onChange`. You also have to handle `NaN`. While typing a floating point number, the value can briefly be `NaN`, for example right after typing `1.`. If you don't catch this for the displayed value, the input is cleared. It is best to encapsulate both in a separate component as described in the input components guide. ```tsx import type { FieldElementProps } from '@formisch/react'; import { useMemo, useRef } from 'react'; interface NumberInputProps extends Omit { label?: string; placeholder?: string; input: number | undefined; errors: [string, ...string[]] | null; required?: boolean; onChange: (value: number | undefined) => void; } export function NumberInput({ label, input, errors, name, onChange, ...inputProps }: NumberInputProps) { const prevValue = useRef(); // Get value, keeping previous value if NaN const value = useMemo(() => { if (typeof input === 'number' && !Number.isNaN(input)) { prevValue.current = input; return input; } return prevValue.current; }, [input]); return (
{label && } onChange( event.currentTarget.value === '' ? undefined : event.currentTarget.valueAsNumber ) } aria-invalid={!!errors} aria-errormessage={`${name}-error`} /> {errors &&
{errors[0]}
}
); } ``` Pass `field.onChange` after spreading `field.props` so it overrides the native handler. ```tsx {(field) => ( )} ``` ##### Date input example The same applies to dates. An `` works with `yyyy-mm-dd` strings, while you usually want to store a `Date`. So you convert in both directions: format the `Date` for display, and parse the entered string back with `valueAsDate` before storing it. ```tsx import type { FieldElementProps } from '@formisch/react'; import { useMemo } from 'react'; interface DateInputProps extends Omit { label?: string; placeholder?: string; input: Date | undefined; errors: [string, ...string[]] | null; required?: boolean; onChange: (value: Date | undefined) => void; } export function DateInput({ label, input, errors, name, onChange, ...inputProps }: DateInputProps) { // Transform date to string const value = useMemo( () => input && !Number.isNaN(input.getTime()) ? input.toISOString().split('T', 1)[0] : '', [input] ); return (
{label && } onChange(event.currentTarget.valueAsDate ?? undefined) } aria-invalid={!!errors} aria-errormessage={`${name}-error`} /> {errors &&
{errors[0]}
}
); } ``` As with the number input, pass `field.onChange` after the spread to override the native handler. ```tsx {(field) => ( )} ``` #### Custom inputs and component libraries Some component libraries don't expose the underlying native HTML element, which means you cannot spread `field.props` onto them. For these cases, use `field.onChange` to set the value programmatically. ```tsx import { DatePicker } from 'some-component-library'; {(field) => ( field.onChange(newDate)} /> )} ; ``` This is useful for: - **Component libraries** that wrap native elements without exposing them - **Complex custom inputs** like date pickers, rich text editors, or color pickers The `field.onChange` method updates the field value and triggers validation, just like a native input would. #### Next steps Now that you understand controlled fields, you can explore more advanced topics like nested fields and field arrays to handle complex form structures. ### Nested fields To add a little more structure to a complex form or to match the values of the form to your database, you can also nest your form fields in objects as deep as you like. #### Schema definition For example, in the schema below, the first and last name are grouped under the object with the key `name`. ```tsx import * as v from 'valibot'; const ContactSchema = v.object({ name: v.object({ first: v.pipe(v.string(), v.nonEmpty()), last: v.pipe(v.string(), v.nonEmpty()), }), email: v.pipe(v.string(), v.email()), message: v.pipe(v.string(), v.nonEmpty()), }); ``` #### Path array When creating a nested field, use an array with multiple elements for the `path` property to refer to the nested field. The array represents the path through the nested structure. ```tsx {(field) => } ``` If you're using TypeScript, your editor will provide autocompletion for the path based on your schema structure. #### Deep nesting You can nest objects as deeply as needed. Simply extend the path array with additional keys: ```tsx const ProfileSchema = v.object({ user: v.object({ address: v.object({ street: v.string(), city: v.string(), country: v.string(), }), }), }); // Access deeply nested field {(field) => } ; ``` #### Type safety The path array is fully type-safe. TypeScript will validate that each element in your path corresponds to a valid key in your schema structure, providing autocompletion and compile-time errors if you reference a non-existent path. ### Dirty fields When a user edits a form, Formisch tracks which fields have changed since they were initialized. The library exposes three methods for working with that dirty state: `getDirtyInput`, `getDirtyPaths`, and `pickDirty`. This guide explains what each one is for, when to reach for it, and why `pickDirty` exists alongside the others. #### What "dirty" means A field is dirty when its current input differs from its start input. The form starts clean. As the user types, only the fields they touch flip to dirty. Resetting a field (or resetting the form with a new `initialInput`) clears the dirty flag. > The dirty flag is per-field. Editing a deeply nested value does not flip its ancestors' flags. The dirty-extraction methods walk the tree internally to find dirty descendants, which is why all three methods do the same kind of work under the hood. #### The three methods ##### `getDirtyInput` Returns the dirty subtree of the form's input. Use it when you want to ship the values the user typed — typically for a PATCH endpoint that accepts the same shape as your form input. ```tsx import { Form, getDirtyInput, type SubmitHandler, useForm, } from '@formisch/react'; import * as v from 'valibot'; const UserSchema = v.object({ name: v.pipe(v.string(), v.nonEmpty()), email: v.pipe(v.string(), v.email()), }); export default function EditProfile({ user }) { const profileForm = useForm({ schema: UserSchema, initialInput: user, }); const onSubmit: SubmitHandler = async () => { const dirty = getDirtyInput(profileForm); if (dirty) { await api.patchUser(user.id, dirty); } }; return ( {/* fields */} ); } ``` If only `email` was edited, `dirty` is `{ email: 'new@example.com' }`. If nothing was edited, it is `undefined`. Because dirty state is bound to the form input, `getDirtyInput` always returns the raw user input. Schema transformations such as `v.trim()` or `v.toNumber()` are not applied to the returned values. When you need the validated and transformed output instead, reach for `pickDirty` (see below). ##### `getDirtyPaths` Returns a list of paths to dirty fields. Use it for logging, telemetry, or driving a custom walker over the form's dirty state. ```tsx import { getDirtyPaths } from '@formisch/react'; const dirtyPaths = getDirtyPaths(profileForm); // e.g. [['email'], ['user', 'name']] ``` Arrays are atomic: only the array's own path is returned, never the paths of individual items. ##### `pickDirty` Filters a user-supplied value down to its dirty parts using the form's dirty mask. Use it when you have a separately-derived value — most commonly the validated and transformed output from a submit handler — and you want only its dirty parts. ```tsx import { pickDirty, type SubmitHandler } from '@formisch/react'; const onSubmit: SubmitHandler = async (output) => { const dirty = pickDirty(profileForm, { from: output }); if (dirty) { await api.update(dirty); } }; ``` #### Why `pickDirty` exists Dirty state is tracked against the form **input** — the raw values the user typed. But Valibot schemas can transform that input into a different output shape before it reaches your submit handler: ```tsx import * as v from 'valibot'; const Schema = v.object({ name: v.pipe(v.string(), v.trim()), age: v.pipe(v.string(), v.toNumber()), }); ``` After validation, `output.name` has whitespace trimmed and `output.age` is a number. `getDirtyInput` would give you the raw strings, because the dirty state is bound to the form input — not to the validated output. `pickDirty(form, { from: output })` is the bridge: it walks the form's dirty tree as a structural mask and reads the corresponding values from the output you supply. The result preserves the transformed types. ```tsx import { pickDirty, type SubmitHandler } from '@formisch/react'; const onSubmit: SubmitHandler = async (output) => { // output.age is a number — pickDirty preserves that. const dirty = pickDirty(form, { from: output }); if (dirty) { await api.update(dirty); } }; ``` If the schema reshapes the output entirely — for example, by combining several input fields into a single output value — `pickDirty` returns `undefined` because the shape no longer aligns with the form's input shape. #### Atomic arrays All three methods treat arrays as atomic. When any descendant of an array is dirty, the full array is returned (or its own path, for `getDirtyPaths`). The methods never produce sparse arrays. Sparse arrays don't round-trip safely. Serializers compact them, `JSON.stringify` writes `null` for holes, and indices lose positional meaning. Returning the full current array preserves order and lets the server treat the array as a complete replacement. This differs from objects, where clean keys are omitted. Objects model keyed dictionaries; arrays model ordered sequences. #### Common patterns The snippets below assume `form` is your form store (the result of `useForm`). ##### Skip submission when nothing changed The form's `isDirty` flag is the cheapest way to ask "is anything dirty?" — it short-circuits on the first dirty field it finds and doesn't allocate. Use it when all you need is the yes/no answer. If you actually consume the output of `getDirtyInput`, `getDirtyPaths`, or `pickDirty`, call that method directly — its return value already signals "nothing dirty", so checking `form.isDirty` first would just walk the tree twice. ```tsx import type { SubmitHandler } from '@formisch/react'; const onSubmit: SubmitHandler = async (output) => { if (!form.isDirty) { return; } await api.update(output); }; ``` ##### Send only the dirty raw input ```tsx import { getDirtyInput } from '@formisch/react'; const dirty = getDirtyInput(form); if (dirty) { await api.patch(dirty); } ``` ##### Send only the dirty validated output ```tsx import { pickDirty, type SubmitHandler } from '@formisch/react'; const onSubmit: SubmitHandler = async (output) => { const dirty = pickDirty(form, { from: output }); if (dirty) { await api.update(dirty); } }; ``` #### Performance All three methods walk the form's field tree and call `getFieldBool` recursively to skip clean subtrees. Cost is effectively linear in field count for typical balanced forms (shallow and wide) and degrades toward `O(N²)` for deeply nested trees with few siblings at each level. Call these methods from submit or blur handlers — not from tight reactive loops on every keystroke. For very large or deeply nested forms (thousands of fields), profile before binding them to high-frequency events. ### Field arrays A somewhat more special case are dynamically generated form fields based on an array. Since adding, removing, swapping and moving items can be a big challenge here, the library provides the `FieldArray` component which, in combination with various methods, makes it very easy for you to create such forms. > In our playground you can take a look at a form with a field array and test them out. #### Create a field array ##### Schema definition In the following example we create a field array for a todo form with the following schema: ```tsx import * as v from 'valibot'; const TodoFormSchema = v.object({ heading: v.pipe(v.string(), v.nonEmpty()), todos: v.pipe( v.array( v.object({ label: v.pipe(v.string(), v.nonEmpty()), deadline: v.pipe(v.string(), v.nonEmpty()), }) ), v.nonEmpty(), v.maxLength(10) ), }); ``` ##### FieldArray component To dynamically generate the form fields for the todos, you use the `FieldArray` component in combination with React's `Array.map()`. The field array provides an `items` array of unique string identifiers which are used to detect when an item is added, moved, or removed. ```tsx import { Field, FieldArray, Form, useForm } from '@formisch/react'; export default function TodoPage() { const todoForm = useForm({ schema: TodoFormSchema, initialInput: { heading: '', todos: [{ label: '', deadline: '' }], }, }); return (
console.log(output)}> {(field) => ( <> {field.errors &&
{field.errors[0]}
} )}
{(fieldArray) => (
{fieldArray.items.map((item, index) => (
{(field) => ( <> {field.errors &&
{field.errors[0]}
} )}
{(field) => ( <> {field.errors &&
{field.errors[0]}
} )}
))} {fieldArray.errors &&
{fieldArray.errors[0]}
}
)}
); } ``` ##### Path array with index As with nested fields, you use an array for the `path` property. The key difference is that you include the index from the `map()` function to specify which array item you're referencing. This ensures the paths update correctly when items are added, moved, or removed. ```tsx {(field) => } ``` #### Use array methods Now you can use the `insert`, `move`, `remove`, `replace`, and `swap` methods to make changes to the field array. These methods automatically take care of rearranging all the fields. ##### Insert method Add a new item to the array: ```tsx import { insert } from '@formisch/react'; ; ``` The `at` option can be used to specify the index where the item should be inserted. If not provided, the item is added to the end of the array. ##### Remove method Remove an item from the array: ```tsx import { remove } from '@formisch/react'; ; ``` ##### Move method Move an item from one position to another: ```tsx import { move } from '@formisch/react'; ; ``` ##### Swap method Swap two items in the array: ```tsx import { swap } from '@formisch/react'; ; ``` ##### Replace method Replace an item with new data: ```tsx import { replace } from '@formisch/react'; ; ``` #### Nested field arrays If you need to nest multiple field arrays, the path array syntax makes it straightforward. Simply extend the path with additional array indices: ```tsx const NestedSchema = v.object({ categories: v.array( v.object({ name: v.string(), items: v.array( v.object({ title: v.string(), }) ), }) ), }); {(categoryArray) => ( <> {categoryArray.items.map((categoryItem, categoryIndex) => (
{(field) => } {(itemArray) => ( <> {itemArray.items.map((item, itemIndex) => ( {(field) => } ))} )}
))} )}
; ``` You can nest field arrays as deeply as you like. You will also find a suitable example of this in our playground. #### Field array validation As with fields, you can validate field arrays using Valibot's array validation functions. For example, to limit the length of the array: ```tsx const TodoFormSchema = v.object({ todos: v.pipe( v.array( v.object({ label: v.string(), deadline: v.string(), }) ), v.minLength(1), v.maxLength(10) ), }); ``` The validation errors for the field array itself are available in `fieldArray.errors` and can be displayed alongside the array. ### TypeScript Since the library is written in TypeScript and we put a lot of emphasis on the development experience, you can expect maximum TypeScript support. Types are automatically inferred from your Valibot schemas, providing type safety throughout your forms. #### Type inference Formisch uses Valibot's type inference to automatically derive TypeScript types from your schemas. You don't need to define separate types—they're inferred automatically. ```tsx import { Field, Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function LoginPage() { const loginForm = useForm({ schema: LoginSchema, }); // TypeScript knows the form structure from the schema // loginForm is of type FormStore return (
{ // output is fully typed based on LoginSchema console.log(output.email); // ✓ Type-safe console.log(output.username); // ✗ TypeScript error }} > {/* Form fields */}
); } ``` ##### Input and output types Valibot schemas can have different input and output types when using transformations. Formisch provides proper typing for both. ```tsx import { Field, Form, useForm } from '@formisch/react'; import * as v from 'valibot'; const ProfileSchema = v.object({ age: v.pipe( v.string(), // Input type: string (from HTML input) v.transform((input) => Number(input)), // Output type: number v.number() ), birthDate: v.pipe( v.string(), // Input type: string (ISO date string) v.transform((input) => new Date(input)), // Output type: Date v.date() ), }); export default function ProfilePage() { const profileForm = useForm({ schema: ProfileSchema, }); return (
{ // output is: { age: number; birthDate: Date } console.log(output.age); // number console.log(output.birthDate); // Date }} > {(field) => ( // field.input is string )} {(field) => ( // field.input is string )}
); } ``` ##### Type-safe paths Field paths are fully type-checked. TypeScript will provide autocompletion and catch invalid paths at compile time. ```tsx const UserSchema = v.object({ profile: v.object({ name: v.object({ first: v.string(), last: v.string(), }), email: v.string(), }), }); const userForm = useForm({ schema: UserSchema }); // ✓ Valid paths - TypeScript provides autocompletion // ✗ Invalid paths - TypeScript error ``` #### Type-safe props To pass your form to another component via props, you can use the `FormStore` type along with your schema type to get full type safety. ```tsx import { Form, type FormStore, useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); export default function LoginPage() { const loginForm = useForm({ schema: LoginSchema, }); return ; } type FormContentProps = { of: FormStore; }; function FormContent(props: FormContentProps) { return (
console.log(output)}> {/* Form fields */}
); } ``` #### Generic field components You can create generic field components with proper TypeScript typing using the `FormStore` type with Valibot's `GenericSchema`. ```tsx import { type FormStore, useField } from '@formisch/react'; import type { FunctionComponent } from 'react'; import * as v from 'valibot'; type EmailInputProps = { of: FormStore>; }; const EmailInput: FunctionComponent = (props) => { const field = useField(props.of, { path: ['email'] }); return (
{field.errors &&
{field.errors[0]}
}
); }; ``` The `v.GenericSchema<{ email: string }>` type ensures that the form passed to `EmailInput` must have an `email` field of type `string`. TypeScript will catch any type mismatches at compile time. #### Available types Most types you need can be imported from `@formisch/react`. You can find all available types in our API reference. - `FormStore` - The form store type - `FieldStore` - The field store type - `FieldArrayStore` - The field array store type - `ValidPath` - Type for valid field paths - `ValidArrayPath` - Type for valid array field paths - `FormSchema` - Form schema type required at the root - `Schema` - Base schema type from Valibot - `SubmitHandler` - Type for submit handlers without the event - `SubmitEventHandler` - Type for submit handlers with the event ### Architecture You don't need to read this guide to use Formisch. It's here for people who want to understand why the bundle stays small, why updates are fine-grained, and how the same library can support React, SolidJS, Vue, Svelte, Preact and Qwik without forking the codebase. Each of those properties falls out of a few deliberate architectural choices. #### Three packages, three responsibilities Formisch is structured as three packages, each with a clear role: - [`@formisch/core`](https://github.com/open-circle/formisch/tree/main/packages/core) is the framework-agnostic foundation. It contains the form and field store types, the recursive store builder that mirrors your Valibot schema, and the validation orchestration. - [`@formisch/methods`](https://github.com/open-circle/formisch/tree/main/packages/methods) exposes the form operations as standalone, tree-shakeable functions: `setInput`, `validate`, `reset`, `insert`, `move`, `focus` and so on. Each method lives in its own file and only imports the core helpers it actually needs. - [`@formisch/react`](https://github.com/open-circle/formisch/tree/main/frameworks/react) is the thin user-facing layer. It provides the `useForm`, `useField` and `useFieldArray` hooks, the `
`, `` and `` components, and re-exports every method from `@formisch/methods` so you only import from a single package. ``` @formisch/react ├─ useForm, , , … (React-specific reactive layer) └─ re-exports @formisch/methods/react (focus, reset, validate, …) └─ @formisch/core/react (createFormStore, types, signals) └─ framework adapter (createSignal, batch, untrack, createId) ``` The modular architecture is what makes Formisch tree-shakeable. The core stays small, and every additional capability (`setInput`, `validate`, `reset`, `insert`, `move`, `focus` and the rest) is exported as its own function. A form that only imports `useForm`, `` and `` ships nothing else, even though `@formisch/react` re-exports every method. #### One core, one adapter per framework The core package is framework-agnostic, but it still needs _some_ reactivity primitive to build on. Formisch handles this by providing a subpath export for every supported framework (`@formisch/core/react`, `@formisch/core/solid`, `@formisch/core/vue`, …), all built from the same source. The only file that differs between them [is a small adapter](https://github.com/open-circle/formisch/blob/main/packages/core/src/framework/index.ts) that exports four functions: `createSignal`, `batch`, `untrack` and `createId`. The swap happens at build time, not at runtime. A small [rolldown plugin](https://github.com/open-circle/formisch/blob/main/packages/core/tsdown.config.ts) sits in front of import resolution: whenever the bundler resolves an import of `./framework/index.ts`, the plugin looks for a sibling `./framework/index.react.ts` (or `.solid.ts`, `.vue.ts`, …) and, if it exists, redirects the import there. The build runs once per framework, and each run produces a self-contained bundle with the framework-specific adapter inlined. Since React doesn't have a native signal primitive, [the React adapter](https://github.com/open-circle/formisch/blob/main/packages/core/src/framework/index.react.ts) implements a small pub/sub system from scratch that exposes the `Signal` shape: ```ts export function createSignal(value: T): Signal { const subscribers = new Set(); return { get value() { if (listener) { subscribers.add(listener); listener[1].add(subscribers); } return value; }, set value(newValue: T) { if (newValue !== value) { value = newValue; // notify subscribers … } }, }; } ``` A companion [`useSignals`](https://github.com/open-circle/formisch/blob/main/frameworks/react/src/hooks/useSignals/useSignals.ts) hook in the React wrapper registers your component as a listener and forces a re-render when any signal it read changes. For frameworks that already have native signals (Solid, Preact, Vue, Svelte, Qwik), the adapter is a thin wrapper around the framework's own primitive, sometimes just a single re-export. Every other file in `@formisch/core` only ever imports `createSignal`, `batch`, `untrack` and `createId`, never a framework directly. That's why the same [`createFormStore`](https://github.com/open-circle/formisch/blob/main/packages/core/src/form/createFormStore/createFormStore.ts) code path can power every framework binding without a single conditional. This is what makes Formisch different from most framework-agnostic libraries. The usual approach is to ship a runtime abstraction (a custom store, an observer protocol, a subscription layer) that lives in the bundle and has to be bridged into each framework. Formisch ships nothing like that. Where the framework has native signals, Formisch uses them directly; where it doesn't, the adapter is just enough pub/sub to drive re-renders. Either way, there is no extra layer between your form state and the framework's reactivity, and your bundle pays no overhead for portability. In React, form state lives in the same minimal pub/sub the wrapper already needs to subscribe components, with no second abstraction on top. That Formisch is framework-agnostic is not a trade-off you make. It's a benefit you get. A bug surfaced by a Svelte user is a bug fixed for React, Solid, Vue and everyone else. An improvement to the recursive store builder, the validation orchestration or any individual method lands across every binding at once. There is one library to maintain, not one per framework, and every community pulls the rest forward. #### State lives in signals Every piece of reactive state in Formisch is a [`Signal`](https://github.com/open-circle/formisch/blob/main/packages/core/src/types/signal/signal.ts) with the same minimal interface: ```ts interface Signal { get value(): T; set value(nextValue: T): void; } ``` Reads track, writes notify. There is no central store object that gets diffed and no equality check on the consumer side. Each field carries its own signals for `errors`, `isTouched`, `isDirty`, plus an `input` signal for value fields and a `children` collection for arrays and objects. When you call `setInput(form, { path: ['email'], input: 'a@b.c' })`, only the `input` signal of that one field is written, so only the components that read that one signal (typically a single ``) re-render. This is the source of the fine-grained reactivity. The shape of the store is pre-allocated at form creation, matching the shape of your Valibot schema, so methods never have to look up paths in a generic object. They walk a typed tree of stores and update individual signals. #### What happens when you call `useForm` When you call `useForm`, three layers cooperate to produce the form store you receive. ```tsx import { useForm } from '@formisch/react'; import * as v from 'valibot'; const LoginSchema = v.object({ email: v.pipe(v.string(), v.email()), password: v.pipe(v.string(), v.minLength(8)), }); function LoginForm() { const loginForm = useForm({ schema: LoginSchema }); // … } ``` First, the [React wrapper](https://github.com/open-circle/formisch/blob/main/frameworks/react/src/hooks/useForm/useForm.ts) hands the configuration to the core function [`createFormStore`](https://github.com/open-circle/formisch/blob/main/packages/core/src/form/createFormStore/createFormStore.ts) inside a `useMemo`, together with a parse closure that captures your schema: ```ts const internalFormStore = useMemo( () => createFormStore(config, (input) => v.safeParseAsync(config.schema, input)), [] ); ``` Next, `createFormStore` calls [`initializeFieldStore`](https://github.com/open-circle/formisch/blob/main/packages/core/src/field/initializeFieldStore/initializeFieldStore.ts), which walks your Valibot schema recursively and builds the internal store hierarchy: - A `v.object(...)` becomes an `InternalObjectStore` with a `children` record keyed by field name. - A `v.array(...)` or `v.tuple(...)` becomes an `InternalArrayStore` with a `children` list and its own `initialInput`, `startInput` and `input` signals so it can track structural changes. - A leaf like `v.string()` or `v.number()` becomes an `InternalValueStore` with an `input` signal that holds the current field value. - Wrapper schemas such as `v.optional`, `v.nullable`, `v.nonNullable` and `v.lazy` are unwrapped and recursed into. - `v.union`, `v.variant` and `v.intersect` initialize every option into the same store, which is what lets you address discriminated fields with a single field path. At every level, the same three signals are created: `errors`, `isTouched` and `isDirty`. Once the field tree is built, three more signals are added to the form root: `isSubmitting`, `isSubmitted` and `isValidating`. Finally, the React wrapper builds the public form store you actually receive. It's a small object that sits on top of the internal store: form-level signals are exposed through getters that read `internalFormStore.isSubmitting.value` and friends, while derived state like `isTouched`, `isDirty` and `isValid` is computed on demand from the field tree. The whole object is memoized so it survives re-renders: ```ts return useMemo( () => ({ [INTERNAL]: internalFormStore, get isSubmitting() { return internalFormStore.isSubmitting.value; }, get isTouched() { return getFieldBool(internalFormStore, 'isTouched'); }, // … }), [internalFormStore] ); ``` At the very top of the hook body, before any of this, the wrapper calls `useSignals()` to bridge the signals into React's render cycle: it registers the component as a listener so any signal read by the getters above will trigger a re-render when it changes. The internal store is tucked away behind the [`INTERNAL`](https://github.com/open-circle/formisch/blob/main/packages/core/src/values.ts) symbol. Methods like `setInput(form, …)` reach in via `form[INTERNAL]` to mutate signals, while your code only sees the public form store. This separation is what keeps the public API small and stable even as the internal shape evolves. #### Why this design pays off Bundle size is the obvious payoff. The others are why the design is worth talking about: - **Small bundle size.** Because methods are individual modules re-exported from [`@formisch/react`](https://github.com/open-circle/formisch/tree/main/frameworks/react), a form that uses only `useForm` and `` never pulls in `validate`, `reset`, `insert` or the other operations. Tree-shaking gets to do real work. - **Fine-grained reactivity.** The store shape is pre-allocated at form creation, with one signal per piece of state. Methods write `.value` directly, and only the components subscribed to that specific signal re-render. Updating one field does not invalidate the rest. - **Framework portability.** The entire library is parameterized over a four-function adapter. Adding a new framework means writing a small adapter that maps `createSignal`, `batch`, `untrack` and `createId` onto its primitives. - **Type safety.** Your Valibot schema is the single source of truth. It drives both runtime parsing and the inferred TypeScript types for paths, inputs and outputs, so there is no second declaration to keep in sync. #### Further reading To see how these design choices stack up against Felte and TanStack Form, head to the comparison guide. For a closer look at how Valibot's inference flows into your editor, see TypeScript. And if you want to read the recursive walker, the adapter implementations, or how individual methods are written, the full source is on [GitHub](https://github.com/open-circle/formisch). ## Hooks (API) ### useForm Creates a reactive form store from a form configuration. The form store manages form state and provides reactive properties. ```ts const form = useForm(config); ``` #### Generics - `TSchema` #### Parameters - `config` ##### Explanation `useForm` creates a reactive form store that manages form state using the provided Valibot schema. Validation runs when a field is blurred or the form is submitted by default, but this can be customized with the `validate` and `revalidate` options. #### Returns - `form` #### Related The following APIs can be combined with `useForm`. ##### Hooks ##### Components ##### Methods ### useField Creates a reactive field store of a specific field within a form store. ```ts const field = useField(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation With `useField` you create a reactive field store for a specific field path within your form. The field store provides reactive access to the field's input value, validation errors, touched state, and more. It also includes a `props` object that you can spread onto an HTML input or textarea element to automatically handle user interactions like focus, blur, and input events. #### Returns - `field` #### Related The following APIs can be combined with `useField`. ##### Hooks ##### Components ##### Methods ### useFieldArray Creates a reactive field array store of a specific field array within a form store. ```ts const fieldArray = useFieldArray(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation With `useFieldArray` you create a reactive field array store for a specific array field within your form. The field array store provides reactive access to the array items (by their IDs), validation errors, touched state, and more. This is particularly useful when working with dynamic arrays of fields that users can add or remove. #### Returns - `fieldArray` #### Related The following APIs can be combined with `useFieldArray`. ##### Hooks ##### Components ##### Methods ## Components (API) ### Form Form component that manages form submission and applies internal state. Wraps form element and passes submission events to the provided handler. ```tsx children ``` #### Generics - `TSchema` #### Properties - `of` - `children` - `onSubmit` ##### Explanation The `Form` component wraps a native HTML `
` element and provides form submission handling. It automatically prevents the default form submission behavior and calls the `onSubmit` handler when the form is submitted and validation succeeds. The component uses the `of` prop to reference the form store and renders the `children` elements within the form. It also sets `novalidate` on the form element to disable browser validation, as Formisch handles validation internally. #### Related ##### Hooks ##### Components ##### Methods ### Field Headless form field component that provides reactive properties and state. The field component takes a form store, path to field, and a render function that receives a field store to display field state and handle user interactions. ```tsx children ``` #### Generics - `TSchema` - `TFieldPath` #### Properties - `of` - `path` - `children` ##### Explanation The `Field` component is a headless component that doesn't render any UI itself. Instead, it provides a render prop function via the `children` prop that receives a `FieldStore` containing all the reactive state and props needed to render a form field. The component automatically handles field registration, validation, and state management through the `of` prop that references the form store. #### Related ##### Hooks ##### Components ### FieldArray Headless field array component that provides reactive properties and state for managing array fields. The field array component takes a form store, path to array field, and a render function that receives a field array store to manage array items and handle array operations. ```tsx children ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Properties - `of` - `path` - `children` ##### Explanation The `FieldArray` component is a headless component that doesn't render any UI itself. Instead, it provides a render prop function via the `children` prop that receives a `FieldArrayStore` containing all the reactive state and methods needed to manage an array of form fields. The component automatically handles array field registration, validation, and state management through the `of` prop that references the form store. #### Related ##### Hooks ##### Components ##### Methods ## Methods (API) ### focus Focuses the first input element of a field. This is useful for programmatically setting focus to a specific field, such as after validation errors or user interactions. ```ts focus(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field to focus. The `config` parameter specifies which field to focus using the `path` property, and can optionally include additional focus options. #### Related ##### Primitives ##### Methods ### getAllErrors Retrieves all error messages from all fields in the form by walking through the entire field store tree. This is useful for displaying a summary of all validation errors across the form. ```ts const errors = getAllErrors(form); ``` #### Parameters - `form` ##### Explanation The `form` parameter is the form store to retrieve errors from. The function walks through the entire field store tree to collect all validation error messages from every field. #### Returns - `result` #### Related ##### Primitives ##### Methods ### getDirtyInput Retrieves only the dirty input values of a specific field or the entire form. Object keys whose subtree contains no dirty descendant are omitted; arrays are treated as atomic and returned in full whenever any descendant is dirty. Returns `undefined` if no field in the inspected subtree is dirty. ```ts const input = getDirtyInput(form); const input = getDirtyInput(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to retrieve dirty input from. The optional `config` parameter scopes the result to a specific field path - if omitted, returns dirty input from the entire form. The returned value is a partial of the inspected input shape containing only the fields whose `isDirty` flag is set, which is useful for submitting only the values that changed since the start input. Arrays are treated as atomic — when any descendant of an array is dirty, the full current array is returned. Internally, the function walks the form's field tree and asks `getFieldBool` whether each branch contains a dirty descendant. Because that check is itself recursive, the cost is effectively linear in field count for typical balanced forms (shallow and wide) and degrades toward `O(N²)` for deeply nested trees. Call this method from submit or blur handlers rather than from tight reactive loops on large forms. #### Returns - `result` #### Related ##### Methods ### getDirtyPaths Returns a list of paths to dirty fields in the form. Object branches are recursed into; arrays are treated as atomic — when any descendant of an array is dirty, only the array's own path is returned. ```ts const paths = getDirtyPaths(form); const paths = getDirtyPaths(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to inspect. The optional `config` parameter scopes the search to a single subtree via its `path` property. Object branches are recursed into and clean keys are omitted; arrays are atomic, so when any descendant of an array is dirty, the result includes the array's own path rather than the paths of its individual items. Returns an empty array if the inspected subtree contains no dirty fields. When `path` targets a dirty array or value field, the result contains that path. Internally, the function walks the form's field tree and asks `getFieldBool` whether each branch contains a dirty descendant. Because that check is itself recursive, the cost is effectively linear in field count for typical balanced forms (shallow and wide) and degrades toward `O(N²)` for deeply nested trees. Call this method from submit or blur handlers rather than from tight reactive loops on large forms. #### Returns - `result` #### Related ##### Methods ### getErrors Retrieves error messages from the form. When called without a config, returns form-level errors. When called with a path, returns errors for that specific field. ```ts const errors = getErrors(form); const errors = getErrors(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to retrieve errors from. The optional `config` parameter specifies which errors to retrieve - either form-level errors (when omitted) or field-specific errors (when a `path` is provided). #### Returns - `result` #### Related ##### Primitives ##### Methods ### getInput Retrieves the current input value of a specific field or the entire form. Returns a partial object as not all fields may have been set. ```ts const input = getInput(form); const input = getInput(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to retrieve input from. The optional `config` parameter specifies which field to get input from - if omitted, returns input from the entire form. #### Returns - `result` #### Related ##### Primitives ##### Methods ### handleSubmit Creates a submit event handler for the form that prevents default browser submission, validates the form input, and calls the provided handler if validation succeeds. This is designed to be used with the form's onsubmit event. ```ts const result = handleSubmit(form, handler); ``` #### Generics - `TSchema` #### Parameters - `form` - `handler` ##### Explanation The `form` parameter is the form store to handle submission for. The `handler` parameter can be a `SubmitHandler` (no event) or a `SubmitEventHandler` (with event) that gets called with the validated form output if validation succeeds. #### Returns - `result` #### Related ##### Primitives ##### Methods ### insert Inserts a new item into a field array at the specified index. All items at or after the insertion point are shifted up by one index. ```ts insert(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field array. The `config` parameter specifies the path to the field array, the index where to insert the new item, and optional initial input values for the new item. #### Related ##### Primitives ##### Methods ### move Moves an item within a field array from one index to another. All items between the old and new positions are shifted accordingly. ```ts move(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field array. The `config` parameter specifies the path to the field array and the indices to move the item from and to. #### Related ##### Primitives ##### Methods ### pickDirty Picks only the dirty parts of the given value, using the form's dirty tree as a structural mask. Object keys whose subtree contains no dirty descendant are omitted; arrays are treated as atomic and returned in full whenever any descendant is dirty. Returns `undefined` if no field is dirty. Where the supplied value's shape diverges from the form's input shape — for example, a field expected to be an object holds a primitive, `null` or array — that branch is returned as-is. Useful for filtering a validated output to just the changed parts before submitting. ```ts const dirty = pickDirty(form, config); ``` #### Generics - `TSchema` - `TValue` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store providing the dirty mask. The `config` parameter must include a `from` value to filter. The value's shape is expected to match the form's input shape — wherever the shapes diverge (e.g. an object key in the form holds a primitive, `null` or array in the supplied value), that branch is returned as-is so the divergence is preserved in the result. Use this when a Valibot schema transformation produces a value of a different shape than the form's input and you want to ship only the dirty parts of that output. Internally, the function walks the form's field tree alongside the supplied value, using `getFieldBool` to skip clean subtrees and a constant-time check at each node to verify shape alignment. Because the dirty check is itself recursive, the cost is effectively linear in field count for typical balanced forms (shallow and wide) and degrades toward `O(N²)` for deeply nested trees. Call this method from submit or blur handlers rather than from tight reactive loops on large forms. #### Returns - `result` #### Related ##### Methods ### remove Removes an item from a field array at the specified index. All items after the removed index are shifted down by one. ```ts remove(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field array. The `config` parameter specifies the path to the field array and the index of the item to remove. #### Related ##### Primitives ##### Methods ### replace Replaces an item in a field array at the specified index with a new item. ```ts replace(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field array. The `config` parameter specifies the path to the field array, the index of the item to replace, and the new item values. #### Related ##### Primitives ##### Methods ### reset Resets the form or a specific field to its initial state or to a new initial input. Optionally keeps certain states like input values, touched state, or errors. ```ts reset(form); reset(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation When called without a config or with `path` set to `undefined`, the entire form is reset. When a `path` is provided, only that specific field and its nested fields are reset. By default, the form resets to its original initial input. However, you can pass a new `initialInput` in the config to update the form's baseline data. This is useful when remote data has changed and the form needs to reflect the updated values. Combined with `keepInput`, `keepTouched`, `keepErrors`, and `keepSubmitted`, you can update the initial state without overwriting the user's current edits. ###### More context on dirty tracking Formisch distinguishes between two concepts: - **Initial input**: the baseline value used for dirty tracking (often the server state). - **Current input**: the value the user is currently editing (the client state). Calling `reset` updates the initial input (baseline). Depending on the `keep*` options, it can also overwrite the current input, or keep it and just recompute state like `isDirty` based on the new baseline. > If the initial input is `null` or `undefined`, Formisch does not treat an empty string or `NaN` as dirty. This helps when HTML inputs produce `''` or `NaN` for "empty" values. #### Related ##### Primitives ##### Methods ### setErrors Sets or clears error messages on the form or a specific field. This is useful for setting custom validation errors that don't come from schema validation. ```ts setErrors(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to set errors on. The `config` parameter specifies the path and error messages to set, or can be set to null to clear existing errors. #### Related ##### Primitives ##### Methods ### setInput Sets input values for the form or a specific field programmatically. ```ts setInput(form, config); setInput(form, config); ``` #### Generics - `TSchema` - `TFieldPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to set input on. The `config` parameter specifies the path to the field and the new input values to set. > `setInput` updates the **current input** (what the user is editing), but it does not change the **initial input** (the baseline used for `isDirty`). If your baseline data changes (e.g. after refetching from the server), prefer `reset` with a new `initialInput`. #### Related ##### Primitives ##### Methods ### submit Programmatically requests form submission by calling the native `requestSubmit()` method on the underlying form element. ```ts submit(form); ``` #### Parameters - `form` ##### Explanation The `form` parameter is the form store to submit. The function triggers form submission by calling the native `requestSubmit()` method on the underlying form element. #### Related ##### Primitives ##### Methods ### swap Swaps two items in a field array at the specified indices. ```ts swap(form, config); ``` #### Generics - `TSchema` - `TFieldArrayPath` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store containing the field array. The `config` parameter specifies the path to the field array and the two indices of the items to swap. #### Related ##### Primitives ##### Methods ### validate Validates the entire form input against its schema. Returns a safe parse result indicating success or failure with detailed issues. Optionally focuses the first field with validation errors. ```ts const result = validate(form, config?); ``` #### Generics - `TSchema` #### Parameters - `form` - `config` ##### Explanation The `form` parameter is the form store to validate. The optional `config` parameter allows specifying whether to automatically focus the first field with validation errors after validation. #### Returns - `result` #### Related ##### Primitives ##### Methods ## Types (API) ### DeepPartial A utility type that recursively makes all properties and nested properties optional. > This type is too complex to display. Please refer to the [source code](https://github.com/open-circle/formisch/blob/main/packages/core/src/types/utils/utils.ts). #### Related ##### Primitives ### FieldArrayStore Reactive field array store interface with properties for managing array fields. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `FieldArrayStore` - `path` - `items` - `errors` - `isTouched` - `isDirty` - `isValid` ### FieldElement A union type representing form field elements that can be registered with a field store. #### Definition - `FieldElement` #### Related ##### Methods ### FieldElementProps Props to spread onto a field element for integration with React form handling. #### Definition - `FieldElementProps` - `FieldElementProps` - `name` - `autoFocus` - `ref` - `onFocus` - `onChange` - `onBlur` ### FieldStore Reactive field store interface with properties and element props for field management. #### Generics - `TSchema` - `TFieldPath` #### Definition - `FieldStore` - `path` - `input` - `errors` - `isTouched` - `isDirty` - `isValid` - `onChange` - `props` ### FocusFieldConfig Configuration interface for focusing a field. Used by the `focus` method to specify which field to focus and any additional focus options. #### Generics - `TSchema` - `TFieldPath` #### Definition - `FocusFieldConfig` - `path` #### Related ##### Methods ### FormConfig Form config interface that defines the configuration options for creating a form store with `useForm`. #### Generics - `TSchema` #### Definition - `FormConfig` - `schema` - `initialInput` - `validate` - `revalidate` ##### Explanation The `FormConfig` object is passed to `useForm` with a required `schema` property and optional properties for `initialInput`, `validate`, and `revalidate` to control form behavior and validation timing. ### FormSchema Type definition that represents the Valibot object schemas allowed as the root of a form. This includes object schemas, combinators (`intersect`, `union`, `variant`) whose options resolve to objects, and `lazy` schemas wrapping any of these. Forms must have an object root; use Schema for nested field schemas. #### Definition - `FormSchema` #### Related ##### Primitives ##### Methods ### FormStore Form store interface that provides reactive access to the state of a form created with `useForm`. #### Generics - `TSchema` #### Definition - `FormStore` - `isSubmitting` - `isSubmitted` - `isValidating` - `isTouched` - `isDirty` - `isValid` - `errors` ##### Explanation The `errors` property only contains validation errors at the root level of the form. These are errors from the root object schema validation itself, not errors from nested fields. To retrieve all validation errors from all fields across the entire form, use the `getAllErrors` method instead. ### GetFieldDirtyInputConfig Configuration interface for retrieving field-scoped dirty input. Used by the `getDirtyInput` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `GetFieldDirtyInputConfig` - `path` #### Related ##### Methods ### GetFieldDirtyPathsConfig Configuration interface for inspecting field-scoped dirty paths. Used by the `getDirtyPaths` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `GetFieldDirtyPathsConfig` - `path` #### Related ##### Methods ### GetFieldErrorsConfig Configuration interface for retrieving field-specific errors. Used by the `getErrors` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `GetFieldErrorsConfig` - `path` #### Related ##### Methods ### GetFieldInputConfig Configuration interface for retrieving field-specific input. Used by the `getInput` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `GetFieldInputConfig` - `path` #### Related ##### Methods ### GetFormDirtyInputConfig Configuration interface for retrieving form-level dirty input. Used by the `getDirtyInput` method when no specific field path is provided. #### Definition - `GetFormDirtyInputConfig` - `path` #### Related ##### Methods ### GetFormDirtyPathsConfig Configuration interface for inspecting form-level dirty paths. Used by the `getDirtyPaths` method when no specific field path is provided. #### Definition - `GetFormDirtyPathsConfig` - `path` #### Related ##### Methods ### GetFormErrorsConfig Configuration interface for retrieving form-level errors. Used by the `getErrors` method when no specific field path is provided. #### Definition - `GetFormErrorsConfig` - `path` #### Related ##### Methods ### GetFormInputConfig Configuration interface for retrieving form-level input. Used by the `getInput` method when no specific field path is provided. #### Definition - `GetFormInputConfig` - `path` #### Related ##### Methods ### InsertConfig Configuration interface for inserting items into array fields. Used by the `insert` method. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `InsertConfig` - `path` - `at` - `initialInput` #### Related ##### Methods ### PartialValues Utility type that recursively makes all value properties optional, including nested objects and arrays. #### Generics - `TValue` #### Definition - `PartialValues` #### Related ##### Methods ### Path Type definition for readonly arrays of path keys used to access nested properties. #### Definition - `Path` ### PathKey Type definition for keys used in paths to access nested properties in objects and arrays. #### Definition - `PathKey` ### PickDirtyConfig Configuration interface for picking dirty parts of a value. Used by the `pickDirty` method. #### Generics - `TValue` #### Definition - `PickDirtyConfig` - `from` #### Related ##### Methods ### MoveConfig Configuration interface for moving items within array fields. Used by the `move` method. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `MoveConfig` - `path` - `from` - `to` #### Related ##### Methods ### RemoveConfig Configuration interface for removing items from array fields. Used by the `remove` method. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `RemoveConfig` - `path` - `at` #### Related ##### Methods ### ReplaceConfig Configuration interface for replacing items in array fields. Used by the `replace` method. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `ReplaceConfig` - `path` - `at` - `initialInput` #### Related ##### Methods ### RequiredPath A type that represents a required path into an object structure with at least one key. > This type is too complex to display. Please refer to the [source code](https://github.com/open-circle/formisch/blob/main/packages/core/src/types/path/path.ts). #### Related ##### Methods ### ResetFieldConfig Configuration interface for resetting field-specific input and errors. Used by the `reset` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `ResetFieldConfig` - `path` - `initialInput` - `keepErrors` - `keepInput` - `keepTouched` #### Related ##### Methods ### ResetFormConfig Configuration interface for resetting form input and errors. Used by the `reset` method when no specific field path is provided. #### Generics - `TSchema` #### Definition - `ResetFormConfig` - `initialInput` - `keepErrors` - `keepInput` - `keepSubmitted` - `keepTouched` #### Related ##### Methods ### Schema Schema type definition that represents any Valibot schema that can be used with Formisch. #### Definition - `Schema` #### Related ##### Primitives ##### Methods ### SetFieldErrorsConfig Configuration interface for setting field-specific errors. Used by the `setErrors` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `SetFieldErrorsConfig` - `path` - `errors` #### Related ##### Methods ### SetFieldInputConfig Configuration interface for setting field-specific input. Used by the `setInput` method when a specific field path is provided. #### Generics - `TSchema` - `TFieldPath` #### Definition - `SetFieldInputConfig` - `path` - `input` #### Related ##### Methods ### SetFormErrorsConfig Configuration interface for setting form-level errors. Used by the `setErrors` method when no specific field path is provided. #### Definition - `SetFormErrorsConfig` - `path` - `errors` #### Related ##### Methods ### SetFormInputConfig Configuration interface for setting form-level input. Used by the `setInput` method when no specific field path is provided. #### Generics - `TSchema` #### Definition - `SetFormInputConfig` - `path` - `input` #### Related ##### Methods ### SubmitEventHandler Function type for handling form submission with the submit event. Used by the `handleSubmit` method and form components. #### Generics - `TSchema` #### Parameters - `output` - `event` #### Related ##### Methods ##### Types ### SubmitHandler Function type for handling form submission without the submit event. Used by the `handleSubmit` method. #### Generics - `TSchema` #### Parameters - `output` #### Related ##### Methods ##### Types ### SwapConfig Configuration interface for swapping items in array fields. Used by the `swap` method. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `SwapConfig` - `path` - `at` - `and` #### Related ##### Methods ### UseFieldArrayConfig Configuration object for creating a field array store with `useFieldArray`. #### Generics - `TSchema` - `TFieldArrayPath` #### Definition - `UseFieldArrayConfig` - `path` ### UseFieldConfig Configuration object for creating a field store with `useField`. #### Generics - `TSchema` - `TFieldPath` #### Definition - `UseFieldConfig` - `path` ### ValidArrayPath A utility type that validates array paths and returns the first possible valid array path based on the given value if the provided path is invalid. > This type is too complex to display. Please refer to the [source code](https://github.com/open-circle/formisch/blob/main/packages/core/src/types/path/path.ts). ### ValidateFormConfig Configuration interface for form validation. Used by the `validate` method to specify validation behavior. #### Definition - `ValidateFormConfig` - `shouldFocus` #### Related ##### Methods ### ValidationMode Validation mode type that defines when and how form validation is triggered. #### Definition - `ValidationMode` #### Related ##### Primitives ##### Methods