First, let me quote myself and briefly tell why would anyone ever bother about Server Side Rendering:
One of the potential candidates to become the company-wide standard were frameworks Next.js or Electrode, so why not just take it and forget about the pain. Or not? Maybe the pain will get even worse? Next.js comes with benefits, but also it comes with restrictions and opinionated patterns:
it does not havecustom routes out of the box, existing modules have their own caveats, popular React Router is not used
does not work with old-fashioned CSS, issues with taking third-party components with styles
same story with SASS/LESS
It may be good for beginners, but sometimes this lack of flexibility can’t be accepted. Next.js comes with pre-baked server side rendering approach, all you need is to plug your pages into it’s lifecycle and enjoy. You need to carefully analyze all potential tradeoffs before diving into Next.js world.
Next.js & Redux
I assume that if you landed here, then you should already know what Next.js and Redux are. For those who don’t: Next.js is a framework for painless React app development, capable of server rendering. Redux is a data framework that implements so called Flux paradigm, which, in turn, is a unidirectional data flow.
When it renders pages, it takes files located indirectory, grabs and uses static method of exported component to inject some props to it. The method can also be asynchronous. Same method is called both on server side and on client side, so the behavior is mostly consistent, the difference is in the amount of arguments that it receives, for example, server has (which is the NodeJS Request), client doesn’t have it. Both will receive normalized and .
Here is a minimalistic page component:
What we want to do on a server while rendering the React app which also has Redux inside? We’d like to dispatch some actions before we ship the resulting HTML to the client. For this caseis the best bet. We can prepare our Redux Store’s state there so that when component will be rendered, the state will have all the right things, so the resulting HTML will have them too.
But in order to do that we need to first prepare the Redux store, both on client and on server, while keeping in mind that on client the store must be a singleton, but on server store has to be created for each request. When store is created we’d like to inject it intoalong with the rest of Next.js things.
The same store must later be passed to React Redux, so that all it’s children will have access to it.
First, in has to be installed:
Next, we need to set things up:
Simple, yet, powerful.
The wrapper itself supports this scenario too, because it saves an instance of Store in request for server and in memoized variable for client, but authors of Next.js say it’s a bad choice from lifecycle perspective and you should never do that. Mkay… Instead, you can create your own HOC and dispatch whatever you want from there also from page-level, without even having the.