react-redux: Can we avoid inconsistencies on non-batched dispatches?

Prompted by https://github.com/reactjs/redux/issues/1415, please read the discussion there. We currently subscribe in componentDidMount but it runs from children first. This has a potential of introducing inconsistencies when a child receives some update state earlier than its parent that passes a state-dependent prop to it.

Would subscribing the parents first fix the inconsistencies? Can we do that somehow (e.g. by passing subscribers up via context)?

Alternatively, can/should we wrap dispatch into ReactDOM.unstable_batchedUpdates() by default like Relay does?

cc @epeli @chandlerprall @tappleby @acdlite

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 5
  • Comments: 28 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@qbolec : Yes, React-Redux v5 introduces top-down subscriptions, which resolves the issues described here.

@tappleby

My only idea is having each connected component being responsible for notifying its own children instead of subscribing directly to the store, this would end up with only the root connected component being subscribed to redux.

I agree with that.

It looks to me an antipattern to have Parent > Child, both using connect, and parent passing down props to child. If Child has to receive props from Parent, the parent could pass as props everything the child needs. I don’t really see any advantage of the child receiving state from both props and connect at the same time and it’s probably better to choose one or the other but not both at the same time.

@epeli

But the biggest argument for enabling it by default in my opinion is that it makes dispatch() consistent. Currently by default dispatch() can surprise you because it works differently depending on when you happen to call it. Ex. onClick vs. setTimeout.

Do you mean that dispatches from event handlers are batched automatically? If that’s the case yes it’s probably worth batching automatically on dispatches to have a consistent behavior, even if I still think the issue described here can be avoided in the first place.