You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Asynchronous defaults are commonplace as they're often retrieved from storage when a UI is rendering
My use case is such that the UI presents some default values on checkboxes and radio buttons. If the user has never saved them before it doesn't matter, the consumer of these values has the same defaults elsewhere. If the users changes any of these values, the non default values are stored when changed. When the form is retrieved, defaults are set and the changed values are retrieved and set.
The reason the default value in this example is "flash of default" is because it the default value briefly flashes into the field while the asynchronous value is retrieved.
Describe the solution you'd like
Some sort of asynchronous defaults/suspense compatible api to set default values would be incredibly useful I think. Ideally one which is aware that it is setting defaults so it doesn't trigger changes on the form.
Describe alternatives you've considered
Obviously this is why I was trying to use to try and prevent the rendering of the field until the remote data was ready so the user didn't see the default value, then the stored value.
I wonder if perhaps a function for the defaultValues config or defaultValue prop could be async and provide a means by which to tell react-hook-form that the values are async.
The other problem with using setValue or reset to update the default values after the form has first rendered is that it causes watch() and useWatch() to trigger (as the fields have rightly changed), but they're actually technically the defaults. This has caused me issues with autosaving on change etc as I render defaults, get saved values and put them into the fields, watch notices it changes and it tries to save again so lots of refs and value comparisons etc has to happen around that to stop it trying to save the values it just retrieved!
Thanks for the detailed feature request, I don't think we will implement such API for now, i will add a feature request and waiting for upvote for this issue.
Is your feature request related to a problem? Please describe.
Asynchronous defaults are commonplace as they're often retrieved from storage when a UI is rendering
My use case is such that the UI presents some default values on checkboxes and radio buttons. If the user has never saved them before it doesn't matter, the consumer of these values has the same defaults elsewhere. If the users changes any of these values, the non default values are stored when changed. When the form is retrieved, defaults are set and the changed values are retrieved and set.
The reason the default value in this example is "flash of default" is because it the default value briefly flashes into the field while the asynchronous value is retrieved.
Describe the solution you'd like
Some sort of asynchronous defaults/suspense compatible api to set default values would be incredibly useful I think. Ideally one which is aware that it is setting defaults so it doesn't trigger changes on the form.
Describe alternatives you've considered
Obviously this is why I was trying to use to try and prevent the rendering of the field until the remote data was ready so the user didn't see the default value, then the stored value.
I wonder if perhaps a function for the
defaultValues
config ordefaultValue
prop could be async and provide a means by which to tell react-hook-form that the values are async.Additional context
The other problem with using
setValue
orreset
to update the default values after the form has first rendered is that it causes watch() and useWatch() to trigger (as the fields have rightly changed), but they're actually technically the defaults. This has caused me issues with autosaving on change etc as I render defaults, get saved values and put them into the fields, watch notices it changes and it tries to save again so lots of refs and value comparisons etc has to happen around that to stop it trying to save the values it just retrieved!Related #2333
The text was updated successfully, but these errors were encountered: