persistValue prop feature idea

[wdfinch]

It is common for large forms to be spread over multiple components (wizard forms) and/or be expandable (a toggle to hide/reveal part of a large form).

Right now it appears the library will only store form values that are mounted and will remove form values when they are unmounted. This leaves it up to the user to store these values (via redux, useState, context, etc.) and inject them back into the form if the component is mounted again.

This becomes tedious over many forms and seems like an unnecessary burden to place on the user. However, I do understand that there are cases where form values should be removed on unmount. For example, a user clicks a checkbox to reveal some additional options and then decides to unclick the checkbox to remove those options. We can assume those options are associated with the checkbox and are irrelevant if the box is not checked.

To meet both use cases, I propose adding a new prop to register and <Controller/> called persistValue or something similar. If this prop is used, then the value of the field will be persisted even after the component is unmounted. Obviously, it would not be persisted when the useForm component is unmounted. This would make it much easier for the user to keep track of values in conditionally rendered fields, while still keeping the default behavior and option of removing values on unmount.

What do you think?

[bluebill1049]

Hi @wdfinch thanks for the suggestion. I think if you dig around in the example folder, someone has submitted an example.

The rational on the design with react hook form is more aligned with native form behavior which includes its validation when an input gets unmounted and value should be removed (according to the current design) However, we do understand the concern and inconvenient to change most of us (React developer's mindset), hence I have introduced shouldUnregister: false at the current v6 as a workaround. I think a large major of React developer seems to be more comfortable with the behavior which you have described above. however, I don't agree on large form or wizard should capture entire forms state inside a single useForm, at least that's not what useForm was designed for, it's designed per form, same as the purpose of the original form tag, it's not a formWizzard tag for HTML.

Those are my personal take on the matter, as more developers having issues around inputs get unmounted and values get removed, (which can be solved by toggle the CSS as well) we are removing that config together in v7, and users will have to unregister manually. you can read more on v7 RFC.

[wdfinch]

Hi, @bluebill1049 thanks for the quick reply. I read through the v7 RFC and from my understanding it sounds like values will be persisted by default in v7 even after an unmount. If that's the case, that sounds like a good solution to this problem.

I understand you're reasoning and design goals. It's more true to the original design goals of the form tag and that makes sense. For me personally, I view a form as containing a set of inputs. Whether you create many small separate forms or one large form really depends on how disjoint/separated the inputs are.

I think in examples like the one you have for the wizard forms where the forms are on different routes, it makes sense to separate the inputs into separate forms as they are very disjoint. However, this is somewhat of an extreme example (merging form data across multiple pages/routes).

In most cases, a form will be on a single page and contain a small set of connected inputs. Whether they are all visible on the screen or not is merely a UI detail. For example, if want to hide some inputs because they are taking up too much space, I shouldn't need a separate <form/> and useForm hook for that as they are logically part of the current form.

While CSS can be used, I don't think it's very clean nor react like. Additionally, it's can negatively impact validation. For example, I might want to allow the user to proceed to the next step in a wizard form when the mounted input is valid, but using display: none with all the input mounted could break this (input on the next page isn't valid yet so I can't move forward). Also, it increases the number of react nodes rendered.

This (the use of <form/>) is the mindset of react-final-form, redux-form, and I believe formik. Not saying this is the right outlook, just that many React users will expect this functionally and might be surprised when it isn't easily obtainable.

Lastly, something to consider is the ongoing increase in the complexity of websites. When many of the HTML tags and native behaviors were defined, the web was much simpler. However, as time has gone on, websites have grown exponentially in complexity. With that many of the native behaviors just don't cover more advanced use cases (which are becoming more common as time goes on).

I like how the library stays true to the native behavior and understand the downside of adding too many features/becoming too broad. However, as time goes on more and more users will likely need to cover advanced use cases far beyond the original behavior of the form tag. Obviously, you and the community must decide what's best for the library but just something to think about from an outside perspective and someone who works on large/complex React apps.

[bluebill1049]

100% agree with your statement above. I think my intention and goal is once again to be more align and getting close to native form, and hence we have better performance and DX for any web developer. So v7 will be the one you are after, but I will still recommend and supporting form by its nature to the rest of the users whether they r beginner or advance users. Thanks for the participation and feedback, honestly I am really appreciated all of them. Let's (I need more feedback and ideas like yours) make the next version of RHF even better DX for all types of users.

[wdfinch]

Sounds good. I will review the original design spec of <form/> more. I guess because I work on enterprise-grade React apps with extremely complex forms, I view the form tag as more of a sematic element rather than something to guide the behavior of the form. This at least is the attitude of many React devs who work on larger projects. Most of the forms I work on are so complex with so many requirements, that the traditional use of the form tag is rarely adequate. Happy to see the direction V7 is going and provide feedback. My perspective and use cases are definitely more extreme than a lot of React users so maybe not representative of most people, but hopefully, it can make the library better.