Is context provider in SSR mode necessary?

[bolu61]

Since pullstate implements an alternative to the context API, is there a way to avoid using it in SSR?

[lostpebble]

If you are manipulating the state during the rendering on the server-side and need to hydrate that state on the client side (which is generally always the case) - then there is no other way to go about it than using context.

Any library which does SSR and is manipulated during a render needs to have context- there's no way around it, because each separate user "request" on a server needs to maintain a unique state, which can't be controlled globally like we do on the client (otherwise all requests share the same state and clash / overwrite each other)- hence context is required.

If you are not manipulating the state during rendering on the server, then you don't need the context provider. But I'd recommend just putting it in anyway because you might run into weird issues in the future.

[bolu61]

For the sake of discussion, is it possible to implement PullStateCore without React's context API? For example using a simple map of all the individual stores. Since they are already reactive, we don't need context consumers for hydration (Correct me if I'm wrong). I'm asking because I personally don't like wrapping an app with a context provider component.

Something along the lines of:

// redacted

Edit: Nvm, I just answered my own question. It would in fact lead to very ugly code.

[lostpebble]

I feel you, I also had a big aversion to it- and tried my hardest to not have to use it with Pullstate. But when it comes down to it, and after much testing and thought, it just isn't something that can be done- conceptually, React needs a way to hold state during render on the server- which we pass on to the client- and context is what provides that.

I've come to understand the need for it and I don't dislike it as much as I used to though.