Description
Version
2.3.0
Reproduction link
https://github.com/Harper04/vuex/tree/bug/ssr
Steps to reproduce
Either:
Clone the linked repo and run npm i && npm run test:ssr
Or:
Run tests in your own repo with (this mimics the environment vue sees during ssr rendering):
VUE_ENV=server npm run test:unit
Or:
Have a project with a lot of stores and watch for weird ssr behavior
What is expected?
The tests should run.
Your store logic should behave exactly the same no matter whether you run it in your browser or during an ssr data prefetching step.
What is actually happening?
Vue turns of reactivity in case of server side rendering the moment you create/import the an vue ssr renderer. For frontend components/real rendering this is perfectly okay and an important optimization.
The problem is that vuex also uses a vue instance internally in order to get the reactivity and caching for getters etc. Therefore also the reactivity of vuex is turned of during ssr. Every getter will return whatever it returned the first time it was called (think of isValid getters or filtered lists)
Debugging:
I did run the tests and my project with a modified version of vue where the isServerRendering check in the observer part of Vue is deactivated which worked fine.
I also tried to just return the getter function instead of the computed property in mappedGetters (vuex) which also worked for me (but not for the tests).
PR?
I've tried to come up with a pull request where vue would get another constructor variable like forceReactivity or dataOnlyVueInstance which vuex could pass in during instantiation.
Unfortunately apart from hacks i could only think of solutions which meant to much work for the risk of solving it in a way you would not accept.
If you could show me a way to pass vm.$options parameters to the observer module without touching too much code i would still be happy to do a PR.
Am i right here?
This seems like a bug for vuex which should be solved by enhancing vue itself. Should i create a feature request there?