Store change not immediately visible to component

[htzhang2]

This code used to work in react-redux v5.0.7:

1. componentDidUpdate dispatch action, then call reducer to update store
2. reducer updates store
3. componentDidUpdate called again with new store value from selector

Step 3 no longer works in react-redux ^6.0.1:
selector not called

in 7.1.0, selector is called but the value not picked up by component props

[timdorr]

Can you provide an example of this on Codesandbox?

[markerikson]

I would definitely expect that there is a difference in behavior between v5 and v6. One of the specific changes we made for v6 was trying to pass the store state through context, thus ensuring that the entire tree always seems the same value during a render pass.

I would generally expect that v5 and v7 behave similarly to each other, though.

[Benjamin-Dobell]

I'm seeing this as well. Specifically I've got an event listener in a Component that calls setState(someState) and dispatch(someAction).

Logging shows that action is dispatched, and the reducer called before the component re-renders, however despite the store being updated by the reducer, mapStateToProps is not called before the component is re-rendered. As such when the render happens my internal component state is out of sync with the components props (coming from mapStateToProps).

However, I must admit, I can't remember whether this was always the case. I'm on react-redux@7.1.0 and was doing some refactoring when I ran into this race condition.

[YoshiYo]

I think I have the same problem when I updated the package to latest. ^7.1.0
I downgrade to 7.0.3.

---

My component had a value={aValue}. And I don't know why, on the onChange, this one dispatched the action, mutated the store and then render my component with new value, but it's was "bugged" liked the component had it's internal state changed before then apply the value from store.

It just happened on one component on my side, and I can't explain why. I didn't see this on my others components. And it was just a basic component. No massive store or something like this.

---

---

GIF on :

"react-native": "https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz",
"react": "16.8.3",
"react-redux": "^7.1.0",
"expo": "^33.0.6",

[timdorr]

Can you share that code via Codesandbox or just the source somehow? It would really help to have code to look at here.

Also, you probably don't want to store every bit of state in your store in general anyways. Things like form values are usually a smell that you're over-reliant on the store. (Sorry for the arm chair critique!)

[slavikdenis]

@timdorr here is a expo snack example. You can see the issue @YoshiYo is describing. After changing react-redux version to 7.0.3 this issue dissapears.

https://snack.expo.io/@denis.slavik/react-redux-7.1.0-rn-error

[slavikdenis]

Related sources:
facebook/react-native#24409
facebook/react-native#23578
https://stackoverflow.com/questions/43298709/textinput-flickering-choppy-behaviour-on-render

[Benjamin-Dobell]

@slavikdenis Not going to lie, the complexity of that example hurt my head so much it motivated me to make a minimal reproduction 😉

Actually, my results are different than yours, 7.0.3 is also broken for me. Need to go back to 6.0.1 to resolve the race condition in my REPL. However, @htzhang2 said that 6.0.1 doesn't work for them. I suspect there are a several different race conditions people are running into, perhaps related, perhaps not.

https://repl.it/@BenjaminDobell/ReactReduxRaceCondition

@timdorr The above repl.it is stock react (DOM) & react-redux. It will throw an error when the redux store (props) comes out of sync with StatefulComponent's state - which happens (but shouldn't) when you click the checkbox.

If you fork the project on repl.it. downgrade to 6.0.1 and re-run you'll see it goes off without a hitch.

However, more than that, I noted that the problem only rears its head when the parent component re-renders as well as a child. To verify this, if you go to App.js, I've marked two lines that, either of which, when commented out resolve the race condition.

Additionally, I've added 4 console logs through-out the code base; #1, #2, #3, #4 that should be logged in order. Thus if you open your browser console output, you'll be able to see that #3 (mapStateToProps) is not being hit before the re-render when using react-redux 7.x.x.

[Benjamin-Dobell]

@timdorr Sorry, just realized I better address this...

Also, you probably don't want to store every bit of state in your store in general anyways. Things like form values are usually a smell that you're over-reliant on the store. (Sorry for the arm chair critique!)

Yep, totally agree, although my example above is doing just that; my real-world app where I first encountered this issue definitely isn't doing that!

My real world app is storing information about async operations in progress (i.e. data fetching in progress) in redux. Various components through-out the app use this information to display spinners, disable buttons etc.

However, some internally stateful components (e.g. forms) which generate these async operations are kicking off an async operation (according to their state) but when they re-render immediately after kicking off the async operation, the component's props (from redux) indicate no such operation is in progress (until the next re-render). So there's this 1 render where things explode as states become out of sync, unless I introduce more stateful logic (which is my temporary work-around).

