RVF v8.1.0: Small improvements

What's changed

• FieldApi.reset now accepts the same options object that FormApi.resetField does. (commit)
• Added an experimental API for listening to fine-grained form events. (commit, commit)
• In onBeforeSubmit, you can now pass data to getValidatedData to override what gets validated. (commit)
• Fixed an issue where FormApi.subscribe.value wasn't respecting the current scope. (commit)

PRs merged

• Fix docs grammar error by @bairdj in #456
• Fixed #457 [Bug]: zfd.checkbox() is not passing when type boolean is passed to it by @Dan503 in #458

New Contributors

• @bairdj made their first contribution in #456
• @Dan503 made their first contribution in #458

Full Changelog: v8.0.0...v8.1.0

RVF v8: Small, rarely-breaking changes

v8

This release contains some incremental changes that are only breaking in rare situations. In addition to that we have a couple small API additions.

New features

Experimental unstable_setCustomError API

The FormApi now has an experimental API unstable_setCustomError. The documentation for that is in the JS docs attached to the method itself. Please give it a try and feel free to give feedback! But do keep in mind this is an unstable API and may change before the final release.

Also worth noting that we don't yet have an API to set custom errors server-side, only the client-side API. Ideas for how that might API might look are welcome!

Added a keepError option to resetField

When I have time, I'd like to reach feature parity with the options object passed to resetField from react-hook-form. For now, I've just added keepError. If you'd like to help add the remaining options, please feel free to reach out and/or file a PR!

New options for the cancelSubmit API in onBeforeSubmit

The two new options are shouldFocusErrors and shouldCallOnInvalidSubmit. You can read more about these in the documentation here.

Breaking changes

These breaks are small, and likely won't affect the majority of use-cases.

noValidate when hydrated by default

In the old recommendations on supporting users without JS, there was a note about adding noValidate to the form element after hydration. This is now the default.

The reason for this change is to better support the useNativeValidity and useNativeValidityForForm hooks.
When these hooks are used without noValidate, RVF isn't able to perform validations on submit because the native validation errors block the submission.

This is especially problematic with the new custom errors API because an anticipated use-case is setting & clearing custom errors during onBeforeSubmit.

If you have a use-case where you need noValidate to be false, you can override this behavior by passing the prop to your form after calling getFormProps.

<form {...form.getFormProps()} noValidate={false} />

In onBeforeSubmit getValidatedData now correctly focuses invalid fields when it fails

When using the onBeforeSubmit callback, the getValidatedData api is used to run form validations and get the result. If validation fails, it throws and aborts the submit. The intention is for validation errors thrown this way to behave exactly as they would if you weren't using onBeforeSubmit.

Under the hood, this calls cancelSubmit({ shouldFocusErrors: true, shouldCallInvalidSubmit: true }). If your use-cases requires the old behavior, you can catch the cancellation error thrown by getValidatedData and call cancelSubmit yourself with the correct options.

PRs merged

These are all the PRs merged since the last release notes, though some of these have been released for awhile in patch releases.

• Update .npmignore by @darthmaim in #409
• Adding viewTransition to the useForm by @ZipBrandon in #412
• fix typo by @sajadtorkamani in #428
• Standard schema support by @airjp73 in #431
• fix: input type inference by @airjp73 in #436
• fix(docs): typo in supporting-no-js by @chohner in #440
• docs: fix typos by @cherryblossom000 in #451
• unstable_setCustomError and a couple other small improvements by @airjp73 in #454

New Contributors

• @darthmaim made their first contribution in #409
• @sajadtorkamani made their first contribution in #428
• @cherryblossom000 made their first contribution in #451

Full Changelog: 7.0.1...v8.0.0

zod-form-data v3

Zod v4 support for zod-form-data

Thanks to @chungweileong94, the types for zod-form-data have been updated to work with zod v4. It now has a minimum zod version of 3.25.0.

What's Changed

• Support Zod v4 in zod-form-data by @chungweileong94 in #430

Full Changelog: rvf-7.1.0...zfd-v3

v7.1.0 -- Standard Schema support

Overview

The main addition for this release is support for Standard Schema. 🎉 We've also stabalized the useNativeValidityForForm api.

Standard Schema

It's now possible to directly pass zod, valibot, or any other Standard Schema compliant schema into the useForm hook or ValidatedForm component. To do this, you need to use the new schema option.

useForm({
  schema: z.object({ /* etc */ }),
})

Some other new features around this are:

Default values are now required

When using a Standard Schema schema, the defaultValues option is required. It remains optional if you're still using a validator.

Type inference for default values

Standard Schema allows schemas to define an input type for the schema. This is used to infer the type of default values, but it's still possible to widen this type if you need.

useForm({
  schema: z.object({
    myNumber: z.number(),
    myOtherNumber: z.number(),
  }),
  defaultValues: {
    // This still works!
    myNumber: null as null | number,
    // But this fails
    myOtherNumber: null,
  }
})

Zod and Valibot adapters deprecated

Zod and Valibot both support Standard Schema, so they are automatically supported by the schema prop.
Therefore, the withZod and withValibot adapters are now deprecated.

Future direction

I'm planning on eventually removing the validator prop in favor of schema. The official Yup adapter will eventually be reworked to wrap the Yup schema to make it Standard Schema compliant, rather than using a custom Validator object.

useNativeValidityForForm

This was an unstable API that's now been stabilized with this release. Read the docs here.

---

Auto release notes:

What's Changed

