Multi-instance stores rooted to specific component instances?

[Infeligo]

I'll try to explain the idea by describing my use case. Maybe, there is already a better solution for it.

Imagine you need to implement something like a datagrid - a searchable, sortable, filterable and pageable table of some data. This is a complex component composed of many sub-components. Naturally, you want to separate the state management part into... a store. This would keep the current search and sort criteria, found results and maybe some state related to the appearance and behavior of the datagrid parts. It would also have actions to call search API based on the current state. Such store would allow all sub-components to access the data and to modify it (e.g. trigger search) in a controlled and uniform way.

The problem is that all the store libraries like Vuex and Pinia provide global central stores, which are tied to the application root. However, there are valid use cases when several datagrids are displayed on a single page (e.g. some kind data comparison). The state of each datagrid component tree should be independent from others and its lifecycle should be bound to the lifecycle of its root component.

Can this be achieved with Pinia?

[joshkrz]

I know that you can spin up multiple instances of Vuex modules. I'm wondering if this can be achived in Pinia to solve the exact situation your describing.

[ccqgithub]

I'll try to explain the idea by describing my use case. Maybe, there is already a better solution for it.

Imagine you need to implement something like a datagrid - a searchable, sortable, filterable and pageable table of some data. This is a complex component composed of many sub-components. Naturally, you want to separate the state management part into... a store. This would keep the current search and sort criteria, found results and maybe some state related to the appearance and behavior of the datagrid parts. It would also have actions to call search API based on the current state. Such store would allow all sub-components to access the data and to modify it (e.g. trigger search) in a controlled and uniform way.

The problem is that all the store libraries like Vuex and Pinia provide global central stores, which are tied to the application root. However, there are valid use cases when several datagrids are displayed on a single page (e.g. some kind data comparison). The state of each datagrid component tree should be independent from others and its lifecycle should be bound to the lifecycle of its root component.

Can this be achieved with Pinia?

maybe this can help you? pinia-di.

[markbaydoun]

Don't know if this still applies, but I found a way to do it like you say

useTableStore.ts

export const useTableStore = (tableId: string) => defineStore(`tables/${tableId}`, {
  state: () => ({
    foo: {},
    bar: {} 
  }),
  getters: ...,
  actions: ...,
})(); // <- this is the key right here, by initialising it here

Then in other component or components:

const tableId = props.table.id // Just as an example

const tableStore = useTableStore(tableId)

Assuming the tableIds are different for each table, they will use a new instance of this store, so they won't share state unless the tableId is the same

[sabifa]

This discussion is pretty dated already, is this still the recommended way? @posva
You stated that it could be added to the docs but it seems like that never happened. Is there a reason to it?

[MickL]

Works fine for me:

export const useProductStore = (productId: number) =>
  defineStore(`product-${productId}`, () => {
      console.log('create product store for ' + productId);
  };
})();

[mirik-k]

@MickL You should use productId in store name

[MickL]

You are so fast to reply :) I just found it out as well and updated my answer. Works totally fine, stores that are created once are cached as well.

I just wonder about garbage collection ... By time hundreds of stores could be created and will never be destroyed?

[mirik-k]

Yea, you should definitely determine the moment, when the store isn't needed anymore, and destroy it manually

[aghArdeshir]

I'm not sure if I'm the only one who understood the problem differently or not.
But I had the same issue, and none of the replies really worked fr me.
What worked for me in the end was to externalize pinia using webpack in the library and specifying it only as a peerDependency. So there was no pinia bundled in the final build.

[etranger]

Apparently, you can use internal component property this._uid as part of store identifier