Bug: Number increases twice with set-Callback

[Shaegi]

When trying to update an Object with a number within, there seems to be a bug where when I first add and then spread I will receive a wrong number.

React version: 17.0.2

Steps To Reproduce

1. create useState with Object with Number inside
2. create set-Callback
3. mutate prevState directly
4. Spread on return

Link to code example: https://codesandbox.io/s/nice-flower-3783g?file=/src/App.js

The current behavior

Click0 will go from 0 -> 1 -> 3 -> 5 -> 7
Click1 will go from 0->1->2->3
Click2 will go from 0->1->2->3

The expected behavior

"Click0", "Click1" and "Click2" should have the same result.

[vkurchatkin]

Well, you shouldn't "mutate prevState directly". That's what causes the problem

[bvaughn]

This code should not be doing what it's doing:

          setCount((prev) => {
            prev.count = prev.count + 1;
            return { ...prev };
          });

State updaters should always return a new state, not mutate the old one:

          setCount((prev) => {
            return {
              count: prev.count + 1
            };
          });

[bvaughn]

I'm going to close this issue since it seems like a question that's now been answered

[Shaegi]

In all 3 cases a new object will be returned, it seems pretty weird that the order of creating the new object matters aspecially because all updaters are only called once. So how does the +2 happen instead of +1, which ist still not explained. Even tho I know its indeed bad practise to update the state value directly it should be an issue to do so IMO and seems to be unintuitive for new users and just straight up wrong because click0 and click1 will both return a new object with count increased by 1.

[bvaughn]

aspecially because all updaters are only called once

This is not true. Strict mode calls updaters twice, like render functions and other render-phase functions in order to help spot side effects.

The mutation side effect in your code is why the value gets over-incremented.

[Shaegi]

Okay, thanks for the explaination. Haven't read concurrent mode up yet, so I didn't know about the second "silent" render.
Even as someone who uses react for the last 3 years this seams quite harsh to understand whats going on.
Still Mystery solved.
I'd still suggest some kind of warning/error beeing thrown in a case like this because it seems like it can be easly overlooked.

[bvaughn]

We are working on both React and DevTools to make this (double render) more discoverable and less confusing. (See #21889 and #21890)