T
TanStack2w ago
old-apricot

Async form default based on another field

Is there a clean way to base an async form field default off of the value of another field? The issue with using the form's default values option is that it creates a circular dependency. Specific example, I have items which have an "inventory type" option. Inventory type can be retail or consignment let's say. Each item is connected to an account which has its own default for inventory type. So if the selected account is set to one which defaults to "consignment", I need to update the form default after fetching the account. The issue is that the fetch must be declared after the useForm hook because the fetch is using values from the form. This is an issue because then that default value is defined after the form. A workaround could be to store the defaults in a useState, and then set that state from the fetch, but that's a bit messy. Another workaround could be to set the default on the field, but that doesn't work because of this issue which has been closed as intended behavior. A final workaround (which is suggested in the issue conversation by me) would be to manually set the field value in a useEffect if the field is not dirty. This doesn't work always if the form is reset, and there doesn't appear to be any way to tell in a useEffect if a form is reset. Any suggestions are appreciated!
GitHub
Default value prop on field doesn't update · Issue #1154 · TanSta...
Describe the bug When using the defaultValue prop on form field, if the value is updated, the default doesn't update when the prop is updated. I could understand maybe if this was intentional b...
5 Replies
old-apricot
old-apricotOP2w ago
Ok, I've gone with the useState option, but it actually isn't working. The field is not dirty, not touched and is pristine, but it doesn't use the default value for some reason after I setState. isDefaultValue is false. I can make a minimal reproduction, but not sure why it isn't using the default when the field is pristine.
extended-salmon
extended-salmon2w ago
the reason is likely that the user has already touched the form, at which point the defaultValues updating should no longer override the user's values I believe that is currently at the form level instead of field level, so touching any field can cause untouched fields to not receive updated defaultValues. Is that the behaviour you're experiencing?
old-apricot
old-apricotOP2w ago
That's possible, I will work on a minimal reproduction to confirm. However, I think this is happening after I've reset the form, meaning all fields are pristine
extended-salmon
extended-salmon2w ago
oh ... hmmm. Yeah, if you can get a minimal reproduction working, I'd appreciate that also, based on this description, I can suggest some solutions. Keep in mind that I could be misunderstanding it, so correct me if I made a mistake. The user has control over two things: * A selection of accounts, which the user can choose one of * Inventory item properties, which are based on the account If I understood correctly, inventory type is not changeable by the user, but a descriptor dependent on the selected account. Therefore: If the user cannot change it, then it should not be part of form state. If inventory type falls under that category, then it should not be part of the form state. Merely data (from the query fetch) that can be displayed. As for values that are changeable (like Inventory Item name), those can be changed by the user and can still be fetched based on the account. So that leaves the final thing to handle - if a user changes an account after editing inventory fields, what behaviour should they have? should they preserve what the user wrote? should they be completely overwritten and go back to their defaults?
old-apricot
old-apricotOP2w ago
Not exactly, it's a pretty complex form. The inventory type can be updated by the user, so the account default inventory type is a default for the form. My current workaround is I'm both setting the defaultState as well as updating the form field value if the field isn't dirty

Did you find this page helpful?