render is called during or after dispatch depending on how dispatch was called

Depending on how dispatch was called, render method is called after dispatch or during dispatch, increasing total dispatch execution time. I’ve created a tiny example project to explain it (look at console logs for operations order): https://codesandbox.io/s/XoLlRLMxl In 1st case (plain) we call dispatch directly and have the following order:

action
reducer
dispatch: 0.345947265625ms
render

In 2nd case (promise) we call dispatch from inside promise resolve callback and constantly getting a different order:

action
reducer
render
dispatch: 1.508056640625ms

3rd case (setTimeout) is leading to the same order as 2nd

Probably 2nd and 3rd case are ok and render stuff + dispatch itself taking the same time in total as in 1st case. But when we need to dispatch two or more actions after resolving promise we will get a huge overhead (that’s how I discovered this issue). So is it a bug or supposed to be? And if that’s ok then could it be controlled somehow?

[gaearon]

setState does not change behavior in 16, but will likely do in 17.

[timdorr]

If you need to run after rendering has finished, use the React lifecycle. componentDidUpdate is exactly what you’re looking for.

Ultimately, this isn’t something for Redux to solve. It’s just how React behaves. It’s just a matter of looking in the wrong place. You shouldn’t look to Redux or connect() to ensure rendering guarantees. That’s React’s job and it’s got lifecycle methods for it.