[timdorr]

Here's a "fix" for that example: https://repl.it/@timdorr/CalmImaginaryBacktick This is because we get the latest store state in the case that the incoming props have updated

This is ultimately caused by our top-down subscription mechanic. We ensure ancestor components are updated before descendants, so that if one of those descendants leaves the tree, they won't try to render that store update (the "zombie child" problem).

The problem is the update to the internal state of the descendant connected component is being batched at the same time as the ancestor connected component. It looks like this:

1. setState enqueues an update and dispatch updates the store.
2. The <Provider> fires its subscription and notifies the top-most connected component(s).
3. The top-most connected components render, including their sub-tree. The existing mapped props (stored in state) for the descendants are still the same, but include the setState update. (This is your mismatch)
4. The top-most connected notify the next level of descendants and they render with the new store state and mapped props. Everything is back in sync now.

It's basically two different state management systems fighting for control. React's built-in system will get its updates immediately and doesn't generally have to worry about ordering (at least not until Concurrent Mode...). But this library has to "bolt on" via whatever APIs are provided and therefore cannot influence that ordering.

I'm not sure there is a good fix for that. Like I mentioned at the top, you can "fix" it by providing updated props to your child components. Those would have to be drilled down if you're deeply nested, so it's not necessarily ideal. Another option would be to call store.getState() directly inside your render function to make sure you're dealing with the latest state.

I think while the example cases are useful to understand things, I don't see the practicality. That is, why are you storing the same bit of information (a box is checked) in two different places? I would argue that's architected incorrectly and the stateful elements around that operation should be unified into one place (Redux or React state).

[Benjamin-Dobell]

I think while the example cases are useful to understand things, I don't see the practicality. That is, why are you storing the same bit of information (a box is checked) in two different places? I would argue that's architected incorrectly and the stateful elements around that operation should be unified into one place (Redux or React state).

Guessing our messages crossed, just in case you missed it, I'm not doing that. Well, I am in the example obviously, but my real webapp is not using the redux store to store any user interface related state. It's exclusively being used to manage app-wide state, in particular track async operations that, once completed, themselves will update the redux store (i.e. the app-wide state).

Various components all through-out the app therefore need to know when a async operation is in progress. Sometimes that's as simple as displaying a spinner rather than stale content, other times it's to disable buttons, other times it's to modify those components to track the async operation, and sometimes it's to ensure that other components don't attempt to kick-off duplicate or conflicting async operations - granted the app logic does actually prevent that, but the UI should always accurately reflect what operations are possible.

[Benjamin-Dobell]

Okay, perhaps I better explain exactly what's happening my real-world app so you don't think I'm crazy. Granted, this is all highly use-case specific, quite boring, and honestly not particularly related to react-redux (beyond the seeming regression in functionality from 6.0.1 -> 7). But here goes...

I'm not storing the same data in two different places. Well, actually I wasn't, but am doing so now as part of my work-around for this issue - but it's certainly not my intention. In the past (react-redux <7) I was able to store my async operations only in the Redux store.

To be specific, the real-world issue I'm hitting is that my component has a "toggle" (of sorts) which among other things controls which child component(s) ought to be displayed. This toggle is indeed UI state, so it is stored as part of the component's state, not in the Redux store (which is pure model). However, when the toggle is "switched" we need to fetch a different set of data, for the newly visible child component(s). So a web request is kicked off, and a redux action is dispatched indicating the web request is in progress - such that in theory the entire app knows new data is on its way.

Because the toggle has changed, React correctly goes to re-render my component. The component correctly sees the new toggle state (internal component state), however props (from the Redux store) indicate there is no web request in progress (stale store data). There's supposedly no web request in progress, thus it shouldn't render a loading interface, but should instead render the child component corresponding with the "toggle state". However, the child component of course fails to render (throws errors) because the data it expects (doesn't matter where it attempts to get it from; passed props or redux store) simply doesn't exist - the child component should never have been displayed whilst the app is in this state.

There are of course workarounds, and I've implemented one already. There's also undoubtedly ways to fundamentally differently architect the app logic to decrease the likelihood of running into this sort issue. I've just chimed in here to report what seems to be a regression.

However, I also understand that we're limited with respect to what APIs React provides, particularly with all the internal rejigging going on post-Fiber. The work you're doing keeping up with all this is by no means under-appreciated, so thank you very much!