Problem: How to handle dynamic store on runtime?

[AhsanAbrar]

suppose I have multiple travelers with the same state fields Name and Age.

of course, we will not create multiple store files like this:

stores/traveler-1.js
stores/traveler-2.js
stores/traveler-3.js

how can we create a traveler store dynamically with different id?

---

My Current Solution

// stores/traveler.js

import { createStore } from 'pinia'

export const useTravelerStore = function (name) {
    return createStore({
        id: 'traveler-' + name,

        state: () => ({
            name: '',
            age: ''
        })
    })
}

and using in Traveler.vue like this

import { useTravelerStore } from './stores/traveler'

export default {
    props: {
        name: String
    },

    setup({name}) {
        let { state } = useTravelerStore(name)()

        return { state }
    }
}

and use traveler form as:

<traveler-form name="one"></traveler-form>
<traveler-form name="two"></traveler-form>
<traveler-form name="three"></traveler-form>

is there any better solution or that way is ok?

[posva]

I don't understand what you are trying to do. The way I understood it right now is that it would be better to have one store where you progressively add new travelers rather than creating a whole new store for every traveler. But I don't know about the context of your app and maybe creating stores on the fly and storing them somewhere (which looks like what you are doing right now) is the way the go.

Regarding calling useStore every time we use the store, this only matters when doing SSR or caring about code splitting

FYI the id of the store if for devtools purposes (extracting, restoring state)

[AhsanAbrar]

I have just created a very small example to understand this kind of scenario.

here is the demo link:
https://pinia-multi-travelers-example.netlify.com

here is Github repo:
https://github.com/AhsanAbrar/pinia-multi-travelers-example

in vuex we use dynamic module for that

because there are multiple dynamic travelers but state fields are the same.

Rest of the things of pinia is really appreciatable 👍

but the dynamic part is missing.

any suggestion?

[posva]

Thanks! Yeah, so I would use one single store and add a new entry for each traveler, probably in an array

[AhsanAbrar]

how we will define fields in array like Name and Age?

how v-model will work with array?

can you please give me a little example, how this scenario will work in array or alternate way?

Thanks

[posva]

I was thinking of a regular array travelers where

travelers.push({
  id: someGeneratedId,
  name: '',
  age: ''
})

It doesn't really change v-model, you go through the array of travelers with a v-for:

<li v-for="traveler in travelers" :key="traveler.id"><input v-model="traveler.name"></li>

In vuex, the point of dynamic modules was adding store pieces by plugins and also lazily loading them. But on Pinia, due to its api, this is no longer a concern.

[vuejstime]

hello i'm using nuxt2
i also have the same scenario but my scenario is a little complicated:
imagine i have some product and some filters in sidebar and my filters related on category_id i want to cache data for each category, for example if user click on mobile category then tablet and backed to mobile i don't want refetch the api request for mobile category again and use data i already fetched before.
in this scenario if i use an object or array for my store i have to return a method on each getter and pass category_id to getter to get related data for that category and it's very hard i think.
what is your solution for this scenraio?

[vuejstime]

another solution i thought about is to set an active id for category to store and use it in my getters it's straightforward but whats wrong with this above idea?

[chiragparekh]

@AhsanAbrar How did you manage to work on this issue?

[Sjoerd82]

I ran into a similar scenario, where an array does not seem to be an appropiate solution and used the original proposed solution from AhsanAbrar. This works great (just remember that createStore is now defineStore!).

This discussion moved away from his solution as it was not appropiate for the acutal proposed scenario. I have used it, so-far without issues. Any caveats to this approach? If this is an anti-pattern I'd like to hear why.

[ijpatricio]

I also landed on this discussion, looking for dynamic stores.

While building a "custom dashboard builder", a user may define a page with N variable metrics.
Each metric is a SQL query, that will see its result shown in a chosen Chart type.
The query has filter parameters, which are also dynamic, and these must be sent to the backend while changing parameters and after these are applied.

So, in this example (simplified for the show case), we have a Metric, which has a Dataset, a ParameterPanel, and many Parameters.

I think each Metric (Tile/Card on page) should have its store. Making a Store for all the page, which in turn would have an array of Metrics would be just overwhelming.

I'm also going with the approach of @AhsanAbrar , combined with "lodash uniqid" go help lme generate unique store names.

I'll come and share results when I have them, but for the experiments I already conducted, it all seems fine!

And just like @Sjoerd82 said, the method name is now changed to: defineStore

Thank you so much!!

[toniengelhardt]

I think a common use case would be if you have for instance a complex project management app where each project has a lot of stuff in it, folder, files, lots of models... Then, in the UI you have a dropdown where you select a project. Would be nice to be able to dynamically create one store for each project and not having to worry about filtering for project in lists, etc.

One important aspect is also when you use persisted-state, which will always write ALL data into localstorage when anything changes. This can get really slow if you cannot split up projects...

And another case, which I currently have in two apps is that you build everything and then want to add "projects" later. Without dynamic stores you have to refactor everything, but with dynamic stores you can just leave everything as is and just swap the store when you select a different project.

[JohnCuba]

Try just use dynamic components! For me it works just fine.
Bind key prop to component that have dynamic store, component will remount with right store.