Redux-saga: Should I render twice for server side rendering?

Created on 29 May 2016  路  3Comments  路  Source: redux-saga/redux-saga

I'm new of redux-saga and trying to apply my universal-app with redux-saga.
redux-saga's real-world example renders root components twice for one response.
I think it will make performance slower if the react app become huge.
Why I worry is I can see people trying to make rendering reduce.

question

Most helpful comment

The 1st render is meant to activate componentWillMount methods which then dispatch actions for loading initial data. Actions are then handled inside sagas which will eventually update the Redux state on the server. The 2nd render (inside the then callback is the one that sends the HTML along with the cumulated state so for

I think it will make performance slower if the react app become huge.

As @oreqizer mentioned the bottleneck of an app is generally on networked calls (e.g. loading data from a remote API server or a DB) where the latency is -typically- far more superior to in-process function calls. But if you find that the impact of the 2 renders is significative on your app performance then you may try another solution which dosent involve universal Sagas (like attaching load actions as static props to your components, then inspecting those props inside the router's match function) .

I highlighted 'if you find' because the conclusion should be based on a real measurement of perf. costs not just assumptions.

All 3 comments

we use server side rendering in production at kiwi.com and rendering has never been an issue. it's the fetchComponentData stuff that's the bottleneck.

anyway, I have a universal react, router, redux saga etc. boilerplate here, the component's being rendered only once. I don't see a reason to render it twice. The rendering takes place here.

EDIT:
now that I think about it, if you mean that I first renderToString, insert it to the component root, then renderToStaticMarkup the whole thing - I don't really think it renders the innards a second time, since they already are rendered with all React's fancy stuff, and it's just a string prop anyway.

The 1st render is meant to activate componentWillMount methods which then dispatch actions for loading initial data. Actions are then handled inside sagas which will eventually update the Redux state on the server. The 2nd render (inside the then callback is the one that sends the HTML along with the cumulated state so for

I think it will make performance slower if the react app become huge.

As @oreqizer mentioned the bottleneck of an app is generally on networked calls (e.g. loading data from a remote API server or a DB) where the latency is -typically- far more superior to in-process function calls. But if you find that the impact of the 2 renders is significative on your app performance then you may try another solution which dosent involve universal Sagas (like attaching load actions as static props to your components, then inspecting those props inside the router's match function) .

I highlighted 'if you find' because the conclusion should be based on a real measurement of perf. costs not just assumptions.

When u have server-side rendered markup already in place, use the following to avoid rending twice.

const rootEle = document.getElementById('root');

if (rootEle.hasChildNodes()) {
  ReactDOM.hydrate(<App />, rootEle);
} else {
  ReactDOM.render(<App />, rootEle);
}
Was this page helpful?
0 / 5 - 0 ratings