Breaking change in v7 - componentDidUpdate order

[macobo]

We are running into some difficulty updating to v7 due to what seems like a breaking change.

Context: We're rendering react inside a larger non-react webapp, where when user does some action, some hidden forms get rendered and the form submit.

We detect if it's time to submit by using componentDidUpdate method on a parent component - relying that child forms have re-rendered by the time componentDidUpdate has been called.

With v7 this seems to be broken - componentDidUpdate for parent is called before child render.

Repro: https://codesandbox.io/embed/eloquent-bas-b12b6

V7 order:

V6 order:

This seems like a bug to us as official docs state

componentDidUpdate() is invoked immediately after updating occurs. This method is not called for the initial render.
Use this as an opportunity to operate on the DOM when the component has been updated. This is also a good place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed).

Is the order in v7 intentional?

[markerikson]

We aren't using componentDidUpdate in v7, as connect is now implemented with a function component and hooks instead of a class.

Now, we are using useLayoutEffect to propagate change notices, which is supposed to run in the same phase as componentDidUpdate, but it's certainly possible there are timing differences.

React-Redux has never explicitly guaranteed the kind of behavior you're describing - that falls under the heading of implementation details, and isn't part of our public API.

[macobo]

Hi mark, thanks for the quick answer!

Is there a way to know once all changes have been processed and components re-rendered following an action being dispatched?

[markerikson]

Unfortunately, not that I know of. I wish there was - it would be helpful for some of our benchmarking efforts.

[macobo]

I guess we have no other choice but to try remove our dependency on this behavior going forward, though I'm really surprised by this. Thanks for the help regardless!

[markerikson]

Yeah, it's amazing how many subtle aspects of behavior people rely on and assume that it's "correct", even though it's actually implementation-specific. For example, in v6 we switched to passing store state via context for consistency, only to find out that people were relying on the immediate changes being reflected in child components in earlier versions when mounting code-split reducers via lazy-loaded components.

[markerikson]

Actually, looking at the lifecycle trace, I think the other issue may specifically be with v6 versus other versions.

In v5 and v7, we implement our own store update cascading logic in order to enforce top-down updates. Connected ancestors notify nested connected descendants after the ancestors have finished rendering. This does actually mean that parent components are likely happening in a separate render cycle from the descendants.

In v6, everything was done via React's normal top-down rendering pass.

Thinking about it, that does likely mean that a parent will have completely rendered and be done, before a nested connected component renders.

[ckedar]

The root cause of this error is wrapping the ConnectFunction in React.memo, which makes the connect HOC a PureComponent which it should not be.

For now, as a workaround, pass {pure:false} as fourth param to connect for child.

[markerikson]

@ckedar : no, that's not correct, and I don't know why you're saying that.

connect has always behaved as a PureComponent equivalent, but with a stronger net guarantee: if the combination of const mergedProps = {...ownProps, ...stateProps, ...dispatchProps} hasn't changed, then your own component won't render.

The React.memo() usage in v7 is a key part of that implementation, and is necessary for acceptable performance.