• Update .npmignore by @darthmaim in #409
• Adding viewTransition to the useForm by @ZipBrandon in #412
• fix typo by @sajadtorkamani in #428
• Standard schema support by @airjp73 in #431

New Contributors

• @darthmaim made their first contribution in #409
• @sajadtorkamani made their first contribution in #428

Full Changelog: v7...rvf-7.1.0

v7 -- React 19 & React Router 7 support

Overview

This release comes with support for React 19 and React Router 7. There's also one additional, rarely-breaking change

Changes

React 19 & React Router 7

• @rvf/remix has been renamed to @rvf/react-router and supports React-Router v7
• React 19 is now supported
• React 17 has been removed from peer deps of all packages

Change to the behavior of resetField

This changes only affects cases whereresetField is used with a second argument to modify the default value (e.g. form.resetField("foo", "newDefaultValue"). In these cases, the previous behavior of resetField was unclear and incidental rather than intentional. The new behavior is described in detail in the docs. The main points are:

• resetForm() will now revert any field reset via resetField("foo", "bar")
• resetField("foo") will now revert nested field resets resetField("foo.bar", "baz")
• Likewise, if you call resetField("foo.bar", "baz"), defaultValue("foo") will still return the default value of the whole object, ignoring the modified default to foo.bar. defaultValue("foo.bar") will return the new default value.

This change facilitates proper encapsulation when making your own abstractions. In the future, it's might make sense to add a new API to get whatever the "current" defaults are.

React/Remix 6.2.0

Adds a new .keys() helper to the FieldArrayApi. The use-case for this is pretty niche, but can be useful in some more complicated situations. You can read more about this api here.

RVF v6 🎉

Version 6 of RVF is finally ready! You can read about this release in detail in the migration guide, but here are some key points:

• Renamed to RVF (no longer remix-validated-form)
• Decoupled from Remix (but still supports Remix, of course!)
• Simplified and more powerful API

Documentation:
https://www.rvf-js.io

remix-validated-form-v5.1.0

What's Changed

• use DeepPartial for acceptable DataType into ValidatedForm by @Alex-Yakubovsky in #318

New Contributors

• @Alex-Yakubovsky made their first contribution in #318

Full Changelog: remix-validated-form-v5.0.1...remix-validated-form-v5.1.0

Remix Validated Form v5.0.1

Slightly breaking fix

The v5 release notes communicated a breaking change to the types that narrowed the onSubmit type based on the provided subaction. This was not fully implemented and only the defaultValues were being narrowed. This patch fixes that and adds the expected type narrowing to the onSubmit prop as well.

This could technically be considered an additional breaking change, but I've included it as a patch because it was the originally intended behavior for the v5 breaking change.

Full Changelog: remix-validated-form-v5...remix-validated-form-v5.0.1

Remix Validated Form v5

Breaking changes

Minimum version of Remix now 1.15.0

We've removed the deprecated useTransition API in favor of useNavigation. I'm not sure which version this API was introduced, so I set the peer dependency to 1.15.0.

with-yup v3

@remix-validated-form/with-yup now requires a minimum yup version of 1.0.0.

Validation behavior changed when validating one field

In order to improve the DX when using dependent validations, validating a single field now checks other fields in the form as well. The behavior for that is like this:

• If another field no longer has an error, it will be cleared automatically.
• If another field's error has changed, it will be updated automatically.
• If another field has a new error, it will only add the error if the field has been touched or the form has already been submitted unsuccessfully.

In practice, these changes should only be noticeable when the validity of a field changes based on the value of another field.

Field array API changed

useFieldArray and FieldArray have had some changes to their APIs. We now automatically generate a key for each item in the array and adjusted the API slightly to accommodate it.

Here's an example of migrating to the changed API.

  const [items, helpers, error] = useFieldArray("myFieldArray");

  return items.map((item, index) => (
-   <li key={item.id}>
+   <li key={item.key}>
      <input
        name={`myFieldArray[${index}].id`}
        type="hidden" 
-       value={item.id}
+       value={item.defaultValue.id}
      />
      <MyCustomInput name={`myFieldArray[${index}].value`} />
    </li>
  );

Values in the form are now captured before validation occurs

It's unlikely you will have anything break due to this change, but it is technically a breaking change. Previously, it was possible to change the values in the form while validation was occurring, and that would change the values that ultimately got sent to the server.

This will now never happen. The values that are in the form when the submit is initiated are the values that will be sent to the server.

Added type narrowing based on the subaction prop

The inferred values of data in the onSubmit prop will now be narrowed based on the subaction prop if you supply a validator that includes validations for multiple subactions.

This is technically a breaking change but only in rare cases. If your validator doesn't reference a subaction at all, then the type will be the same as before.

Deprecations

Validator["validateField"]

The validateField property in custom validators is now optional and deprecated. Remix Validated Form no longer calls into this function. It's also not always useful to implement this for some validation libraries (see zod adapter), which don't actually support validating only a specific field.

Non-breaking changes

FieldArray now generic

Previously, only the hook version (useFieldArray) was generic. Now, both versions are.

PRs merged

• Support yup 1.0 by @jnicklas in #288
• Moving useTransition -> useNavigation by @ZipBrandon in #284
• Fix: prevent scroll to reset not working by @nimaa77 in #291
• Export FORM_DEFAULTS_FIELD to fix #227 by @stephenwade in #281

New Contributors

• @ZipBrandon made their first contribution in #284
• @nimaa77 made their first contribution in #291
• @stephenwade made their first contribution in #281

Full Changelog: remix-validated-form-v4.6.12...remix-validated-form-v5