[Compiler] Don't count a setState in the dependency array of the effect it is called on as a usage#35134
Conversation
…ct it is called on as a usage Summary: The validation only allows setState declaration as a usage outside of the effect. Another edge case is that if you add the setState being validated in the dependency array you also make the validation opt out since it counts as a usage outside of the effect. Added a bit of logic to consider the effect's deps when creating the cache for setState usages within the effect Test Plan: Added a fixture
josephsavona
approved these changes
Nov 14, 2025
Comment on lines
+3
to
+7
| function Component({prop}) { | ||
| const [s, setS] = useState(0); | ||
| useEffect(() => { | ||
| setS(prop); | ||
| }, [prop, setS]); |
Member
There was a problem hiding this comment.
nit: maybe pass the setState down in props that way it's reactive and has to be included as a dep?
Contributor
Author
There was a problem hiding this comment.
That would disallow the lint as per the next diff 😅 might have to keep it like this in the short term
jorge-cab
added a commit
that referenced
this pull request
Nov 14, 2025
…ns lint (#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ #35135 * #35134
github-actions bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
…ct it is called on as a usage (#35134) Summary: The validation only allows setState declaration as a usage outside of the effect. Another edge case is that if you add the setState being validated in the dependency array you also make the validation opt out since it counts as a usage outside of the effect. Added a bit of logic to consider the effect's deps when creating the cache for setState usages within the effect Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35134). * #35135 * __->__ #35134 DiffTrain build for [de97ef9](de97ef9)
github-actions bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
…ct it is called on as a usage (#35134) Summary: The validation only allows setState declaration as a usage outside of the effect. Another edge case is that if you add the setState being validated in the dependency array you also make the validation opt out since it counts as a usage outside of the effect. Added a bit of logic to consider the effect's deps when creating the cache for setState usages within the effect Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35134). * #35135 * __->__ #35134 DiffTrain build for [de97ef9](de97ef9)
github-actions bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
…ns lint (#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ #35135 * #35134 DiffTrain build for [257b033](257b033)
github-actions bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
…ns lint (#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ #35135 * #35134 DiffTrain build for [257b033](257b033)
manNomi
pushed a commit
to manNomi/react
that referenced
this pull request
Nov 15, 2025
…ct it is called on as a usage (facebook#35134) Summary: The validation only allows setState declaration as a usage outside of the effect. Another edge case is that if you add the setState being validated in the dependency array you also make the validation opt out since it counts as a usage outside of the effect. Added a bit of logic to consider the effect's deps when creating the cache for setState usages within the effect Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35134). * facebook#35135 * __->__ facebook#35134
manNomi
pushed a commit
to manNomi/react
that referenced
this pull request
Nov 15, 2025
…ns lint (facebook#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ facebook#35135 * facebook#35134
unstubbable
pushed a commit
to vercel/next.js
that referenced
this pull request
Nov 15, 2025
[diff facebook/react@93fc5740...fb2177c1](facebook/react@93fc574...fb2177c) <details> <summary>React upstream changes</summary> - facebook/react#35143 - facebook/react#35145 - facebook/react#35140 - facebook/react#35139 - facebook/react#35062 - facebook/react#35135 - facebook/react#35134 </details>
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Nov 16, 2025
…ns lint (facebook#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ facebook#35135 * facebook#35134 DiffTrain build for [257b033](facebook@257b033)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Nov 16, 2025
…ns lint (facebook#35135) Summary: This only matters when enableTreatSetIdentifiersAsStateSetters=true This pattern is still bad. But Right now the validation can only recommend to move stuff to "calculate in render" A global setState should not be moved to render, not even conditionally and you can't remove state without crossing Component boundaries, which makes this a different kind of fix. So while we are only suggesting "calculate in render" as a fix we should disallow the lint from throwing in this case IMO Test Plan: Added a fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35135). * __->__ facebook#35135 * facebook#35134 DiffTrain build for [257b033](facebook@257b033)
Moroshima
pushed a commit
to Moroshima/next.js
that referenced
this pull request
Nov 20, 2025
…#86155) [diff facebook/react@93fc5740...fb2177c1](facebook/react@93fc574...fb2177c) <details> <summary>React upstream changes</summary> - facebook/react#35143 - facebook/react#35145 - facebook/react#35140 - facebook/react#35139 - facebook/react#35062 - facebook/react#35135 - facebook/react#35134 </details>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
The validation only allows setState declaration as a usage outside of the effect.
Another edge case is that if you add the setState being validated in the dependency array you also make the validation opt out since it counts as a usage outside of the effect.
Added a bit of logic to consider the effect's deps when creating the cache for setState usages within the effect
Test Plan:
Added a fixture
Stack created with Sapling. Best reviewed with ReviewStack.