Bug: useReducer runs the queued updates with new props

[a-c-sreedhar-reddy]

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

[vkurchatkin]

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

[a-c-sreedhar-reddy]

I think since prop is a constant, won't reducer be pure?

[markerikson]

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.

[a-c-sreedhar-reddy]

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.

[markerikson]

As I said, per Dan's post, this appears to be intentional, and not a bug.

[gaearon]

Is this the same problem as #15088 (comment)?

[a-c-sreedhar-reddy]

yeah @gaearon. Is it a bug or feature?

[gaearon]

I think it's a bug.

[a-c-sreedhar-reddy]

Why are the updates queued when it is known that no state has been changed?

[gaearon]

Because it is a bug?

[stale]

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!

[a-c-sreedhar-reddy]

bump. Exists in 16.13.1

[sarathps93]

Hi @gaearon Shall I work on this if it is ok to?

[a-c-sreedhar-reddy]

@sarathps93 How can this be fixed can you explain briefly please?

[sarathps93]

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

[Gautam-Arora24]

Seems like no one is working on this one. Can I work on this issue?

[csr632]

I have created a simpler codesandbox to reproduce this bug:
https://codesandbox.io/s/reducer-trigger-unnecessary-lhqnc?file=/src/index.js

The workaround is: don't bail out the reducer (by returning prevState). Instead, return { ...prevState }. So that this action will not be processed again in the next render.

[zxh19890103]

mark.