-
Notifications
You must be signed in to change notification settings - Fork 51k
Comparing changes
Open a pull request
base repository: react/react
base: 93fc5740
head repository: react/react
compare: fb2177c1
- 7 commits
- 23 files changed
- 5 contributors
Commits on Nov 14, 2025
-
[Compiler] Don't count a setState in the dependency array of the effe…
…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
Configuration menu - View commit details
-
Copy full SHA for de97ef9 - Browse repository at this point
Copy the full SHA de97ef9View commit details -
[Compiler] Avoid capturing global setStates for no-derived-computatio…
…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
Configuration menu - View commit details
-
Copy full SHA for 257b033 - Browse repository at this point
Copy the full SHA 257b033View commit details -
[compiler] Allow ref access in callbacks passed to event handler props (
#35062) ## Summary Fixes #35040. The React compiler incorrectly flags ref access within event handlers as ref access at render time. For example, this code would fail to compile with error "Cannot access refs during render": ```tsx const onSubmit = async (data) => { const file = ref.current?.toFile(); // Incorrectly flagged as error }; <form onSubmit={handleSubmit(onSubmit)}> ``` This is a false positive because any built-in DOM event handler is guaranteed not to run at render time. This PR only supports built-in event handlers because there are no guarantees that user-made event handlers will not run at render time. ## How did you test this change? I created 4 test fixtures which validate this change: * allow-ref-access-in-event-handler-wrapper.tsx - Sync handler test input * allow-ref-access-in-event-handler-wrapper.expect.md - Sync handler expected output * allow-ref-access-in-async-event-handler-wrapper.tsx - Async handler test input * allow-ref-access-in-async-event-handler-wrapper.expect.md - Async handler expected output All linters and test suites also pass.
Configuration menu - View commit details
-
Copy full SHA for 21f2824 - Browse repository at this point
Copy the full SHA 21f2824View commit details -
[compiler] Repro for false positive mutation of a value derived from …
…props (#35139) Repro from the compiler WG (Thanks Cody!) of a case where the compiler incorrectly thinks a value is mutable. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35139). * #35140 * __->__ #35139
Configuration menu - View commit details
-
Copy full SHA for dbf2538 - Browse repository at this point
Copy the full SHA dbf2538View commit details -
[compiler] Fix for inferring props-derived-value as mutable (#35140)
Fix for the repro from the previous PR. A `Capture x -> y` effect should downgrade to `ImmutableCapture` when the source value is maybe-frozen. MaybeFrozen represents the union of a frozen value with a non-frozen value. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35140). * __->__ #35140 * #35139
Configuration menu - View commit details
-
Copy full SHA for 19b769f - Browse repository at this point
Copy the full SHA 19b769fView commit details -
[compiler] fix bad rebase from sapling (#35145)
--- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/35145). * #35144 * __->__ #35145
Configuration menu - View commit details
-
Copy full SHA for 647e133 - Browse repository at this point
Copy the full SHA 647e133View commit details -
[Flight] Fix pending chunks count for streams & async iterables in DEV (
#35143) In DEV, we need to prevent the response from being GC'd while there are still pending chunks for ReadableSteams or pending results for AsyncIterables. Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for fb2177c - Browse repository at this point
Copy the full SHA fb2177cView commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 93fc5740...fb2177c1