Avoid stateful singletons in the SSR

[cmeyertons]

Current behavior

The same Vuex store instance is shared across requests -- because it contains users specific things like cart

Expected behavior

The vuex store should follow vue's recommendations.
https://ssr.vuejs.org/guide/data.html

[pkarw]

Hi, @cmeyertons does it causes any side effects in Your case? I mean:

• cart, user stores are used only in CSR (client side) therefore shoulnd't contain any data in SSR (there is no way to modify it in SSR)
• we're using runInNewContext https://github.com/DivanteLtd/vue-storefront/blob/68fcc9e145d53f3aa3ef0e05f79abcf64bc847d6/core/scripts/server.js#L55 - https://ssr.vuejs.org/api/#runinnewcontext it means each requests is being executed with fresh global context and Vue instance + Vuex stores are not preserving state.

Please provide us with more info - what exactly do You recommend to change and what kind of issues it causes?

[pkarw]

It's probably related to https://ssr.vuejs.org/guide/structure.html#avoid-stateful-singletons, correct?

I think we're safe with the note they posted:

This constraint can be eliminated when using the bundle renderer with { runInNewContext: true }, however, it comes with some significant performance cost because a new vm context needs to be created for each request.

Basically, this is our case. I'm not sure if at this point we can easily refactor state and stores from being singletons as all the core and user modules are created with this style...

Moreover, there are other singletons like route-manager, i18n, event-bus. I think that this is something that requires kind of RFC - to propose general changes to singleton management. The benefit of this refactor would be that we'll be able to switch the runInNewContext: false - potential performance benefit. But not sure if it justifies the refactoring efforts (as the SSR performance is pretty high anyway)?

[pkarw]

Related: #2522