Is there a way to compose form objects that have separate schemas? #11891
Replies: 1 comment
-
It's often appropriate to take what are considered "form values" to state management outside of the form, especially if you require special handling of sequence of events, and so on. I'm doing something similar to what you are describing by maintaining certain meta attributes of each field (state: disabled, hidden, loading, and data: field-specific data like Select options that could be decided by other fields and written to meta.data). This splits up any schema I pass to a form into Dynamic paths are required to pull this off, just as you demonstrate in your last snippet. There's nothing wrong with this whatsoever. If you come up with a pattern that suits your application (or better yet, a pattern that suits you beyond just this one application) then you can make this a rather comfortable place with some getters and setters of a bespoke design. Just look out for nesting of complex fields, lists etc to make sure you are not duplicating work the deeper your values go. My particular design requires further data structures and decisions outside of this system, so i employ zustand with immer middleware to maintain an external store to be used by rhf's resolver and each individual field (if it needs it), through a very performant subscription to the store. Obviously for this kind of setup, my forms are controlled - and that is desired due to the specific sequence of steps that must be taken as a result of most value changes. |
Beta Was this translation helpful? Give feedback.
-
I have a form that uses a nested schema structure. Currently I used zod and compose my schemas, and then feed them into the resolver like so:
This works nicely and results in a form schema structure that looks like:
So now if I want to set a value in
schemaC.fieldC1
, I can do the following:Since these schemas are re-usable and composable, in theory I can plug
schemaC
into a complete different composition, example:But now setting a value, I need to do:
What I'd like is to have a pattern where
schemaC
can live stand-alone along side the parent schema so that I can make changes to it directly, without having to step over the parent schemas, ex:Perhaps this would require multiple form objects that I can merge together?
Or perhaps there is a way to make the parent path in the
form.setValue
dynamic, like so:This would allow me to create a set of re-usable input fields that are related to
schemaC
and can be plugged in to any form without having to reference each parent path that might be unique to the overall schema.I know this was probably a hard read. Rather difficult to explain the problem. But if you've followed along and have come across a similar problem w/ solution, I'd be very interested in hearing about it.
Beta Was this translation helpful? Give feedback.
All reactions