question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Can we avoid inconsistencies on non-batched dispatches?

See original GitHub issue

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

Issue Analytics

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

github_iconTop GitHub Comments

3reactions
markeriksoncommented, Sep 5, 2017

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

1reaction
slorbercommented, Apr 30, 2016

@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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Dispatching Errors: Best Practices to Avoid Mistakes
There are some best practices you can take to avoid mistakes and areas that will ensure any mistake will be caught early on....
Read more >
Stale props and zombie children in Redux | Kai Hao
We 're going to do that by re-implementing the core features of Redux ... The parent component would stop rendering that child as...
Read more >
Advanced RPC Programming Techniques
Advanced RPC Programming Techniques. This section addresses areas of occasional interest to developers using the lower level interfaces of the RPC package.
Read more >
Low-Level I/O - Audiokinetic
From there, you can perform native file reads, or you can route the I/O requests to your own I/O ... Avoid deferring file...
Read more >
Available easyTravel problem patterns - Dynatrace Community
Usually you will combine this problem pattern with others, ... of journeys and locations which avoids costly calls to the backend/database.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found