Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not keep bailouted actions which might lead to reducer computing wrong value on update later #15198

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@Andarist
Copy link
Contributor

commented Mar 23, 2019

This is a fix for what I think is a bug which I've reported in #15088

The issue might be observed here https://codesandbox.io/s/n97q1o6nq4 . Just increment the counter -> disable the whole thing -> increment few times (those are going to bail out) -> enable the counter -> observe a counter incrementing by the amount of actions which have bailouted previously.

@Andarist Andarist force-pushed the Andarist:fix/stale-bailouts-reused branch 2 times, most recently from 5ae4b7c to f39995f Mar 23, 2019

@Andarist Andarist force-pushed the Andarist:fix/stale-bailouts-reused branch from f39995f to d2a0516 Mar 23, 2019

@acdlite

This comment has been minimized.

Copy link
Member

commented Mar 23, 2019

This is an interesting bug, but I don't think it's the right fix. I think I have a better one but I'm on my phone right now so I'll follow up later, or on Monday.

@Andarist

This comment has been minimized.

Copy link
Contributor Author

commented Mar 23, 2019

Might not be the best, although the fix is pretty straightforward and doesn't seem like a hacky solution. If you have any thoughts on how this could be improved I'm all ears - I'd love to work on this if possible. Enjoy your weekend!

@acdlite

This comment has been minimized.

Copy link
Member

commented Mar 24, 2019

Test case for you to consider: A parent and a child are both updated in the same batch. The child bails out early, but the parent doesn’t. The parent re-renders and passes a new prop to the child, which closes over the new prop in its reducer. What do you think should happen?

@Andarist

This comment has been minimized.

Copy link
Contributor Author

commented Mar 24, 2019

Didn't consider that! I assume that React's assumption is that scheduled work in a batch should execute top-down, therefore eager bailout lower in the tree should get ignored (or rather - the action should get processed by the reducer in the render phase if a parent has provided new props to a child which enable the child's state update).

I've added a failing test case for this 👍 Do you have any possible solutions in mind? I could try to explore this fully on my own but for sure it would take me way longer as I'm not that familiar with the codebase here. I would appreciate any pointers so I could continue working on a fix.

@Andarist

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2019

@acdlite any tips on how I could implement proper fix for this?

@Andarist

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

@acdlite friendly 🏓 would love to explore fixing this but atm I'm not sure what the appropriate approach to tackle this would be

@gaearon

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

I think @acdlite would probably have already replied or fixed this if he had a strategy in mind. We appreciate the help but I think you might need to try something and look at in more depth to form a proposal if you want to move it forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.