Bug: In useEffect, why the same state as setState will also be re-rendered? about react

[addy]

Unless I'm missing something, you are getting the first console.log on the initial render of the component. After clicking the button you are mutating the state of a which is a dependency of an effect that, in turn, mutates the state of b. These mutations individually cause re-renders, which is why you see "render 2" logged twice.

[sanbinlbw]

Unless I'm missing something, you are getting the first console.log on the initial render of the component. After clicking the button you are mutating the state of a which is a dependency of an effect that, in turn, mutates the state of b. These mutations individually cause re-renders, which is why you see "render 2" logged twice.

Changing the state of a will trigger the side effect function to execute setB(b), but this will not change the state of b, because the state after the change is the same as the state before the change.So it should not cause re-renders.

[AndreaPallotta]

Unless I'm missing something, you are getting the first console.log on the initial render of the component. After clicking the button you are mutating the state of a which is a dependency of an effect that, in turn, mutates the state of b. These mutations individually cause re-renders, which is why you see "render 2" logged twice.

Changing the state of a will trigger the side effect function to execute setB(b), but this will not change the state of b, because the state after the change is the same as the state before the change.So it should not cause re-renders.

Even if the value of b remains the same after calling setB(b), React still considers it as a state update and triggers a re-render of the component. I might be wrong here, but I believe React internally batches state updates and performs them asynchronously for performance reasons. So even though the value of b doesn't change, React still queues a re-render for the component.

[lb1129]

See https://react.dev/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development

[Douc1998]

Firstly, I think the conclusion you have drawn from debugging is problematic, and I hope you can confirm it again.

Secondly, the setB (b) method does not trigger an update, only setA (a+1) will trigger this update. The reason why "render, a, b" is printed twice is that React hooks re-executes function components when setState is called, hence there are two console.log. However, this does not mean that it has been updated twice. We know that React updates and renders the contents in render (corresponding to the return in function components). If you add a Math.random() content in the return, you will find that in fact, setB (b) does not trigger the second update, only setA (a+1) will trigger the update. But in your example, it is not easy to observe this situation. I have made modifications to your example, and the principle is consistent. Here is the codesandbox link: https://codesandbox.io/s/update-issues-about-react-hooks-8dvqyk?file=/src/App.js

However, later on, I found that in the example in the codesandbox link, clicking the clickB button will only trigger console.log once, and it will not trigger again no matter how many times it is clicked. However, every time I click the clickA button and then click the clickB button, console.log can be triggered again. This also shows that after React is re-rendered due to setA(a + 1), even if a setState is executed with a value that has not changed (i.e. setB(b)) and this will not cause an update, it allows the function component to be re-executed once. Then if it is found that nothing has changed, it will not trigger again. This is my guess, and I have not found a reasonable explanation for it yet, but as long as setB(b) does not trigger extra redundant rendering, there is no problem with performance waste.

Regarding the other question, you found that lane === 1 during debugging because the current mode is Legacy mode, and the priority of all update objects is syncLane, which is binary 0000...0001, corresponding to decimal 1. This update object was generated when the setA(a + 1) method was called by clicking the button.

The above is my personal understanding, I hope it’s helpful to you. If there are any errors, criticisms and corrections are welcome.

[sanbinlbw]

Firstly, I think the conclusion you have drawn from debugging is problematic, and I hope you can confirm it again.

Secondly, the setB (b) method does not trigger an update, only setA (a+1) will trigger this update. The reason why "render, a, b" is printed twice is that React hooks re-executes function components when setState is called, hence there are two console.log. However, this does not mean that it has been updated twice. We know that React updates and renders the contents in render (corresponding to the return in function components). If you add a Math.random() content in the return, you will find that in fact, setB (b) does not trigger the second update, only setA (a+1) will trigger the update. But in your example, it is not easy to observe this situation. I have made modifications to your example, and the principle is consistent. Here is the codesandbox link: https://codesandbox.io/s/update-issues-about-react-hooks-8dvqyk?file=/src/App.js

However, later on, I found that in the example in the codesandbox link, clicking the clickB button will only trigger console.log once, and it will not trigger again no matter how many times it is clicked. However, every time I click the clickA button and then click the clickB button, console.log can be triggered again. This also shows that after React is re-rendered due to setA(a + 1), even if a setState is executed with a value that has not changed (i.e. setB(b)) and this will not cause an update, it allows the function component to be re-executed once. Then if it is found that nothing has changed, it will not trigger again. This is my guess, and I have not found a reasonable explanation for it yet, but as long as setB(b) does not trigger extra redundant rendering, there is no problem with performance waste.

Regarding the other question, you found that lane === 1 during debugging because the current mode is Legacy mode, and the priority of all update objects is syncLane, which is binary 0000...0001, corresponding to decimal 1. This update object was generated when the setA(a + 1) method was called by clicking the button.

The above is my personal understanding, I hope it’s helpful to you. If there are any errors, criticisms and corrections are welcome.

This is very helpful for me, thanks