How best to persist state between client renders, e.g. appContext

[jahredhope]

I've been trialling out vite-plugin-ssr as a possible replacement to my existing toolchain. VPS has really impressed me with it's features, and it's documentation for those features. Really amazing work. Thank-you to all the contributors.

One thing I haven't worked out how to do yet is to replicate things I'd normally create in my single JavaScript entry, like a persistent api client / store. This would usually happen before fanning out to separate pages. (e.g. render-entry.ts and client-entry.ts)

The docs mention that pageContext is deliberately not what I'm looking for:

"That's why it's called pageContext (and not appContext)" - pageContext

The docs also describe that persisting state is why you would choose client-side routing:

"Client-side state preserved across navigation." - Client Routing

So my question is, how? If I do want appContext how should I do it?

Any help or advice would be appreciated please.

---

Some ideas I went looked at:

• It doesn't seem possible to add an onLoad hook that returns an appContext, as a peer to render and onBeforeRender. Or any way to inject code that only runs once and is available for any future render (until the app reloads).

async function render(pageContext: PageContextClient, appContext: AppContextClient) {
...
}

• I could rely on module re-use. Using modules as singletons. In my experience this isn't reliable, especially with HMR or complex chunking strategies as the module may get duplicated.

If I understand correctly, I think the docs suggest this solution of singleton modules. So maybe that is the preferred method.

if (pageContext.isHydration) {
    // `pageContext.initialState` is available here
    initClientSide(pageContext.initialState)
  }

• I could create things in global space. This seems like the least desirable but may be the only reliable solution.

if(!window.globalStore) {
  window.globalStore = createStore()
}

[brillout]

Usually folks use state management tools such as Pinia for Vue, and for React Redux or its many alternatives.

These tools handle the global client-side state on the user's behalf. But, if you wish to handle your global state manually yourself, then there is nothing wrong with using the global scope window – just make sure to use a unique prefix such as window.__my_global_scope.someGlobalData to avoid conflicts with libraries and browser extensions. (You can also use a Symbol() to avoid conflict with certainty.)

Let me know if that answers your question. I'm glad you're enjoying VPS.

[jahredhope]

Thanks. I'll try handling the scope globally either though modules or window.

Though to ensure we are talking about the same thing: I am using Redux, and alternatives like it. As far as I'm aware these tools don't help solve this problem.

They'll help you create the store on the initial render, and access it throughout your component tree but then you need to persist that store somewhere to be re-used by the next page's render. Either using modules or global space as described above (or I was hoping for another option).

e.g.

// Redux helps you create a store
const store = configureStore({ reducer: rootReducer })

// Then it'll help you use it throughout your React components using a provider
root.render(
  <Provider store={store}>
    <App />
  </Provider>
)

However, if you put the above in a render hook, you'll be creating a new store every time the user moves between pages. Requiring you to store the store (excuse the pun) somewhere else between page renders.

So you can then store it in a module's scope:

let store;
export const setStore = newStore => (store = newStore)
export const getStore =() => store

Or put it in global space:

if(!window.store_to_use_during_render__please_dont_use_this_outside_render) {
  window.store_to_use_during_render__please_dont_use_this_outside_render = configureStore({ reducer: rootReducer })
}

root.render(
  <Provider store={window.store_to_use_during_render__please_not_use_this_outside_render}>
    <App />
  </Provider>
)

[brillout]

Exactly. Both are fine. (My personal preference would be to use the module scope, while using the global scope to assert that the module scope is instantiated exactly once.)

Btw. in case your company is up for it: https://github.com/sponsors/brillout. Any gesture is appreciated!

[brillout]

Thanks for the sponsoring 💚. If company sponsorship is on the table that would be great – but thanks already, I appreciate it!