Data: Rerun selection if state changed during mount

[aduth]

This pull request seeks to resolve an issue with the @wordpress/data withSelect higher-order component which would have prevented a wrapped component from receiving the most up-to-date store values if it had incurred a store state change during its own mount (e.g. dispatching during its own constructor).

Testing instructions:

Ensure unit tests pass:

npm run test-unit packages/data

cc @jsnajdr @Tug

[youknowriad]

👍

[Tug]

I did try it against https://github.com/wordpress-mobile/gutenberg-mobile/tree/add/gb-store-test and it fixed the issue 👍

[jsnajdr]

Subscribing in constructor can cause subscriptions to leak in two cases:

• when server-side rendering, constructor is called, but componentWillUnmount never is.
• in React Fiber concurrent mode, component instances can be constructed, but never actually committed to DOM. This can happen when Fiber is working through rendering a low-priority update (calling constructors and render methods) and suddenly a higher priority update is scheduled that invalidates the work that's been done. Then the unfinished low-priority work will be thrown away and restarted. In such a case, constructor is called, but the component(DidMount|WillUnmount) methods aren't.

The correct place to subscribe is therefore always componentDidMount.

Then, of course, we might miss a store update that happened between constructor and componentDidMount.

react-redux solves that by rerunning the selector (i.e., mapStateToProps) in componentDidMount and calling forceUpdate if anything changed. That's the stable v5.1.1.

In master, they have an unreleased beta version where the Redux provider and consumer are rewritten using the new React context API and where the connect-ed consumers don't subscribe to the store at all. Just the Provider does. That could be an inspiration for the @wordpress/data internals, too 🙂

Conclusion: this patch solves the bug that @Tug discovered, but other subtle issues are still present.

[youknowriad]

Subscribing in the constructor is important for another use-case. It's important that the parent's component rerenders before its children do. For example when you remove a block, you don't want its inner components to rerender, you want the block list to rerender first to remove the block before the selectors of a removed block get called.

There's probably a better way to fix it but moving to componentDidMount causes the components to rerender in the wrong order because componentDidMount of children components runs before parents. I wonder how connect solves this.

[Tug]

Found a comment that I believe explains it: reduxjs/react-redux#1079 (comment)
Makes me wonder if we should use a per component listener?

[jsnajdr]

In react-redux, nested connected components don't subscribe directly to the Redux store, but there is a nested hierarchy of Subscription objects and each child component subscribes to the parent's Subscription. Only components that don't have any connected parent subscribe directly to the store. Then the Subscription object makes sure that the listener of its owner is called first, and the listeners of the children are called after it. Something like this:

constructor() {
  this.subscription = new Subscription();
  // `this` is always the first subscriber
  this.subscription.subscribe( this.onStateChange ); 
}

componentDidMount() {
  this.subscription.subscribeToParent();
}

componentDidUnmount() {
  this.subscription.unsubscribeFromParent();
}

The parent subscription object is passed down to children in context. And then each child in turn passes a different parent subscription to its children.

It's very clever and satisfies all the subtle requirements: no leaks, parent listener called before children...

[youknowriad]

I'd be fine with something like this if proposed, seems like a good enhancement.

[jsnajdr]

The latest React Redux 6 beta is even better. It uses React.createContext and only the Provider subscribes to anything. The connected components receive the latest Redux state through the context and rerender if anything relevant changed. Parent component receives the updated context before children do. Everything is much simpler and it just works.

[aduth]

I'm interested in exploring further enhancements, and have a few ideas floating in my head related to what's been discussed here. To clarify, do these concerns impact whether this should be merged as-is?

[jsnajdr]

To clarify, do these concerns impact whether this should be merged as-is?

No. As far as I know, this PR makes things better and doesn't make anything worse 🚢

[aduth]

Gotcha, great. And thanks for the additional context. While I've done my fair share of scouring react-redux source, in how you've laid it out here, there seems to be much we could still do to improve. I'll plan to dig deeper very shortly 🙂