How to properly manage conditional fields?

[rpmonteiro]

Hi Bill, fantastic job on this library and maintaining and closing issues like a champion. I absolutely love using it, and recommend it to pretty much everyone!

I'm not sure if this is a bug, or if I'm the bug (most likely lol), but I can't seem to manage conditional fields in a way that's predictable and doesn't make me tear my hair out.

I'm very sorry if I'm the one being a complete doofus. Your feedback would be much appreciated.
I tried to reproduce a minimal version on the codesandbox to illustrate the problem. Let me know if you want me to add more details.

Describe the bug
Values get reset without me doing so excplicitly.
Values get reset between mount/unmount of the form (I think this is by design, as it follows the normal form behaviour)
I've tried to manage it with useEffect() and register/unregister, but it's so difficult and the code so hacky... it's a nightmare :(

To Reproduce
Steps to reproduce the behavior:
Inside the codebox

Codesandbox link (Required)
https://codesandbox.io/s/react-hook-form-useform-template-gi2f7

Expected behavior
I want to have a bunch of conditional/hidden fields that I can manage, with the values staying where they are, with validation still being applied to them, without having to hack away like crazy and using setValue, watch(), handle onChange, onBlur, onFocus, etc etc etc... without making me want to cry lol

Desktop (please complete the following information):
Mac, latest version with latest chromium browser

[bluebill1049]

oh my god, I just shared a message on twitter today. Is this the problem that you having?

https://twitter.com/bluebill1049/status/1265505918852173824

[rpmonteiro]

Yes, very close to it. I've tried that approach, managing the register myself, but with more than 2 or 3 fields, it becomes crazy verbose, specially if you want to have the same behaviour as others, and manage blur/focus states, and validation seems to not be predictable...

[bluebill1049]

but with more than 2 or 3 fields, it becomes crazy verbose, specially if you want to have the same behaviour as others, and manage blur/focus states, and validation seems to not be predictable...

do you have a codesandbox that I can have a play with?

1. custom register (not working for you)
2. toggle visibility
3. wrapper Controller around your toggled inputs

[rpmonteiro]

I'll prepare one asap

[rpmonteiro]

Ok, I gave it another shot:
https://codesandbox.io/s/react-hook-form-useform-template-fd2zy?file=/src/index.tsx

[bluebill1049]

Thanks for the CSB I will take a look at it.

[JeromeDeLeon]

Chiming in, @rpmonteiro I inspected the csb you provided and you used reset with only partial values and because of that only those values that you provided will be injected as values of RHF.

// If you use this on your `onModalCancel`
reset({
  modalClientEmail: '',
  emailContent: '',
  emailSubject: ''
});

// the value of the form will only consist of those three, the rest will be removed. Try inspecting the logs you wrote. To solve this, either:

// 1st
reset({
  ...getValues({ nest: true }),
  modalClientEmail: '',
  emailContent: '',
  emailSubject: ''
});

// or 2nd
setValue([
  { modalClientEmail: ' }',
  { emailContent: '' },
  { emailSubject: '' }
]);

[bluebill1049]

I did a quick look as well, I will try to build something similar, I think the model pop up should be a completely separate form and store your result in a state lib.

RHF is close to when you building native form. pop up should normally be a separate form instead a form nested inside the form, it normally makes things harder.

[JeromeDeLeon]

I saw that too that the AppComponent can be componetize with smaller components to avoid that kind of problem 😄

[bluebill1049]

@rpmonteiro take a look my example: https://codesandbox.io/s/cocky-stallman-c7n0r let me know your thoughts.

[rpmonteiro]

Awesome. Great tips guys! Thanks so much :)

[bluebill1049]

@rpmonteiro feel free to ask questions next time. we are glad that we can help.

[rpmonteiro]

And that's why this library is already the best form library, and soon it'll be the most used... keep it up, Bill!

[Nantris]

FWIW I found the example to be very confusing when visiting it directly from the FAQ page. It took me probably ten minutes for me to figure out what I was looking at. It could use more commenting to explain what's going on IMO.

[bluebill1049]

FWIW I found the example to be very confusing when visiting it directly from the FAQ page. It took me probably ten minutes for me to figure out what I was looking at. It could use more commenting to explain what's going on IMO.

Thanks for the feedback. would like to contribute and to make it more developer friendly?

[Nantris]

I'm still wading through trying to replicate the method in my own project. It makes sense why it's convoluted to use in modals, but it's not easy to conceptualize about when you have a number of fields to manage. It's a super simple library in every other context though!

[bluebill1049]

I'm still wading through trying to replicate the method in my own project. It makes sense why it's convoluted to use in modals, but it's not easy to conceptualize about when you have a number of fields to manage. It's a super simple library in every other context though!

By the way, we are fixing this issue on V7, I think for now you can switch to shouldUnregister: false, which will prevent inputs ' value gets removed after unmount. The reason for such design was trying to align with native form, while I ignored the better DX aspect...

[Nantris]

Ah jeez I'm pretty sure I looked away from the shouldUnregister option as soon as saw "This prop is getting deprecated in the next major version." But now that you mention it, that works great for us!

When v7 is released will projects that use shouldUnregister: false need to make some changes to their code, or will it "just work" in v7?

Do you think it would make sense to mention that option on the modal/tabs FAQ page? Normally I'd think not for an option that's deprecated, but it's a real lifesaver in this context. The alternative would have been quite verbose.

[bluebill1049]

When v7 is released will projects that use shouldUnregister: false need to make some changes to their code, or will it "just work" in v7?

Yes, it will just work in v7.

Do you think it would make sense to mention that option on the modal/tabs FAQ page? Normally I'd think not for an option that's deprecated, but it's a real lifesaver in this context. The alternative would have been quite verbose.

👍