Redux middleware SSR access to request and response for setting cookies

[bdefore]

Redux middleware SSR access to request and response for setting cookies

[bdefore]

@msvalina that's outdated documentation, and is no longer supported because the passing of express request and response objects was unconventional for redux middleware and was incompatible with other middleware that were expecting dispatch and state parameters. if you are attempting to build an authentication system, i recommend using headers. the JWT example shows a way of doing that.

[pristas-peter]

Could you at least pass req object in the renderer.js method html(config, tools.assets(), store, res._headers); for example like this:

html(config, tools.assets(), store, req, res._headers) or html(config, tools.assets(), store, req, res._headers, root)?

I need this to get the locale and userAgent from headers and dispatch these values to the store before initial render...

[msvalina]

@bdefore yeah I understand the argument that it is unconventional for middleware to be passed anything other than dispatch and state, but that raises a question should this fetcher be middleware or by just a regular helper. What was rationale for putting in it middleware?

[bdefore]

@msvalina the motivation was mostly historical, in departing from the RRUHE project. as is, it does get you some help in streamline your actions, but it's possible that redux middleware is not the best place to accomplish that.

[bdefore]

@pristas-peter that's an interesting approach. on the one hand, the Html helper is getting a lot of parameters already, but that may be the most reasonable way to get access to request (and response) objects outside of redux middleware. could you file a new issue/PR?

[pristas-peter]

@bdefore

I've got better idea, why not to dispatch action: {
type: INIT_SERVER,
meta: req
}

after creating the store...
all the reducers could do whatever they want with the request

[bdefore]

@pristas-peter If I'm understanding you correctly, a base Html (or Head, Body) component of universal-redux could itself be connected to props populated from a store that reacted to INIT_SERVER actions? Keep in mind that all of those components are currently serverside rendered.

[sompylasar]

👍 for an action dispatched after store creation.

Actually, there is one, "@@redux/INIT", but it's dispatched on both server and client, so need to check which cookie-setting side-effect to use (server-side or client-side).

[pristas-peter]

@bdefore I didn't mean it to use it in html component, rather that universal redux would export action name (type) which you could import in your own reducer and process the request object on server, or something else on client => there should be dispatched two actions, one on server (INIT_SERVER) and one on client (INIT_CLIENT), or maybe better naming like STORE_DID_CREATE

[sompylasar]

@pristas-peter As far as we don't have side-effects inside reducers, putting the cookie-reading code, like any other storage-reading and storage-writing code, into a reducer looks wrong to me, its place now is in action creators' thunks.

Reading cookies

I think it would better be an action COOKIES_INITIALIZED with the cookie values as its payload (but this way you'll have to list the cookie names somewhere in the configuration). This way would even allow you to test your reducers with different initial cookie values.

Writing cookies

This is an impure side-effect, so there is no place for it in the reducer. Some code capable of doing side-effects, like a React component, or a middleware, or an action creator thunk, should be introduced.

[pristas-peter]

yes, you are right, however we are using redux-saga for side effects

[sompylasar]

@pristas-peter OK, then you'll have cookie-reading and cookie-setting side-effects in a saga, if I understand correctly? I haven't used redux-saga but I'm a bit familiar with its concept. Please show an example code how you see it with sagas.

[shilpan]

+1 I am using radium and material-ui in a project and they both need userAgent for serverside rendering. It would be good to find a way to provide access to the userAgent to setup configurations

[smirea]

any update on this. @bdefore your jwt example doesn't work with SSR auth. If you login, disable JS and refresh the code received from SSR is with logged out state which is invalid

In the current implementation of the starter there is no way to pass the cookies (nor headers nor anything else) from req to superagent and therefore can't load the user data on the server

[bdefore]

Just coming back to this issue and catching up. If I gather what's being proposed, there's two options forward that I can see:

• Where headers are currently passedto the html component (or custom root components if they are configured), change this to pass req and res and leave it up to the component to parse what they need (headers, userAgent, cookies, etc.)
• Trigger an action of INIT_SERVER or INIT_CLIENT that contains req and res, post first render.

The latter approach looks cleaner to me, but implementation could be tricky: there is currently no concept of a redux lifecycle within UR. It just ferries along the redux middleware you'd like into the store creation and does not have access to the dispatcher.

How does everyone feel about the former approach?

[smirea]

I actually needed that functionality and went ahead and implemented it in a fork:

https://github.com/sageapp/universal-redux/commit/26a2bd9d0e22acdd907666a4c0ab565702984c26

So the former works out really well - there is probably a better way of doing it, but that gets the job done