Cross-request state pollution ?

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:

@Module({ stateFactory: true, namespaced: true, name: 'user' })
export class UserStoreModule extends VuexModule {
    public user: IUserModuleState['user'] = {}
}

This is my createStore function:

const createStore = () => {
    
    return new Vuex.Store({
        modules: {
            user: UserStoreModule
        }
    })
}
export default createStore

Module access is like this:

const userModule = getModule(UserStoreModule, this.$store)

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; to modOpt.store = store || modOpt.store;

and

function getModule(moduleClass, store) {
    if (moduleClass._statics) {
        return moduleClass._statics;
    }

to

function getModule(moduleClass, store) {
    if (moduleClass._statics && !store) {
        return moduleClass._statics;
    } 

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: UserStoreModule initializing ?

[Sharsie]

PR made, @AliLozano in the meantime, you can use npm i Sharsie/vuex-module-decorators#hotfix.ssr.1

[Sharsie]

Here is my working solution: https://github.com/championswimmer/vuex-module-decorators/compare/master...Sharsie:hotfix/ssrSupport Sharsie/vuex-module-decorators#hotfix.ssr.1

@championswimmer Is this something you would be willing to merge? Shall I PR the changes? I’ve done my best to preserve backward compatibility using _statics when store is not provided.

I can think of only one way this would break and that’s when someone would mix usage of getModule(module) and getModule(module, store), then two instances of the module would be created… but then again, this might be a desired behaviour, e.g. using two different stores: getModule(module, store1) and getModule(module, store2)

The behaviour of this would change with the PR, as now it always uses 1 module state… after the PR each module would use state from a different store.