V7

[bluebill1049]

Context

Typescript is getting more and more populated among the community, and it's our responsibility to improve type support over time. TS 4.1.0: https://devblogs.microsoft.com/typescript/announcing-typescript-4-1-beta/#template-literal-types is totally a game-changer for us to build strict typed form, and that's one of the main drivers for us to produce another major version so we can leverage this awesome feature to provide users even better typescript support.

Documentation V7

https://react-hook-form-website-git-v7.bluebill1049.now.sh/

Vision

📖 (DX) Strictly typed form
🏋🏻‍♀️ Reduce package size
🏎 Performance
💁‍♂️ Simplicity and consistency

Proposal

• register

We really want to guarantee type-safe with register API, the current implementation does have difficulty achieving this because there is no simple way for typescript to extract name attribute inside input element as ref, so we plan to move away from the current way of register native input. here is the proposal:

- <input ref={register, { required: true }} name="test" />
+ <input {...register('name', { required: true })} /> 

By doing the above, which means we can type the input name correctly with template literal against your input data type.

• MutationObserver will be removed as well.
• input name will need to be consistent with '.' syntax instead of [] for the array field, this is to be consistent with typescript usage.

- test[2].test
+ test.2.test

🟢 Better fast refresh support
🟢 Made strict type checking possible
🟢 Less to type and consistent API with useFieldArray
🟢 Consistent with React Native API
🔴 Breaking change
🔴 Required to invoke unreigster when inputs get unmounted

---

valueAs

Currently valueAs is running at submission value, this is causing inconsistency with type. This will be changed at V7, where valueAs will always be run before the build-in validator and resolver.

useForm<{ test: number }>()

<input {...reigster('test', { validate: (data: number) => { console.log(data) } })} /> // the data will be consistent with type declaration.

🟢 Type consistency
🔴 Breaking change

---

• Controller

remove as prop and provide a single solution with render prop, as works well with standard controlled input which exposed onChange, onBlur and value, however, there are cases which are not going to work well and it's confusing to give users too many options. onFocus prop is removed, use the ref prop from the field object.

- <Controller as={<input />} />
+ <Controller render={({ field }) => <input {...field} />} />

change render's props to align with useController

- <Controller render={(props) => <input {...props} />} />
+ <Controller render={({ field, fieldState, formState }) => <input {...field} />} />

updated meta:

{
  invalid: boolean;
  isTouched: boolean;
  isDirty: boolean;
  error: FieldError;
}

🟢 Consistent API with useController
🟢 Less way to think about making components
🔴 More to type
🔴 Breaking change

---

• reset

reset is one of the most powerful APIs in hook form, however, it does comes with its own limitation and yet more functionality can be explored. We want to make it as easy as it today for beginner users and still have the capability for advanced users, so we would like to enhance the second argument from the current API.

- reset(values, { isDIrty: true })
+ // second argument is still optional
+ reset(values, { 
+   keepDefaultValues: true, // new
+   keepValues: true, // new
+   keepDirty: true, 
+ })

🟢 declarative on the second argument on what's getting reset
🔴 Breaking change
🔴 Verbose

Related:
#3719

---

• getValues

There have been quite a few questions around why getValues() is not returning defaultValues, we will make getValues return defaultValues before the render (before inputs mounted).

const { register, getValues } = useForm({ defaultValues: { test: 'test' } });

console.log(getValues()) // v6 return {}

// v7 return { test: 'test' } and only the first call before the render, the second re-render getValues will read what's in the current view.
console.log(getValues());

return <input {...register('test')} />;

🟢 Users can retrieve defaultValues before inputs get mounted.
🔴 Breaking change

---

• append
• insert
• prepend

The current above API design is lack of extending, the second argument as boolean is not scalable for new options. we are proposing to change that into an object of options.

append(object, config: { shouldDirty: boolean, focusIndex: number, focusName: string })
insert(object, config: { shouldDirty: boolean, focusIndex: number, focusName: string })
prepend(object, config: { shouldDirty: boolean, focusIndex: number, focusName: string })

append({
  test: [
    { test: 'name' }
  ]
}) // support deep nested field array

🟢 More powerful and extensible
🔴 Breaking change

Related:
#2155
#3525
#2155

---

• resolver

resolver is a powerful way to integrate with external validation libs, and we want to further improve its functionality and robustness. We are introducing the third argument which gives other libs like more insight into the validation.

- resolver: (values: any, context?: object) => Promise<ResolverResult> | ResolverResult
+ resolver: (
+    values: any, 
+    context?: object, 
+    options: { 
+       criteriaMode?: 'firstError' | 'all', 
+       names?: string[],
+       fields: { [name]: field } // Support nested field
+    }
+  ) => Promise<ResolverResult> | ResolverResult 

🟢 More powerful and extensible
🔴 Breaking change

Related:
#3110
#3538

---

• watch

allow watch to subscribe to inputs change without trigger re-render. watch's defaultValue will only get printed on the initial invoke before render.

React.useEffect(()  => {
  watch((value, { name, type }) => {
    console.log('value', value);
  })
}, [watch])

watch array will return array instead of object

- watch(['test', 'test1']); // { test: '1', test1: '2' }
+ watch(['test', 'test1']); // ['1', '2']

- watch('test', 'test'); // default value will return when inpu removed
+ watch('test', 'test'); // default value will only return on the initial call before render

🟢 Flexible with subscribed inputs
🟢 Type alignment
🔴 Increase bundle size

Related:
#912

---

• trigger

trigger will no longer return validation result (as Promise), instead of subscribing to errors formState, each time calling trigger will trigger a re-render as well.

- await trigger('test'); // will return true/false
- trigger('test'); // return void in v7

🟢 Reduce trigger's complexity and keep it simple and focus only on doing one goal, that's to trigger validation.
🔴 Breaking change and more to type

---

• errors

One of the limitations right now is errors or any formState will always re-render at the root of the App/Form, we would like to improve that and give users the opportunity to isolate that re-render within components level, which means we want to wrap errors within the proxy as well, so we can skip any re-render if users are not subscribed to the errors formState.

- const { errors } = useForm();
+ const { formState: { errors } } = useForm();

🟢 Allow hook form to precisely know which state to subscribe
🔴 Breaking change and more to type

---

• useFormState

This new hook will allow you to subscribe formState update at the component level instead of the root level where you initialized the useForm. Users will have the capability to subscribe to individual form state at each useFormState.

const { isDirty } = useFormState();

🟢 Subscribe to form state at any component level
🔴 Increase bundle size (tree shakeable)

---

• setError

set shouldFocus option is to move into the third argument for consistency purpose and more scalable for other options.

- setError('test', { type: 'type', message: 'issue', shouldFocus: true })
+ setError('test', { type: 'type', message: 'issue' }, { shouldFocus: true })

🟢 APi consistency
🔴 Breaking change

---

• unregister

add new option argument for unregister, it will give the user more control over how to reset formState after an input gets removed.

unregister: (
  name?: FieldPath<TFieldValues> | FieldPath<TFieldValues>[],
  options?: Pick<
    KeepStateOptions, 'keepTouched' | 'keepDirty' | 'keepIsValid' | 'keepErrors'
  >,
) => void

🟢 Better control on how formState react to unregister inputs
🟢 User can easily unregister all inputs
🔴 Increase bundle size

Related:

#3045
#3155

---

• touch

rename touch to touchedFields, keep it consistent with dirtyFields from formState.

🟢 API consistency
🔴 Breaking change

Related:
#2086

---

deafultValues

useForm's defaultValues will shallow merged into submission results. This will affect watch, getValues, and handleSubmit. defaultValues will make a shallow merge with the actual form values.

Note: as the lib author, I would still recommend users to include form metadata inside input hidden or custom register at useEffect, but this shallow merge update should resolve some of the simple use cases which this community demands.

useForm({
  defaultValues: {test: 'test'}
});

getValues(); // V6 returns {} because nothing is registered

getValues(); // v7 restusn { test: 'test' } because of the shallow merge.

Poll result: https://twitter.com/HookForm/status/1356900322535370753

🟢 Convenient for simple metadata
🔴 Breaking change

---

Remove console warning

The ES6 module build includes references to process.env.NODE_ENV, which breaks browser usages. We will remove those console.warning for now, until we figure out a better solution in the long run. Also, improve the documentation to fulfill the gap.

Related:
#3498

---

TS Improvement

We will aim to support the following API with Template literal.

• watch
• clearErrors
• setError

🟢 Better Type guard
🔴 More restriction and potential limitation (such as type-safe max array index with being capped at 99)

---

• remove warnings from this library

we will no longer throw a warning for incorrect usage for better ES module support.

🟢 ES Module
🔴 The user will have to refer to docs more often.

---

• remove IE 11 support

We are moving away from IE 11 at the next major version as IE11 officially ends support on the August 17th, 2021, however, you can use still V6 which has IE 11 support.

[ZimboQC]

As long that useController is following ;) I like this new hook!! Trying right now to add typescript field for custom component with useControllerProps

[bluebill1049]

useController will have a strict type as well, it will be inherited from register method.

[msutkowski]

Very nice! We rolled out auto-generated hooks with rtk-query using the typed literals and they're great. Looking forward to this release. Congrats and awesome work! 💯

[bluebill1049]

That's awesome to hear @msutkowski ❤️

[aaronjensen]

Continuing conversation from #3719 (comment)

reset: (values?: Record<string, any>, { formState: Partial<FormState>, shouldUnregister: boolean }) => void

• you can skip unregistering (actually we may that option, so inputs never get unregistered automatically)
• instead of omitting state update, now you can reset partially

reset(values, {
  formState: {
     ...formState,
     isDirty: true,
  },
  shouldUnregister: false,
})

let me know your thoughts, it's good to have those conversations and feedbacks. feel free to leave comments in that discussion channel as well, so everyone can see the concerns and we can fix them accordingly.

There are multiple issues raised in #3719:

1. Field array fields get new ids any time the form is reset (maybe this will be fixed by not unregistering)
2. Field array fields get their default values changed, which, because of Chrome's behavior, causes the cursor to move (no fix for this other than to not use field arrays)
3. Default values cannot be changed without extravagant work-arounds like this. (It's unclear how the reset api change addresses this, but if it's meant to, see below.)

Avoiding unregistering is good. However, my ultimate goal is only to change the underlying default values and allow react-hook-form to compute dirty/valid state accordingly.

I don't want to reset the values. I don't want to reset anything, unless you consider changing the default values to be a "reset".

Allowing the resetting of formState is a bit of a head scratcher because it can create nonsense situations. For example, what happens if I set isDirty to false but there are still values in dirty? That's not a valid state. isDirty should always be dirty.length > 0.

Another example, what happens if I say that a field is dirty by setting it in formState.dirty but it actually matches the default value? Now if someone makes a change to that field and then undoes that change, it would be no longer dirty.

In short, I'm not sure I understand the reason to give the user complete control over the state machine so that non-sensical states can be created and it's unclear how I would address the situations described in #3719 with that ability.

[bluebill1049]

Had an idea last night, hows the following:

reset(data, { shouldResetDefaultValue shouldResetValue, shouldResetDIrty, etc. })

verbose but it's declarative on what the options are. the default will reset all, if you need to customize then you need to be specific on all of them. Let me know your thoughts.

[aaronjensen]

It seems unnecessarily verbose and it wouldn't be clear how to use it. Even from your description, do I really need to specify all or just the ones I want to make false? Or just what I want to make true? What does it mean if I pass data in but only reset dirty? Are the values I pass in data used to compare to make the dirty determination?

Ultimately I'd guess the API design problem stems from having a single Swiss army knife function that is really begging to be more than one. It's also because React natural resistances having to call more than one function in a row, which would be one normal unit of composition.

[bluebill1049]

Thanks, @aaronjensen valid points as usual. Yes, It's quite verbose, I think at least it's more declarative than the current API, which is pretty confusing, I think we can treat the rest of the options true by default.

reset(test, {
  shouldResetDefault: false,
  shouldResetValue: false,
  // the rest of them will get reseted
})

[aaronjensen]

That would be better. I'd recommend leaving off the should. Words like that are typically superfluous in APIs.

Another option would be to find a word that means the opposite of reset.

maintainDefault: true

keepDefault: true

[bluebill1049]

Sounds great!

[bluebill1049]

@jorisre should we expose formState in resolver as well? so users can read formState inside a custom resolver.

[jorisre]

Good question !
I think, it's a good idea, it can cover multiples edge cases. It could allow developers to create complex custom resolver 👍🏻 .

If anyone read this thread, feel free to share your opinions, your edges cases about this subject 🙂

---

@bluebill1049 , about formState, do you think we could have a simpler api ? I think about an enum instead of multiples boolean properties. What do you think ?

[bluebill1049]

I did think about that, something like "status", but how we deal with dirty and touched those deeply nested ones? also I do remember we did post this long ago and some developers have concern over such API.

---

in terms of a resolver: what about the following

resolver: async(data, context, meta: { name: 'current validate input name', formState: {} }

[sonhanguyen]

can we not assume the error Message to be a string? In fact it should not be called a message. The library should just take whatever error object from the resolver and pass along with the input key and let the react component decide how to render that error object.

While we are at this has anyone tried to pass an object to message as it is now? If that works what can I do to so typescript can shut up?

[mikestopcontinues]

Hi, the watch updates doesn't match my use case (#3698), though it's closer to the mark.

My problem is that there's no way to watch all changes AND detect what's changed. <form onChange> will tell you both the name and value of the changed value, but only if the change occurs organically. setValue is missed entirely.

The new watch((value) => null) still doesn't tell me what's changed. But it would work if the callback signature was (value, name). Is that a possibility? Thanks!

[mikestopcontinues]

Do you think this isn't the right place to be able to track that info? I'm really just looking for a way to know when a change is made to the form, and what field was changed, much like when you use <form onChange>. The thing is, onChange doesn't detect setValue changes. Do you have another idea where a feature like that would go?

[bluebill1049]

I am trying to find a way without causing too much of a breaking change.

[bluebill1049]

I have this idea! watch((data, name) => {}) it will return which input triggered the change, we do not introduce massive breaking change as well.

[gaetano-guerriero]

I've created a simple snippet for my use case:
https://codesandbox.io/s/react-hook-form-useform-template-forked-wp3j7?file=/src/index.js

My motivation is that the use case is common: "do something when a form field changes.
With a new API the onChange handlers could be avoided. onChange handlers are bad in this case since they must
be put not where the change is observed but where the change is done.

[mikestopcontinues]

@bluebill1049 That would be perfect! 😁

[mikestopcontinues]

I've got a thought on controlled/uncontrolled components, which I think might go well with the new register() syntax.

When creating reusable uncontrolled components, being able to pass the result of register is really useful because it's easy. But one thing you don't get is access meta (from control) and field errors. For any of that, you also need to pass in form or control.

Passing control gives you props and meta, and the ability to get errors (via name). However, it also requires that you pass down your validation rules, rather than being able to declare them in the parent component. Plus, you need useController(), which isn't terrible, but it's an extra step.

So what I'm wondering: Is there any way to combine register with control to get the best of both worlds? For starters, what if control was a function that returned {field, meta, errors}? That would allow you to do things like this, no need for register or useController:

function App() {
  const { control } = useForm({});

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...control(name, {required: true}).field} />
      <InputComponent control={control(name, {required: true})} />
    </form>
  );
}

Perhaps control() always returns an extend function, so that InputComponent could add additional config to the passed control prop.

Anyway, just some food for thought.

[bluebill1049]

Interesting thought above. thank you @mikestopcontinues. Controlled input needs its own context or scope, eg:

• useController should be used within a single component.
• Controller is a render prop that re-render within itself.

which is one of the reasons why I have separated from uncontrolled input, uncontrolled inputs are always easier to manage but then you are missing the other valuable information which you will get from using Controller or useController. I am trying to close the gap here, with useFormStata still isolated re-render, and give users the option to subscribed to form state update. It's actually really powerful because each component can subscribe to its own state update, which means you can potentially stop re-render at the root of your form with errors update.

Again, thanks very much for the idea, it's indeed an option we can consider as well.

[msiric]

Landed here from the docs page to read more about the deprecation of shouldUnregister option and still not sure what the final decision is.
Is this option getting deprecated? If yes, what's the reasoning behind it? Are there going to be any alternatives?

Thanks

[wdfinch]

Ok thanks. I think it would be nice to have the option to just have mounted values be used for validation, but this is more inline with the one useForm per section concept. I'm going to try to use this approach for my forms as this is what you and the library encourage.

[bluebill1049]

Thanks for understanding @wdfinch, another important aspect of hook form is keep as tiny as possible, for V7 I want to shake off some of the options, simplify internal logic, keep it smaller, right now we are looking at a 10% reduction.

[wdfinch]

After thinking about this a bit more, one idea to ponder here is should this idea of keeping values after fields have unmounted be pursued at all. I say this because I feel like there are a number of gotchas and issues with doing this if other changes are not made as well.

After talking to you about this, it seems like this feature does not really align with the library and your vision for it. Therefore if it's added in a somewhat minimal/half-baked way, I worry that users will immediately be confused and start asking for more features to expand it.

Therefore, I feel like it might be best to have more of an all or nothing approach.

One example here is what you mentioned regarding isValid. For example, if a form was validated using values that weren't mounted, this would be a major annoyance for me.

I guess if values are kept after mount, the library would start to feel more like formik and react-final-form in that regard and people would have assumptions and expectations about how it should work (which is not how it currently works).

Just an idea.

[linde12]

@wdfinch I'm currently facing everything you've described here. There is no documentation (what i could find, other than in this discussion) regarding the new behavior of not automatically unregistering on unmount. I have had the same issue you describe in regards to validation/submission.

Splitting up e.g. a wizard into smaller form components (with separate useForm) will require additional state management, and for many applications it is simply a premature optimization & additional overhead, but even if you split up your form you will still have this validation problem with stale conditional properties polluting the form state. I really don't see the "win" with this change, and especially not in removing the opt-out via shouldUnregister: true

@bluebill1049 Is it too late to reconsider or to add something like shouldUnregister again? I won't be able to update any of my current (professional and personal) applications because they rely on this core idea which redux-form, formik & react-final-form & react-hook-form (up until now) all embrace. I imagine that most people will face the same issue, when eventually trying to upgrade to V7, because it is such a core feature.

[bluebill1049]

upvote here: #4355

changelog: https://github.com/react-hook-form/react-hook-form/blob/master/CHANGELOG.md

understand your concern will introduce the feature above, once we have more users asking for the feature.

[getTobiasNielsen]

Regarding:

dirtyFields, isDirty, and touched.

I agree omitting "Fields" is the right choice. My concern is however, if dirty is the right word to begin with. dirty implies that it has been altered for the worse.

I suggest isModified and modified. I also really like: formState.isModified vs formState.isDirty. This will also make the docs more consistent:

Set to true after the user modifies any of the inputs.

This can avoid people coming to this code in a project, and thinking that the input needs to be sanitized further, e.g.

In the docs:

Make sure to provide all inputs' defaultValues at the useForm, so hook form can have a single source of truth to compare whether the form is dirty

Here I question if we really need to explicitly tell the user to provide a defaultValue as components always(?) have a default state? I do think it is important to highlight that dirty(or modified) is compared to the original states.

Hopefully this help you, Bill. I liked everything else.

[bluebill1049]

valid Points! perhaps we should do dirtyFields, touchedFields so it's more consistent and clear? I love the word modified, it's so much more clear, but this industry has already taken dirty for granted and I am worried people will be confused because of some terms that they r already taken for granted.

[getTobiasNielsen]

dirty from Formik makes it seems to me that there is a lot of emphasis on the equality being deep and not shallow. Which makes a lot of sense to me in terms of being dirty or not. You should definitely make it clear what level(deep or shallow) the comparison is done at.

Going away from having just dirty vs dirtyFields , will make a lot of sense, taking this into consideration. Especially considering users, as dirty is a boolean in one, and object in another.

I think it is better to have the variables and functions make sense going forward, than having the users paying the cost of ambiguity moving onwards.

I guess that would be: isModified and modifiedFields

[bluebill1049]

Thanks for your input 👍 will be moving into dirtyFeilds and touchedFields.

[getTobiasNielsen]

Remember "ie" #3714 (comment)

[bluebill1049]

"ie" internet explore? 😆

[wdfinch]

Small typo:

'rename dirtyFeilds to dirty, keep it consistent with touched formState'

dirtyFeilds => dirtyFields

[bluebill1049]

Thanks.

[spaceInvaders007]

It would be nice to improve the error reading. As you focus more on typescript, it would be good if errors could contain more information of why a form is not valid, and have type-related errors too.

[bluebill1049]

can you provide more details on this?

[spaceInvaders007]

Right now it is not possible (I think, maybe I am wrong) to know why an input is invalid, you simply get an isValid: false message. If integrated with typescript, an input error should specify why the input is not valid. E.G. input is expecting a string but received a number. E.G.2 input is expecting type LastNameResidentsInNewYork (custom type) and received FirstNameResidentsInLosAngeles.

[bluebill1049]

isn't that in the error object?

[spaceInvaders007]

My bad, we had disabled the submit button unless the form is valid, but if you don't submit the form you don't get an errors object so I wasn't able to see what the validation errors were. I had to enable the submit button, send again and then get the errors object.

[spaceInvaders007]

I receive empty error messages  On Sat, 16 Jan 2021 at 5:00 pm, Bill<[email protected]> wrote: isn't that in the error object? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[bluebill1049]

can you provide a codesandbox?

[wdfinch]

Just wondering what the timeline for this is. The changes to persisting values are very useful to me so wondering when I can start using this in my projects. Will a beta release be available on NPM first?

[bluebill1049]

still early stage at the moment.

[bluebill1049]

I will ping everyone when we have a beta, it's hard to predict a time because I am working fulltime and hook form is all in my free time.

[bluebill1049]

here is a rough estimate: #3741

[wdfinch]

Thanks for the update. We appreciate you using your free time to work on this.

[borm]

Please do not do its deprecated, its really needed functionality
Example, i need to have Wizard form on one Route and one Container,
i need use useFormContext() in child components
i need have global form state, i no need store formState in Redux store

const form = useForm({ ..., shouldUnregister: false })

return (
  <FormProvider {...form}>
     <form onSubmit={form.handleSubmit(onSubmit)}>
          {formSteps[currentStepIndex]}
)

[bluebill1049]

@borm this is pretty much going to be the default with V7, so don't panic about it. 🙏

[wdfinch]

The plan is to keep values in the form state that are unmounted. I'm wondering if this would also be true for useFieldArray elements.

So let's say I have a field array. A common use case is the ability to hide or conceal a field array elements (a group of inputs) to use screen space better. When this happens, the element is currently removed from the field array. This breaks remove and other methods. My workaround is to keep a hidden (display: none) input around so the element is not removed. I'm wondering if V7 would keep a field array element even if no inputs were mounted for that index.

[bluebill1049]

if you are toggling an input.

const [show, setShow] = React.useState(true);

<button onClick={() => {
  setShow(false);
  // unregister('test'); // if you want to remove that from ressult
}}>toggle</button>

{show && <Controller name="test" render={({ field }) => <input {...field} />} />}

[wdfinch]

I see. I guess a common case is with a checkbox and a controller is handling the onChange. Therefore, I would need to listen with watch. It's doable, just takes a little more work than I think is necessary.

[bluebill1049]

I see, I think for the checkbox is better to build a checkbox grouped component and controlled by Controller (only collect value and validating).

[wdfinch]

ok thanks!

[linde12]

This is also something that is stopping me from basically ever being able to upgrade: i have a field array that is rendered conditionally but and i've added some useEffect to unregister the actual fields in useForm but fields from useFieldArray still has the indices which causes things to blow up. There is no clear/reset for useFieldArray either so i'm wondering how you would apporach this?

@bluebill1049 do you know if there is a feature request for this as well or if it is a part of #4355 ?

[wdfinch]

I wanted to bring up the topic of syncing field array values with form values and an issue I'm facing regarding this.

Let's say we have a field array and we use append to add a value. So something like this:

 const { append, fields } = useFieldArray({
    name: "pets",
  })

const onAddElement = () => {
  append({
    name: "spike"
  })
}

After doing this the new element will be placed inside the fields array and this will be the most up to date version of the field array. formValues on the other hand will not have this element until the input for that array element is registered. This means if we need to access this value somehow prior the input being mounted/registered, we must use fields to access it rather than getValues or watch. I personally think it would be better if append would add the element to fields and formValues so they are not out of sync. Additionally, I tried using setValue to keep them in sync but I can't set all array index that does not exist yet in formValues (causes a crash).

What are the issues with append, remove, etc updating formValues rather than just fields and do you think we should change the behavior so they are always in sync?

[bluebill1049]

Thanks @wdfinch i will have a play around with it.

[bluebill1049]

Thanks @wdfinch i will have a play around with it.

[bluebill1049]

https://codesandbox.io/s/react-hook-form-usefieldarray-template-forked-rogbi?file=/src/index.js

looks like this can be fixed 👍

[wdfinch]

If you click add element twice, it crashes.

[bluebill1049]

This will get improved on the next beta.

[zhicong]

I've been using React Hook Form and love the developer experience! I just saw in the docs that the <Controller as={}> prop is going to be removed. I use <Controller> a lot in my code because it's the only way to get a Material UI <Select> to work, and the as prop helps keep it succinct. Removing it would several more lines of boilerplate code to each instance. I'll miss it 😔

[bluebill1049]

hey, @zhicong, I am sorry to hear that... I understand entirely that however as has created a lot of edge cases and certainly worked for most of the scenarios.

const ControllerAs = (({ as, ...rest })) => {
  return <Controller render={as(rest)} />
}

you may be able to get around with the above by building a wrapper. I hope you understand the concern that i had to be consistent and less edge case at the lib level. 🙏

[misterflop]

Hello,

How am I supposed to define a custom onChange callback in v7?

Thx for your work on v7 :)

[mogelbrod]

Move the onChange line down below the register() spread:

<input
  {...register('test')}
  onChange={e => onChange(e.target.value)}
/>

[misterflop]

Thank you ! :)

[tonyjara]

awesome! this should be on the migrating docs

[bluebill1049]

we are considering a way to make this easier.

[bluebill1049]

Looks like the V7 beta is getting stable! Aim to release an RC version at 2 years birthday, 6th Mar.

[mogelbrod]

Looking forward to it! Great work 💯

[michael-land]

congrats 💪

[rdewolff]

Nice!

[kousenlsn]

Hello, gotta say I really am liking this new version!

I have been experimenting with the current beta version, and have got a problem with the isDirty logic, which I don't know if it's a bug, or a feature not intended.

I saw that the defaultValuesRef only gets setten when instantiating the form at the useForm call, is this correct?

I ask because I only have the defaultValue's setten on the <Controller> tags themselves, but it seems the logic of knowing if the field is dirty is not working that way, as only the defaultValeusRef is checked to know if the value has changed.

I thought the defaultValeusRef should be updated when the register is called when a field is rendered.

Here is a code sample:

for initialData: AddressFormData = { title: "test" };

const Sample = ({ initialData }) => {

     const {
          control,
          formState: { isDirty, dirtyFields },
      } = useForm<AddressFormData>();

     console.log(isDirty);
     console.log(dirtyFields);

     return (
          <Controller
            name="title"
            defaultValue={initialData?.title}
            control={control}
            render={({ field }) => <input {...field} />}
          />
    )
}

Whatever you trigger onChange or onBlur, it will mark the field as dirty.

Doing the following works, but since I add fields dynamically at some forms, it would not suffice:

useForm<AddressFormData>({ defaultValues: initialData });

[bluebill1049]

can you share a codesandbox?

[kousenlsn]

Sure, here you go https://codesandbox.io/s/optimistic-antonelli-qd8d3?file=/src/App.js

[bluebill1049]

for dirty formState, we will always need a defaultValues 👍 as the source of the truth to compare. you may want to use {} instead of undefined.

[dairyisscary]

hey react-hook-form folks! excellent work on v7!

I have a small request/question that i've come across migrating a typscript code base to from a different form library to react-hook-form -- I went straight to the v7 because of the typescript improvements. on that subject, it would be helpful if the Message type from https://github.com/react-hook-form/react-hook-form/blob/v7/src/types/errors.ts#L5 was more permissive than just a string and change to something like string | ReactElement. This would help with integration with internationalization libraries for instance. Interestingly enough, the documentation already kind of hints at this on the output side of things formState.errors.X.message can be a ReactElement. (i tested this already its functionally it seems to work just fine).

In code:

// this example uses the popular react-intl package but i imagine react elements would be often a choice for translation.
const REQUIRED_ERROR_MESSAGE = <FormattedMessage id="someID" defaultMessage="This is a required field!" />;

function MyForm() {
  const { register, formState, handleSubmit } = useForm<{ name: string }>();
  return (
    <form onSubmit={handleSubmit((values) => console.log(values))}>
      <input type="text" {...register("name", { required: REQUIRED_ERROR_MESSAGE })} />
      {formState.errors.name?.message}
      <input type="submit" />
    </form>
  );
}

[bluebill1049]

@kotarella1110 I remember we had an issue with type support on this one right? that's why we only support that for JS but not TS.

[kotarella1110]

@bluebill1049 yes: #1713

[bluebill1049]

thanks @kotarella1110 that's right.

[dairyisscary]

oh right. after reading that issue, makes more sense to me. i think i'll just as Message assert these intl elements since they're basically app global constants, it only needs to be done once.

[dairyisscary]

thanks friends! ❤️

[bluebill1049]

V7 RC released. expected next month release the final v7. I wouldn't expect much of a breaking change from RC onwards.

[lionskape]

Is there any migration guide for v6 -> v7?

[bluebill1049]

yep, WIP:https://react-hook-form-website-git-v7-bluebill1049.vercel.app/migrate-v6-to-v7

[lkhari]

Hey, Loving the new v7!
So I noticed form on FormProvider Performance you have the line:
console.log(methods.formState.isDirty); // make sure formState is read before render to enable the Proxy

Is this also intended for formState.dirtyFields?

Here is an example of what I mean, if you change the field and then click submit you will only see the dirtyFields if you console logged before hand.
https://codesandbox.io/s/exciting-pare-se4e5?file=/src/App.js

Also is console.log the best method of getting round this? Love the feature btw, it allows me to do partial submissions rather than submitting the whole form.

[bluebill1049]

formState needs to be deconstructed, so hook form knows it's subscribed.

[lkhari]

Thanks for the response. When appending to a field array it seems like all the fields in the object are instantly dirty, is this intended?

Also setValue doesn't seem to be updating the values when the items are in a field array.

To recreate I've linked an example below. If you click the button "Add new item" and then change value the first box, I would expect the 2nd box to change to be the same as the first box.
https://codesandbox.io/s/modest-newton-0y189?file=/src/App.js

[bluebill1049]

This is intended but it will generate a new value each time you append. there is a feature request you may be interested to vote. #3525 however this will still not prevent your form to become dirty.

[BigWhale]

Is there a working example of v7 integration with existing form or example of custom components where input is wrapped in it?

https://react-hook-form-website-git-v7-bluebill1049.vercel.app/get-started#Integratinganexistingform

This seems to be it, but I can't get it to work.

Type Error in the line below: register is not a function.

<input {...register(label, { required })} />

Codepen linked in the docs is written for v6 with passing register to ref property and doesn't really apply here.

[BigWhale]

It's here. I just copied the example from the documentation into it.

https://codesandbox.io/s/react-hook-form-adapting-existing-form-ts-forked-es53i?file=/src/index.tsx

[bluebill1049]

you just need to pass register as prop

[bluebill1049]

looks like i forgot to update the codesandbox, i will do that tonight.

[BigWhale]

The example also needs updating. Well, either one will work. :) Thanks!

[BigWhale]

I see the updates now. This is now working, but I have a question. I would like to create a generic Input component that would simply wrap <input> and I have trouble passing register to it.

Making InputPros to accept a type is a good start.

type InputProps<T> = {
    label: Path<T>;
    register: UseFormRegister<T>;
    required: boolean;
};

How do you declare a component then? This below won't work because InputProps requires an argument.

const Input = ({ label, register, required }: InputProps) => (
...

My custom Input component should work in many different forms.

[dolie]

Hello,
The migrating doc says :

The register function itself will return the following props: onChange, onBlur, name and ref.

How to use react-hook-form@v7 with home-made controlled components already using onChange and onBlur (with specific features associated with it) ?

[bluebill1049]

use useController or Controller for controlled inputs.

[dolie]

Does it mean that I should call react-hook-form's onChange from my controlled component's onChange function ?

[bluebill1049]

yes, with from useController

[radoslavkarlik]

Hi, I really like the new API and wanted to ask if you plan to improve typings for a useController/Controller.

type ControllerRenderProps {
  ...
  value: any;
  onChange: (...event: any[]) => void;
}

This means there is no type-safety for the value and onChange handler so basically, any custom input will need a bit more caution to not introduce bugs in the app.

However, other parts of the API such as useWatch or setValue infer the value type from the field name because of the FieldPathValue<TFieldValues, TName> instead of just any.

[radoslavkarlik]

Also, I have noticed that ControllerFieldState could be updated too. The error prop can be undefined as at least the resolver function is supposed to return errors: {} in case of no errors.

export declare type ControllerFieldState = {
    error: FieldError; // can be undefined too
};

[bluebill1049]

thanks @radoslavk 👍

[bluebill1049]

please don't hesitate to send us PRs too :)

[bluebill1049]

Thank you for everyone's participartion. V7 is released.

[wdfinch]

Congrats! Great work!

[samantha-wong]

Congrats on the huge release @bluebill1049 !!! We really appreciate all the time and effort put into RHF. 🙏🥳

[bluebill1049]

Most welcome @samantha-wong thank you for your support alone the way.

[bluebill1049]

Congrats! Great work!

Thank you @wdfinch for all the feedback you have given along the way. This lib has your DNA in it.

[wdfinch]

Thanks!

[bluebill1049]

move to latest v1

[terebentina]

@bluebill1049 know that for every such user that has no idea how to properly use package versions and then blames your library, there are 100 of us who appreciate the work you do and do our best to help. We may not be too vocal about it but we're here. I honestly can say that you're the most responsive open source package author/maintainer I've ever seen and I've been around for a while :)
Keep up the good work and enjoy your weekend

[bluebill1049]

Thank you @terebentina very much for your kind support and reply. ❤️ I feel a lot better now.

[samantha-wong]

Gosh the Walter guy literally made my blood boil. I absolutely hate people who are ungrateful, does 0 code/monetary contributions and only shows up to demand and complain about things. I'm glad he got deleted. 😡

Enjoy the rest of your long weekend Bill 🍻

[bluebill1049]

Thank you @samantha-wong too kind ❤️ enjoy your long weekend too.

[t-hinley]

i am using react hook form version 6, but i havent seen image and files input using controller into backend django

[vimal1824]

can I use version 7 with react version 16.13.1?

[vimal1824]

Thank you for the quick response Bill :)

[craigmcc]

React support across 16.8 and later versions (I.e. support for hooks) has not been a problem. Changing Typescript APIs has been a problem - for me from 7.33.0 to 7.33.1 that broke the build of all my projects that depended on what FieldErrors means. Be vigilant in your testing.

[vimal1824]

I am using typescript v3.5.1 will it cause any issue for me if I use RHF v7?

[craigmcc]

Try it and see. If you are not using an API that got changed, things should still compile. Whether the functionality still works as your app expects should be up to your tests to find out. You have a test suite for your app, I hope.

[vimal1824]

Yeah, it's there, I might have to work on them too. Thanks for the reply.