These posts that detail the setup are great, especially with constantly changing API's like webpack version 4 and react-dom's hydrate versus render.
I really love getting server-side rendering to work, it's just so magical to be able to use the app's component code on both the client and server side. And it's great for sending over pre-rendered markup, which eliminates much of the initial wait time while the app is fetching data.
However, it's important to note that the performance gain is mostly client-side. Enabling server side rendering creates much more work for the server. The server becomes responsible (at least for the first load) to fetch the data to hydrate the initial state in addition to rendering the markup.
It would be interesting to see a post that describes a good strategy for splitting the routes in a react-router-powered React app that need rendering and those routes that do not (like public article/posts that want to be indexed versus a private profile administration page behind an auth wall).
Agree. Great comment.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.