Skip to content

Releases: airjp73/rvf

React/Remix 6.2.0

27 Sep 15:57
Compare
Choose a tag to compare

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 🎉

08 Aug 22:41
a3f261d
Compare
Choose a tag to compare

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

14 Aug 23:21
Compare
Choose a tag to compare

What's Changed

New Contributors

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

Remix Validated Form v5.0.1

14 Jun 14:33
Compare
Choose a tag to compare

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

13 Jun 17:01
Compare
Choose a tag to compare

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

New Contributors

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

remix-validated-form-v4.6.12

06 Jun 12:40
Compare
Choose a tag to compare

What's Changed

New Contributors

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

Remix Validated Form 4.6.11

08 Apr 18:32
Compare
Choose a tag to compare

What's Changed

  • zod-form-data: add FormData as an input type on schemas by @KATT in #262
  • docs: fix typo by @jleknes in #271
  • Handle non-object loader data in useDefaultValuesFromLoader by @haines in #267

New Contributors

Full Changelog: remix-validated-form-v4.6.10...remix-validated-form-v4.6.11

remix-validated-form-v4.6.10

09 Mar 04:52
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: zod-form-data-v2.0.0...remix-validated-form-v4.6.10

Zod Form Data 2.0.0 + RVF patch

22 Feb 20:27
Compare
Choose a tag to compare

Zod Form Data breaking change

The return type of zfd.formData has been updated to be more accurate. This should help provide a better experience to users of tRPC. Thanks @sachinraja!

The bundle has also been updated to support both CJS and ESM.

What's Changed

New Contributors

Full Changelog: remix-validated-form-v4.6.5...zod-form-data-v2.0.0

remix-validated-form-v4.6.5

25 Nov 17:40
Compare
Choose a tag to compare