Using Pinia as a local state manager for a page with complex, multi-layered components

[guypassy]

I am working with a team creating an SPA using VueJS, with Pinia as our global state manager.

We've had multiple issues using VueJS with complex, multi-layered components - specifically, in places containing lists of complex forms with different rules governing how a selection in one place affects the options in another.
A number of people on the team have suggested using Pinia as a local state manager for such pages.

The issues with VueJS:

1. Passing the values of a form using v-model is a problem because by definition the child components are not supposed to edit the props' values. They are supposed to emit a change event and the original component should be the one to mutate the value. This requires a lot of boilerplate and a lot of opportunity for the developer to make mistakes, even using typescript. Moreover, depending on how things are being passed, having to add .value to everything is just additional development overhead.
2. Passing the values using the Provide/Inject paradigm is problematic in that it:
   a. Does not currently have very good typescript support. You still need to manually give it a type, and pass things with strings or Symbols as keys and basically makes me feel like I'm using Vuex again :(
   b. Cannot be called from within a composable. Provide/Inject must be called from a Vue component's setup function/script block.

Pinia resolves all of the above by default. The only issue with Pinia is that, as a global store, it seems somewhat out of scope. Assuming we clear the data from the store when leaving the page (so no we don't hold large amounts of unneeded data in the background), and that the stores are actually only initialized when needed, is there a reason to not use Pinia in this way?

[posva]

a. Does not currently have very good typescript support.

It does 👀 , check the InjectionKey type.

b. Cannot be called from within a composable. Provide/Inject must be called from a Vue component's setup function/script block.

It can: a composable is called within a Vue Component (some other very specific places also work for global provide app.provide() only, like stores and navigation guards), therefore the composable creates everything within the context of the Vue Component itself.

I also suspect you don't need pinia (or state management for this). The new defineModel() for custom input elements should help with the boilerplate within custom input components.
When it comes to Form components, they could also use defineModel() but since you would be using the different properties individually, creating a helper composable to cater to your needs would be necessary to fully reduce the boilerplate.

[guypassy]

Thanks so much for the input. I'll look into those points. Looks like I didn't spend enough time RTFM.

[posva]

To be fair, it's not something you just find in the documentation ready to copy/paste 😅