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

[MickL]

Works fine for me:

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

[miro-ku]

@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?

[miro-ku]

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

[em3link]

For anyone wondering, this doesn't seem to be documented, but you can destroy a store created dynamically using storeInstance.$dispose().

In my case, I have a collection of items (with computed properties) which I need to access in several components, so I created a dynamic store Map() like in the examples above.
I also keep track of an array of itemIds in a global store state.
Then I can remove an item from the collection by querying it from the Map and using $dispose() first, then deleting it from the Map, and finally splicing the id from the itemIds array.

Below a stripped-down sample from my code.

const itemsStores = new Map<number, ReturnType<typeof defineItemStore>>()

export const useItemStore = (itemId: number) => {
  return itemsStores.get(itemId)
}

function defineItemStore(item: Item) {
  return defineStore(`items/${item.id}`, () => {
    const id = ref(item.id)
    const name = ref(item.name)
    const quantity = ref(item.quantity)
    const price = ref(item.price)

    // Example of a computed value I need
    const costTotal = computed(() => price.value * quantity.value)

    return {
      id,
      name,
      quantity,
      price,
      costTotal
    }
  })()
}

export const useGlobalStore = defineStore('global', () => {
    const itemIds = ref<number[]>([])
    const _nextId = ref<number>(0)

    function addItem(name: string, price: number) {
      itemsStores.set(
        _nextId.value,
        defineItemStore({
          id: _nextId.value,
          name,
          quantity: 1,
          price,
        })
      )
      itemIds.value.push(_nextId.value)
      _nextId.value++
    }

    function removeItem(index: number) {
      deviceItemsStores.get(itemIds.value[index])!.$dispose()
      deviceItemsStores.delete(itemIds.value[index])
      itemIds.value.splice(index, 1)
    }

    return {
      itemIds,
      _nextId,
      addItem,
      removeItem
    }
  })()
}

[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.

[pcoterecollective]

Can you give more details please?

[aghArdeshir]

I really don't remember what was the challenge I had at that time 😅

This is the comment I left at the time

We have a root project (normal nuxt + vue + vite app). It included some child projects: the master app mounted the children (children each export a Vue component). Both the master project and the child project had their own stores in vuex, and (unfortunately) they had access to each other's stores ,they could read and write (with Vuex this was possible, because each Vue app (the master project) has one vuex instance that each component can get access to).

But with Pinia this was not possible directly, and I wanted to keep the code that allows reading and writing the stores (master <---> child). If I remember correctly, after investigations, I found out if two projects have two different pinia npm dependecies installed, then the runtime pinia (createPinia()) are different. So I externalized it in the child project, so in the final bundle, there is only one pinia)

[etranger]

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