Repository navigation
Docs Roadmap #829
Description
Activity
This is one thing I'd really appreciate clarified in the docs: mapStores.
I haven't had a chance to test it yet, but since the entire store is a computed property, I would assume that any modification of the store would result in re-rendering of all components subscribed to the store through mapStores. If this is the case, this is a pretty big caveat and should be documented clearly. I would suspect that due to the ease of using mapStores, a lot of users with big global stores might get into trouble.
I would assume that any modification of the store would result in re-rendering of all components subscribed to the store through mapStores
I don't think this is correct. If you had a "global"
reactiveobject and imported it into multiple components, it would only trigger a render if part of that object is tracked and that specifically is changed. For example if in one component you accessglobalObj.prop1within the template or in a computed etc. the render will only trigger if you changed theprop1property on that object, whether it be within the component or elsewhere. That's the beauty of reactivity.This concept is the same for stores, when created there's a global instance of them. Even if you imported the same store in every component (with mapStores or otherwise) it'll only trigger a change if a property has been tracked within that component, and that specific property changed. For example, you access
myStore.prop2within the template, it will only render again ifprop2is changed. If you don't access anything on the store, nothing is tracked, so any changes to the store won't cause a render.I'm using the words
trackandtriggeron purpose as that's in line with how the docs explain it, see https://v3.vuejs.org/guide/reactivity.html#how-rendering-reacts-to-changes & subsequent pages.Reacted by Eduardo San Martin Morote and Jason RooneyI would assume that any modification of the store would result in re-rendering of all components subscribed to the store through mapStores
I don't think this is correct. If you had a "global"
reactiveobject and imported it into multiple components, it would only trigger a render if part of that object is tracked and that specifically is changed. For example if in one component you accessglobalObj.prop1within the template or in a computed etc. the render will only trigger if you changed theprop1property on that object, whether it be within the component or elsewhere. That's the beauty of reactivity.This concept is the same for stores, when created there's a global instance of them. Even if you imported the same store in every component (with mapStores or otherwise) it'll only trigger a change if a property has been tracked within that component, and that specific property changed. For example, you access
myStore.prop2within the template, it will only render again ifprop2is changed. If you don't access anything on the store, nothing is tracked, so any changes to the store won't cause a render.I'm using the words
trackandtriggeron purpose as that's in line with how the docs explain it, see https://v3.vuejs.org/guide/reactivity.html#how-rendering-reacts-to-changes & subsequent pages.That's pretty amazing! Do you have any idea if this might hold true for Pinia in Vue 2 as well? After reading the docs it seems as though I might just need to be careful with property additions and array mutations. Arrays are a non issue, but I'm curious what'll happen if I set an optional prop after the fact.
I can certainly see myself using mapStores over the alternative, as it becomes more obvious when the code is accessing the store.
In any case, can't wait to move to a full Vue 3 + Pinia stack in the near future. Perfect reactivity and typescript support is going to be a major boon to development.
That's pretty amazing! Do you have any idea if this might hold true for Pinia in Vue 2 as well? After reading the docs it seems as though I might just need to be careful with property additions and array mutations. Arrays are a non issue, but I'm curious what'll happen if I set an optional prop after the fact.
Yep, same for Vue2 (with @vue/composition-api of course) there's some slight caveats as you mention but the general concept is the same. You can use
setfrom composition-api to add additional properties in Vue2.I can certainly see myself using mapStores over the alternative, as it becomes more obvious when the code is accessing the store.
I prefer it. It also helps with conversion to composition api because I tend to declare stores in
setuplikeconst userStore = useUserStore(). So if I move a method for example into the setup function I just remove thethis.(sothis.userStore.load()becomesuserStore.load()for example) and it all works as before. Using the other map helpers needs a little more digging to find out where things came from originally.In any case, can't wait to move to a full Vue 3 + Pinia stack in the near future. Perfect reactivity and typescript support is going to be a major boon to development.
Couldn't agree more.
I'm keen to write up some further documentation and cover some of these points. @posva Are there are works in progress for further documentation atm on any branches? And what's the best way to ask you a question if I run into something I'm unsure of while documenting?
-=-
And also to add a suggestion on something to document further:
When the store values differ on Server and Client, such as when using useStorage from Vueuse, the client store needs to be hydrated manually.
There's a section on that within the API reference part of the docs here: https://pinia.vuejs.org/api/interfaces/pinia.DefineStoreOptionsInPlugin.html#hydrate
However, I wanted to propose adding a small section on it under state within the Guide part of the docs.
I originally opened an issue for this, but see it may be better sat under this issue. I'm happy to open a PR to suggest potential documentation for that. Let me know what you think :)
@Jamiewarb I added an item to the list and updated the issue about how to contribute. Let me know if it's missing anything!
I'm really keen on having cookbook entries contributed 🙂Reacted by Jamie Warburton, Etienne Maheu and Nazaré da Piedade- pinned this issue
on Dec 28, 2021 What I'm currently missing from the docs (also from the vuex ones) are some general guidelines and best practices to work with a store. Questions that would be nice to answer in this context:
- For what kind of 'state' do you want to use a store over say component-wise reactive variables
- How much logic do you put in the actions of the store vs in composables that use the store (e.g. should a
loginaction only setisLoggedInandcurrentUseror should it also call the API to fetch the new user config [which would be handled in a different store] and do some general logging for stats etc).
Reacted by Istiyak Tailor, Nazaré da Piedade and PrainLopez7 remaining items
- Spltting the store into multiple files (How to split store in different files? And the limits of object type inference #802)
👍 I'm looking forward "native" way to split a store
Reacted by JemsThe basic example should be rewritten in a clear structure that we can switch between Option and Composition API, overlap between option and composition is awful hard to read, confusing and overwhelm for new readers, my mind went blank despite an experienced programmer.
It feels like a tutorial written by someone's personal notebook?
https://pinia.vuejs.org/introduction.html#basic-exampleI agree #1265 is worth it and should follow Vue way.
I don't know if this has been considered, but it seems like Pinia can be used in a "namespace" way of handling stores that Vuex did. I really wanted to separate stores that are based off the same store file... eg:
// selection.store.js export const useStore = ({ namespace }={}) => { const storeID = `selection${namespace ? `:${namespace}` : '' }`; const store = defineStore(storeID, { state: () => ({ current: undefined, previous: undefined, // ... }), getters: { // .... }, actions: { // .... }, })(); return store; };
Instead of writing 5 different stores that do the same thing using the same content I just do this:
import { useStore } from 'stores/selection.store.js'; // ... define and use each store wherever needed in a separate namespace const selectOneStore = useStore({ namespace: 'one' }); // storeID => selection:one const selectTwoStore = useStore({ namespace: 'two' }); // storeID => selection:two const selectThreeStore = useStore({ namespace: 'three' }); // storeID => selection:three const selectFourStore = useStore({ namespace: 'four' }); // storeID => selection:four // ... do whatever with stores wherever each store is being used // ... if the same is being used without any namespacing const selectionStore = useStore(); // storeID => selection
... and now have stores
selection:one,selection:two,selection:three,selection:fourandselectionthat are independent from each other but use the same logic.They can be used by different things that handle completely different use cases, but use the same logic. They also appear in dev tools as different stores. The best thing is there is nothing weird or hacky on Pinia, it's just how one defines the stores.
I wish this is documented somewhere so that users can use this method of defining stores and also help transition Vuex code.
Could we add the docs for how to properly dispose a store, reset its state or do both (dispose and reset)?
I didn't know dispose doesn't reset the state, and, most of all, wasn't aware these two exist at all before looking into the GitHub issues.
These are the documentation sections I want to add or improve
useLocalStorage()watchingpatchmodifying in place objects $patch function replace value in remote object #1921If you have suggestions about common use cases that are not covered or improvement / refactoring for the existing docs, please share
How to contribute
If you want to contribute to the docs, make sure first there is no active Pull Request or an existing branch on this repository. Fork this repo, and create a Pull Request. You can mark it as WIP/Not ready for review if you need more time to work on it. This would avoid having two people working on the same thing.
If you are uncertain about anything you wrote, just leave a review on your own Pull Request so I can help.
Translations
If you want to contribute translations, only the Chinese and English versions are hosted within the repository. Other translations should be hosted elsewhere following the translation guidelines