Sharsie
commented
5 years ago @arenddeboer I searched here and there and could not find a real solution anywhere... several hours later, I hoped to have a working solution for SSR, but as I dug deeper into the source code, I realized it's not as simple as previously thought.
So there are two main issues.
Caching issue
Whenever function getModule is called, it first looks up _statics property on the Module class.
If not found, it generates a new one and sets it into _statics. _statics is basically your generated @Module class
This property includes stuff like state, store and other shenanigans...The problem is that we will share these "statics" when we receive a couple of requests at the same time... we could get rid of it or skip generating state and just generate mutations etc as these will not change...
Store being stored with the Model
Much bigger issue become the following lines of code from the module generator. It creates a _genStatic method on the Module Class (this is called when getModule is invoked) that accesses an outside property modOpt which again, is shared between requests during SSR. modOpt being @Module options.
It also uses the store from modOpt by default, eventually overriding it if it is not defined in @Module ... what this effectively does is that it sets the store into modOpt object the first time you call getModule with store arg or when you register your @Module with store parameter (you either must set it in @Module or you must provide it in getModule, so one of these times it will get set)
So, we could switch the condition from modOpt.store || store to store || modOpt.store but guess what...modOpt is static and shared on SSR, so again, the users would be setting the store between each other with the last one winning the fight and providing their version for everyone.
I am not sure what Nuxt uses, I am using vue SSR without it, but this led me to the conclusion, that this repository cannot be used in SSR without a larger overhaul. Shame really, because I really liked this one... I'll try a couple more and then I will probably go back to untyped vuex because I will run out of time.
Addendum
Actually there could be a solution that might not be too difficult to implement, but is super hacky...
It would require storing the statics into the store provided through getModule and rewriting all modOpt.store calls to use the statics from this store.
something along the lines of
function getModule(moduleClass, store) {
var moduleName = '_vuexModuleDecorator_'+moduleClass.constructor.name;
if (store[moduleName]) {
// Oh yeah, javascript, can do anything
return store[moduleName];
}
const statics = genStatic(store);
// yay for recursion
return (store[moduleName] = genStatic(store));
}// Simplified version, genStatic is actually generated on the module class
function genStatic(store) {
const statics = { store };
staticStateGenerator(module, modOpt, statics);
// Other staticaly generated shenanigans
return statics;
}function staticStateGenerator(module, modOpt, statics) {
// most of body removed for clarity
- return modOpt.store.state[modOpt.name][key];
+ return statics.store.state[modOpt.name][key];
}
// Other static generators
I'll see if I can make a fork tomorrow and adjust it for SSR. Can't guarantee it will work 100% safe when hundreds of request come knocking on the door, but I believe it could work and only testing will show up any issues with this approach.
arenddeboer
AliLozano
nles
I run into the classic cross-request state pollution scenario that is most often encountered when not using the stateFactory option. This is custom vue ssr project, modeled after the vue hackernews 2.0 repo.
I create my modules like this:
This is my createStore function:
Module access is like this:
I have setup a test environment to check if userModule.user.id is set just after initializing the store and module, and userModule.user.id is indeed set with the value from the previous request. When I modify the file dist/cjs/index.js and change:
modOpt.store = modOpt.store || store;tomodOpt.store = store || modOpt.store;and
to
This issue goes away, it looks the previous state is stored and reused somewhere and forcing to use the store provided to getModule() helps prevent this issue.
Strangely enough, I can't reproduce this with a clean nuxt project and the nuxt way of setting it up as seen in the readme. Does nuxt do some magic by creating a new module, other than my
user: UserStoreModuleinitializing ?