Calling state setter with same value doesn't reliably work as documented
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 68/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- javascript, react
- Domain
- documentation
Research direction
Start with the linked useState documentation's “functional updates” section and review the statement about identical state values. Update the wording to explain that the component function may be called on the first same-value update, while the subsequent rerender is skipped; the change is done when the documentation no longer implies the function is always a no-op.
Written by the indexing model from the issue text.
Description
Thank you for the very high standard of documentation on the React website.
There's a bit that's slightly misleading, though. The "functional updates" section of the useState documentation says:
If your update function returns the exact same value as the current state, the subsequent rerender will be skipped completely.
However, if you watch calls to the component function doing the state update, it seems like a render occurs the first time you do that, because the component function gets called that first time. (Once it returns a bail-out means child components aren't called to rerender.) Subsequent times the component sets the same state value, even the component function isn't called (because of a separate "fast" bail-out).
That first time looks like a render to a dev who's read the documentation and expected setting the same value to be a no-op. That's confusing enough to have made @amsterdamharu file this closed bug report and to have made me, independently, come to github to write a bug report as well (but fortunately I found that one first).
Perhaps:
If your update function returns the exact same value as the current state, the subsequent rerender will be skipped completely (although the component function may be called, at least the first time).
...or something like that.
Then when developers see our component function get called even though we did setValue((v) => v);, we'll know it isn't a bug or our misunderstanding something; it's just part of the complexity of React (and there's probably a good reason for it).
Thanks.
- Dominant language
- JavaScript
- Stars
- 11.8k
- Forks
- 7.9k
- Avg merge
- 16h 6m
- Merged PRs (30d)
- 7
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from reactjs/react.dev
-
type: documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
bug: unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
type: typos
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
bug: unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
All issues in reactjs/react.dev
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/cloudstack#14222 ·
-
Browser Waiting for: Product Owner
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
getsentry/sentry-javascript#24577 · 1 comment ·
-
curation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
amponce/archive-movie-browser#186 ·
-
light
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
aemdemos/patients-stryker#253 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
clerk/javascript#9852 ·