-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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: React StrictMode takes not updated state value from first update on second update of strictmode #21956
Comments
This is neither a bug nor a limitation. This block of code violates some important rules: if (shouldUpdate.current) {
setValue(10);
shouldUpdate.current = false;
}
StrictMode is just doing its job and highlights these issues |
can you please provide a reference to the docs that shows this is a rule violation, and alternative approaches? also, why is this a rule violation? I know what is the order of a component lifecycle and I want to rely on it with a reference to a constant object. why is this wrong? does Detecting unexpected side effects is the reason? if does, does it applies only to concurrent mode in react? |
I want to discuss the example on the docs:
this example talks about inconsistently of event that if you would fire more then once will cause to unexpected results, while in my case the there is no inconsistency because I rely on a constant and consistent lifecycle. My app would work if React.StrictMode would take into account effects from the first update call on the second update call of strictmode. look at the logs examples: it seems like |
Does it mean you cannot do the following?
This is what I currently use, if I want to be notified of element mounts/unmounts. |
Your situation is not related to this issue. @kosciolek |
Slight clarification: It's okay to call a state setter during render. Reading or writing a ref value during render is only safe if you are implementing the lazy initialization pattern. Other types of reading are unsafe as the ref is a mutable source. Other types of writing are unsafe as they are effectively side effects. In the future we may warn about this in DEV mode (see #18545) but we haven't decided yet. |
I'm going to close this issue since this isn't a React bug. |
copy and edited from #21930 (comment)
I will use the next 2 terms
2 very important notes:
on StrictMode:
after a small experiment,2 updates,1 render for each render cycle(means the body of the FC executes twice while effect fire once)
code
see the next code , and lets remember react triggers 2 updates(at least) per render on StrictMode, if the first update will trigger another update(via setState for example) it will come before the second update strictmode schedules:
on the first render
shouldUpdatePosition.current=true
so setSt gets the right position and update call scheduled by React with the right dimensions. the update call would execute and then on StrictMode, the second update would start(and the 3'th update call) and nowshouldUpdatePosition.current=false
the setSt is not executed, and React takes the value from the first update and not from the previous update call. this is unexpected!recap, and logs:
for logs explanation, let's say 0 is the wrong(not updated) value and 10 is the correct value
'pos',10 (set state trigger, another update call is scheduled)
'st',0
'st',10
'st',0 (why? not expected! should be 10)
in order to fix this bug and make the result as expected react should take the value from the most recent update call and not the the first update call of the current cycle in strict mode
this is clearly a bug (or limitation) in StrictMode
code sandbox
see logs, this is not expected
https://codesandbox.io/s/react-strict-mode-bug-bx8is?file=/src/index.js
The text was updated successfully, but these errors were encountered: