v7: config shouldUnregister

[bluebill1049]

Context

In the first version of the hook form, we used to unregister inputs and remove their value & reference based on the component/input unmount. The initial design principle was trying to be closely aligned with the web standard and behavior. However, this yet to introduce confusion in the React community, and hence we introduced shouldUnregister at useForm level, so inputs value can be retained despite been unmounted. In V7, we removed such config to reduce configuration and also reduce the complexity in the codebase. Unfortunately, this solution yet become the perfect solution and many users upvoted this feature request: #4355 so we are trying to find the middle grand to solve this problem by providing desired developer experience.

---

Feature request

#4355

---

Proposal

Introduce shouldUnreigster

We believe by having this config at the component/hook will eventually improve the developer experience in general, providing the option for developers to choose the right behavior for their application requirement.

⚠️ IMPORTANT: the config should set either useForm level or hook/component level. useForm level config takes precedence.

Global level config

useForm({
  shouldUnregister: true // default to false
})

Component/Hook level config (can not overwrites global)

register('test', {
  shouldUnregister: true // default to false
})

<Controller  shouldUnregister={true} />

useController({ shouldUnregister: true })

useFieldArray({ shouldUnregister: true })

Note: Each one of them will invoke unregister at useEffect.

useEffect(() => {
  return () => {
    unreigster('name')
  }
})

---

PR (Draft)

#4758

let us know your thoughts, and we are looking forward to hearing your feedback.

[iamacook]

We have shouldUnregister enabled by default but have admittedly had some issues in the past. A global option is helpful, but I agree that the suggested syntax makes the most sense.

Are you also intending on having all defaultValues loaded in the form values on render? That is something I've been trying to navigate around in v7. I think, should a field be set to shouldUnregister, its defaultValue only be loaded when it mounts.

[wdfinch]

The issue here is conditionally rendered inputs. If we have a large wizard form or a form spread across multiple components, then any inputs that weren't mounted would not have their default values submitted (ex: what the user previously entered if it's an edit form).

Using display: none is not a valid solution here. See my feature request above for my explanation.

[bluebill1049]

This is a separate issue. :) there is another feature request, take a look at the board.

[bluebill1049]

here is the feature request: #4619

[bluebill1049]

FYI unregister by default will remove value from defaultValues as well, which is what you expected result.

[iamacook]

Ok, thank you. I will keep an eye on the other feature request.

[wdfinch]

I think the proposal is valid. The only addition I would like to propose is adding back the global option. This option would be easier to use than having to write { shouldUnregister: true } on every single input. The goal here would be just to maximize control. In V6 it was all or nothing. We could still keep that by adding the global option but allow precise control by adding an option onto the specific inputs.

[bluebill1049]

It will have to be either.

[wdfinch]

If we can only have one, then obviously the better choice would be to put it at the component/register level so we have the most control. It just might get repetitive for users that want every input to have shouldUnregister: true. Could you explain why we can't have both?

[bluebill1049]

Complexity in terms of implementation and potential more error-prone.

[wdfinch]

I see. Then I think what you proposed is the right choice here. This way we handle both use cases.

[iamacook]

If it's wanted on every component, I'm sure you could just add the value to a context and consume it in each component or something. I like the proposed syntax, nonetheless.

[wdfinch]

Additionally, another idea to think about is we need to keep in my what is the best user experience/makes the most sense not it worked this way in V6, change it back so I don't need to refactor my code. If we do this, the library won't move forward.

As most of the issues are focused around this and default values (I proposed this change in the RFC) my thoughts are:

shouldUnregister:
I see no harm in giving the user the maximum amount of control here. I see valid use cases for both sides. Regarding what the default should be, I think it really depends on the use case. All of my forms are giant wizards forms. Therefore, I prefer shouldUnregister: false by default. If you have a smaller form where everything is mounted at once and there are only a few optional fields, then shouldUnregister: true probably makes more sense. It's easy to set this boolean either way if it's present.

shallow merge of default values:
Again if you have a simple form where everything is mounted then I get that the shallow merge isn't really necessary. However, for larger forms where everything isn't mounted this becomes very helpful. A user might not visit a section of the form and we still want to submit some default input or what they previously entered. It's also very helpful for conditionally rendered inputs based on default values. If we need to show an input based on some other form values that haven't been rendered yet, this gets really hard without access to the merged default values.

Most of the issues here are:

1. I want to delete fields - use unregister for regular inputs or setValue for field arrays

2. Random stuff is being added to my form values - you need to parse what you send to default values to ensure it aligns with your form fields. Sending in random data that doesn't relate to inputs is not the proper use of the library.

3. I don't my default values submitted - again proper use of the library to set default values to values like "" or null. If you don't want to send this to your server or whatever, then just filter out these values. If you set the value to something truthy like "this is a default value", then in most cases this is something you would want to send to the server as a default value even if the user didn't change it. If not you could add a checkbox for the user to click to confirm whether they want to add the field.

If this is a real deal-breaker, there is a feature request to add an option to remove the shallow merge. You can vote on it under the projects tab.

[bluebill1049]

shallow merge of default values:

We have a separate issue to tackle, one thing at a time.

[mbretter]

After upgrading from v6, this is a big issue.
With v7, all the values from the defaults are submitted, even those with no related input.

It would help a lot, having the shouldUnregister switch back: useForm({shouldUnregister: true})

[bluebill1049]

I hear your concern, we should be able to ship this feature soon.

[bluebill1049]

PR is merged, thanks for everyone's participation.

[wdfinch]

Thank you!!!

[dwiyatci]

I'm really really feeling so lucky now because I'm only starting to upgrade my codebase to v7 today, and found out that there has been a couple of massive discussions/threads about this issue all along already, and better yet, the PR for tackling it was merged just a few hours ago. Honestly, this'd save me hours (if not days) of migration hassles, especially on the form validation and submission behaviour. 😭

God bless you, @bluebill1049. And thank y'all so very much! 🙏🙏🙇🏻‍♂️

[bluebill1049]

you are welcome guys, let's ship it on Monday once the doc is updated.