-
Notifications
You must be signed in to change notification settings - Fork 47.7k
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
Bug: useReducer runs the queued updates with new props #17953
Comments
I’m not 100% sure, but I think that reducer is supposed to be pure, i.e. you can’t use props, otherwise no guarantees are provided |
I think since prop is a constant, won't reducer be pure? |
My understanding is that this is both a result of how the reducer function is being defined and capturing local values, and actually entirely intentional behavior. |
But if the prop is changed then previous actions which are queued but not applied since they were giving the same state are being applied on the new reducer. |
As I said, per Dan's post, this appears to be intentional, and not a bug. |
Is this the same problem as #15088 (comment)? |
yeah @gaearon. Is it a bug or feature? |
I think it's a bug. |
Why are the updates queued when it is known that no state has been changed? |
Because it is a bug? |
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment! |
bump. Exists in 16.13.1 |
Hi @gaearon Shall I work on this if it is ok to? |
@sarathps93 How can this be fixed can you explain briefly please? |
@a-c-sreedhar-reddy I need to start debugging to find out the root cause which I haven't started yet. If no one else is currently working on it, I can give it a shot. If I am able to find a fix for it, I will let you know. |
Seems like no one is working on this one. Can I work on this issue? |
I have created a simpler codesandbox to reproduce this bug: The workaround is: don't bail out the reducer (by returning prevState). Instead, return |
mark. |
React version: 16.8.0
Steps To Reproduce
Link to code example:
https://codesandbox.io/s/usereducer-wfcmq Link to codesandbox.
The current behavior
Initially step is 0. So for every step react does not rerender due to this https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberHooks.js#L1347. But state updates are queued. So when
step
changes all the state updates are done and hence creates a bug by adding the new step prop.https://overreacted.io/a-complete-guide-to-useeffect/#why-usereducer-is-the-cheat-mode-of-hooks
The text was updated successfully, but these errors were encountered: