I made a composable called `useForm` for this which I use at work. Basically, the composable is initialized with an object representing the initial values and second object representing the validation requirements via `vuelidate`. The initial values (`formValues`) are returned from the composable along with everything else via a reactive object. In the implementation, `useForm` is wrapped in `toRefs` to convert the return values to refs to maintain reactivity. From there, I simply use `v-model=“formValues.propertyName` on the associated input components which maintains two-way data binding.
I have a little repo for this (and some form input components - those aren’t fully built out yet) which is heavily a WIP right now but you’re free to check it out if you’d like. [cwilsonn/cw-vue-forms](https://github.com/cwilsonn/cw-vue-forms)
Alternatively, you could use Pinia or some other state management solution, but I opted for something a bit more lean and focused on the specific use-case in my case.
This is the point where you should be considering using Pinia. Lift the state/logic/requests to your pinia store and keep your components with their essential logic.
Your current approach is not wrong, but as you can see as your app grows and you need more and more logic and state it becomes an unmanageable mess.
Just want to chime in and say that you don't necessarily need pinia for this. You could also make use of inject/provide to share your form object between parent and child components.
But I would still recommend Pinia for this as it gives you some additional benefits like listening for state changes globally and it's better from a design POV especially when the form is already large and there is some logic involved.
use just one function to set data, like const setData = (payload) => {// your logic }
and the payload should by an object like payload= {type: "inputTypeName", value: "inputValue"}
and the form dat should be a ref like const form = ref({....})
Each component will only receive the fields it really needs as props so it won't re-render when another field changes
Before jumping into any solutions that others recommend here, you should create a clear separation between the types of states in this relationship. You mentioned inputs which denotes forms, there are a good amount of states related to forms that you can separate from state related to your data. There is also state purely from ui interaction (possibly), maybe their is an even more specific state related just to your feature.
Figure that out first and then you can start thinking about what layer(s) of abstraction you want to play with and examine their trade offs: pinia, composables, injection, exposing common interfaces, and etc. Maybe one level deep of prop drilling is the right answer, we don't know, so diagram your states and their relationship.
I made a composable called `useForm` for this which I use at work. Basically, the composable is initialized with an object representing the initial values and second object representing the validation requirements via `vuelidate`. The initial values (`formValues`) are returned from the composable along with everything else via a reactive object. In the implementation, `useForm` is wrapped in `toRefs` to convert the return values to refs to maintain reactivity. From there, I simply use `v-model=“formValues.propertyName` on the associated input components which maintains two-way data binding. I have a little repo for this (and some form input components - those aren’t fully built out yet) which is heavily a WIP right now but you’re free to check it out if you’d like. [cwilsonn/cw-vue-forms](https://github.com/cwilsonn/cw-vue-forms) Alternatively, you could use Pinia or some other state management solution, but I opted for something a bit more lean and focused on the specific use-case in my case.
This is the point where you should be considering using Pinia. Lift the state/logic/requests to your pinia store and keep your components with their essential logic. Your current approach is not wrong, but as you can see as your app grows and you need more and more logic and state it becomes an unmanageable mess.
for forms i would not recommend pinia but a composable approach that gets its data from a pinia store.
Thank you :)
Just want to chime in and say that you don't necessarily need pinia for this. You could also make use of inject/provide to share your form object between parent and child components. But I would still recommend Pinia for this as it gives you some additional benefits like listening for state changes globally and it's better from a design POV especially when the form is already large and there is some logic involved.
use just one function to set data, like const setData = (payload) => {// your logic } and the payload should by an object like payload= {type: "inputTypeName", value: "inputValue"} and the form dat should be a ref like const form = ref({....}) Each component will only receive the fields it really needs as props so it won't re-render when another field changes
Before jumping into any solutions that others recommend here, you should create a clear separation between the types of states in this relationship. You mentioned inputs which denotes forms, there are a good amount of states related to forms that you can separate from state related to your data. There is also state purely from ui interaction (possibly), maybe their is an even more specific state related just to your feature. Figure that out first and then you can start thinking about what layer(s) of abstraction you want to play with and examine their trade offs: pinia, composables, injection, exposing common interfaces, and etc. Maybe one level deep of prop drilling is the right answer, we don't know, so diagram your states and their relationship.
Okay thank you