-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When accessing stores outside the rendering context, store composition will get data from the wrong instance #2004
Comments
This is because you are calling an async operation in your action before calling the actions: {
async logItems() {
await simulatedBackendCall();
const user = useUser();
console.log(`${user.name}: ${this.items.join(', ')}`)
}
} You **have to move the actions: {
async logItems() {
const user = useUser();
await simulatedBackendCall();
console.log(`${user.name}: ${this.items.join(', ')}`)
}
} I updated the documentation to explain this. |
The repro you shared, without SSR, is actually way easier to understand, thank you for that 😄 |
I think your documentation additions are good! By the way, our SSR issue seems to be a combination with a bug in Vue also. I think Thanks again! Great documentation clarification, and thanks for being so quick about it. |
Btw, here's the Vue bug I talked about if you are curious: vuejs/core#7733 |
Reproduction
https://jsfiddle.net/tsz32r68/1/
Steps to reproduce the bug
Expected behavior
The JSFiddle ends with logging the user+cart contents:
The documentation is clear that the first
logItems
can log anything: we are outside Vue's context and do not pass the pinia instance to the store. The second line explicitly passesinstanceA
so we expect it to log Alice's items. The third line explicitly passesinstanceB
so we expect it to log Bob's items.All in all, we expect something like:
Actual behavior
The logs for the second line mixes the data. We explicitly pass the pinia instance for Alice, so we expect Alice's name and Alice's items. We get a mix of data: Bob's name and Alice's items.
Additional information
This showed up for us in SSR. When doing SSR we want to preload some data to the Pinia stores, before we even render anything. We use
serverPrefetch
to load the data. As pointed out in the docs pinia addsthis.$pinia
that we can use to provide the right instance to our stores. But the stores themselves will still get data from the wrong instance when they look for data on other stores.In most cases this just happens to work the right way anyway for us. Only when the previous request hit an error during SSR would Pinia pick the wrong instance.
I'll can try set up a minimal SSR repo showing this behavior in
serverPrefetch
too, if that would be helpful for you.The text was updated successfully, but these errors were encountered: