[pull] main from facebook:main #17
Open
+641,645
−224,836
Conversation
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
…pes (#34953) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> Supersedes #34951 ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> Fix the runtime error with named imports and make the last remaining [Are The Types Wrong?](https://arethetypeswrong.github.io/?p=eslint-plugin-react-hooks%400.0.0-experimental-6b344c7c-20251022) error with `eslint-plugin-react-hooks` go away, thanks to the hint from Andrew Branch: - #34801 (comment) ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> I tried adding this to `node_modules` and it fixed the failures when importing named imports like `import { configs, meta, rules } from 'eslint-plugin-react-hooks'`: ```bash ➜ eslint-config-upleveled git:(renovate/react-monorepo) pnpm eslint . --max-warnings 0 Oops! Something went wrong! :( ESLint: 9.37.0 file:///Users/k/p/eslint-config-upleveled/index.js:13 import reactHooks, { configs } from 'eslint-plugin-react-hooks'; ^^^^^^^ SyntaxError: Named export 'configs' not found. The requested module 'eslint-plugin-react-hooks' is a CommonJS module, which may not support all module.exports as named exports. CommonJS modules can always be imported via the default export, for example using: import pkg from 'eslint-plugin-react-hooks'; const { configs } = pkg; at ModuleJob._instantiate (node:internal/modules/esm/module_job:228:21) at async ModuleJob.run (node:internal/modules/esm/module_job:335:5) at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:647:26) at async dynamicImportConfig (/Users/k/p/eslint-config-upleveled/node_modules/.pnpm/eslint@9.37.0/node_modules/eslint/lib/config/config-loader.js:186:17) at async loadConfigFile (/Users/k/p/eslint-config-upleveled/node_modules/.pnpm/eslint@9.37.0/node_modules/eslint/lib/config/config-loader.js:276:9) at async ConfigLoader.calculateConfigArray (/Users/k/p/eslint-config-upleveled/node_modules/.pnpm/eslint@9.37.0/node_modules/eslint/lib/config/config-loader.js:589:23) at async #calculateConfigArray (/Users/k/p/eslint-config-upleveled/node_modules/.pnpm/eslint@9.37.0/node_modules/eslint/lib/config/config-loader.js:743:23) at async directoryFilter (/Users/k/p/eslint-config-upleveled/node_modules/.pnpm/eslint@9.37.0/node_modules/eslint/lib/eslint/eslint-helpers.js:309:5) at async NodeHfs.<anonymous> (file:///Users/k/p/eslint-config-upleveled/node_modules/.pnpm/@HumanFS+core@0.19.1/node_modules/@humanfs/core/src/hfs.js:586:29) at async NodeHfs.walk (file:///Users/k/p/eslint-config-upleveled/node_modules/.pnpm/@HumanFS+core@0.19.1/node_modules/@humanfs/core/src/hfs.js:614:3) ➜ eslint-config-upleveled git:(renovate/react-monorepo) pnpm eslint . --max-warnings 0 ➜ eslint-config-upleveled git:(renovate/react-monorepo) # no error ``` The named imports identifiers `configs`, `meta`, and `rules` also contain values, as a sanity check: - #34951 (comment) cc @poteto
## Summary This PR addresses a pending TODO comment left in #34499 https://github.com/facebook/react/blame/eb2f784e752ba690f032db4c3d87daac77a5a2aa/compiler/apps/playground/components/Editor/ConfigEditor.tsx#L37 This change removes the temporary workaround and replaces it with `<Activity>`, as originally intended. ## How did you test this change? - Updated the component to use `<Activity>` directly - Verified the editor renders correctly in both development and production builds. - The `<Activity>` UI updates as expected. https://github.com/user-attachments/assets/ce976123-da59-4579-b063-b308a9167b21
Add changelog entry for 7.0.1 --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34964). * #34965 * __->__ #34964
This was outdated from previously. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34965). * __->__ #34965 * #34964
…#34580) Summary: Change error and update snapshots The error now mentions what values are causing the issue which should provide better context on how to fix the issue --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34580). * __->__ #34580 * #34579 * #34578 * #34577 * #34575 * #34574
When a longer function or expression is identified as the source of an error, we currently print the entire expression in our error message. This is because we delegate to a Babel helper to print codeframes. Here, we add some checking and abbreviate the result if it spans too many lines.
Some vulnerabilities were detected in older versions of Playwright, upgrading for the playground.
(disclaimer: I used codex to write this script)
Adds a new `yarn generate-changelog` script to simplify the process of
writing changelogs. You can use it as follows:
```
$ yarn generate-changelog --help
Usage: yarn generate-changelog [--codex|--claude] [--debug] [<pkg@version> ...]
Options:
--codex Use Codex for commit summarization. [boolean]
--claude Use Claude for commit summarization. [boolean]
--debug Enable verbose debug logging. [boolean] [default: false]
-h, --help Show help [boolean]
Examples:
generate-changelog --codex Generate changelog for a single
eslint-plugin-react-hooks@7.0.1 package using Codex.
generate-changelog --claude react@19.3 Generate changelog entries for
react-dom@19.3 multiple packages using Claude.
generate-changelog --codex Generate changelog for all stable
packages using recorded versions.
```
For example, if no args are passed, the script will print find all the
relevant commits affecting packages (defaults to `stablePackages` in
`ReactVersions.js`) and format them as a simple markdown list.
```
$ yarn generate-changelog
## eslint-plugin-react-hooks@7.0.0
* [compiler] improve zod v3 backwards compat (#34877) ([#34877](#34877) by [@henryqdineen](https://github.com/henryqdineen))
* [ESLint] Disallow passing effect event down when inlined as a prop (#34820) ([#34820](#34820) by [@jf-eirinha](https://github.com/jf-eirinha))
* Switch to `export =` to fix eslint-plugin-react-hooks types (#34949) ([#34949](#34949) by [@karlhorky](https://github.com/karlhorky))
* [eprh] Type `configs.flat` more strictly (#34950) ([#34950](#34950) by [@poteto](https://github.com/poteto))
* Add hint for Node.js cjs-module-lexer for eslint-plugin-react-hook types (#34951) ([#34951](#34951) by [@karlhorky](https://github.com/karlhorky))
* Add hint for Node.js cjs-module-lexer for eslint-plugin-react-hook types (#34953) ([#34953](#34953) by [@karlhorky](https://github.com/karlhorky))
// etc etc...
```
If `--codex` or `--claude` is passed, the script will attempt to use
them to summarize the commit(s) in the same style as our existing
CHANGELOG.md.
And finally, for debugging the script you can add `--debug` to see
what's going on.
Now that RN is only on the New Architecture, we can stop stop syncing the legacy React Native renderers. In this diff, I just stop syncing them. In a follow up I'll delete the code for them so only Fabric is left. This will also allow us to remove the `enableLegacyMode` feature flag.
Stacked on #34946 This should be a noop, now that the legacy renderers are not being sync'd.
Adds a new `--format` option which can be `text` (default), `csv`, or `json`. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34992). * #34993 * __->__ #34992
Just a light reorganization.
500 tests failed from not using async act. Will fix the tests and then re-land this.
…35003) IO tasks can execute more than once. E.g. a connection may fire each time a new message or chunk comes in or a setInterval every time it executes. We used to treat these all as one I/O node and just updated the end time as we go. Most of the time this was fine because typically you would have a Promise instance whose end time is really the one that gets used as the I/O anyway. However, in a pattern like this it could be problematic: ```js setTimeout(() => { function App() { return Promise.resolve(123); } renderToReadableStream(<App />); }); ``` Because the I/O's end time is before the render started so it should be excluded from being considered I/O as part of the render. It happened outside of render. But because the `Promise.resolve()` is inside render its end time is after the render start so the promise is considered part of the render. This is usually not a problem because the end time of the I/O is still before the start of the render so even though the Promise is valid it has no I/O source so it's properly excluded. However, if the I/O's end time updates before we observe this then the I/O can be considered part of the render. E.g. if this was a setInterval it would be clearly wrong. But it turns out that even setTimeout can sometimes execute more than once in the async_hooks because each run of "process.nextTick" and microtasks respectively are ran in their own before/after. When a micro task executes after this main body it'll update the end time which can then turn the whole I/O as being inside the render. To solve this properly I create a new I/O node each time before() is invoked so that each one gets to observe a different end time. This has a potential CPU and memory allocation cost when there's a lot of them like in a quick stream.
… times along different paths (#35005) We avoid visiting the same async node twice but if we see it again we returned "null" indicating that there's no I/O there. This means that if you have two different Promises both resolving from the same I/O node then we only show one of them. However, in general we treat that as two different I/O entries to allow for things like batching to still show up separately. This fixes that by caching the return value for multiple visits. So if we found I/O (but no user space await) in one path and then we visit that path through a different Promise chain, then we'll still emit it twice. However, if we visit the same exact Promise that we emitted an await on then we skip it. Because there's no need to emit two awaits on the same thing. It only matters when the path ends up informing whether it has I/O or not.
…t order (#35011) Right now it's possible for things like server environments to appear before other content in the timeline just because it's in a different document order. Ofc the order in production is not guaranteed but we can at least use the timing information we have as a hint towards the actual order. Unfortunately since the end time of the RSC stream itself is always after the content that resolved to produce it, it becomes kind of determined by the chunking. Similarly since for a clean refresh, the scripts and styles will typically load after the server content they appear later. Similarly SSR typically finishes after the RSC parts. Therefore a hack here is that I artificially delay everything with a non-null environment (RSC) so that RSC always comes after client-side (Suspense). This is also consistent with how we color things that have an environment even if children are just Suspense. To ensure that we never show a child before a parent, in the timeline, each child has a minimum time of its parent.
…Document (#34641) It's annoying to have to try to find where it lines up with no hints. This way when you hover over something it should be on screen. The strategy I went with is that it scrolls to a percentage along the scrollable axis but the two might not be exactly the same. Partially because they have different aspect ratios but also because suspended boundaries can shrink the document while the suspense tab needs to still be able to show the boundaries that are currently invisible.
When rects are close together (or overlapping) the outline can end up being covered up by sibling rects or deeper rects. This renders the selected outline on top of everything so it's always visible. <img width="275" height="730" alt="Screenshot 2025-10-29 at 8 43 28 PM" src="https://github.com/user-attachments/assets/69224883-f548-45ec-ada1-1a04ec17eaf5" /> <img width="266" height="737" alt="Screenshot 2025-10-29 at 8 58 53 PM" src="https://github.com/user-attachments/assets/946f7dde-450d-49fd-9fbd-57487f67f461" /> Additionally, this makes it so that it's not part of the translucent tree when things are hidden by the timeline. That way it's easier to see what is selected inside a hidden tree. <img width="498" height="196" alt="Screenshot 2025-10-29 at 8 45 24 PM" src="https://github.com/user-attachments/assets/723107ab-a92c-42c2-8a7d-a548ac3332d0" /> <img width="571" height="735" alt="Screenshot 2025-10-29 at 8 59 06 PM" src="https://github.com/user-attachments/assets/d653f1a7-4096-45c3-b92a-ef155d4742e6" />
…penseList (#35018) We have warned about this for a while now so we can make the switch. Often when you reach for SuspenseList, you mean forwards. It doesn't make sense to have the default to just be a noop. While "together" is another useful mode that's more like a Group so isn't so associated with the default as List. So we're switching it. However, tail=hidden isn't as obvious of a default it does allow for a convenient pattern for streaming in list of items by default. This doesn't yet switch the rendering order of "backwards". That's coming in a follow up.
…rder (#35021) Stacked on #35018. This mounts the children of SuspenseList backwards. Meaning the first child is mounted last in the DOM (and effect list). It's like calling reverse() on the children. This is meant to set us up for allowing AsyncIterable children where the unknown number of children streams in at the end (which is the beginning in a backwards SuspenseList). For consistency we do that with other children too. `unstable_legacy-backwards` still exists for the old mode but is meant to be deprecated. <img width="100" alt="image" src="https://github.com/user-attachments/assets/5c2a95d7-34c4-4a4e-b602-3646a834d779" />
In #35019, we excluded debug I/O info from being considered for enhancing the owner stack if it resolved after the defined `endTime` option that can be passed to the Flight client. However, we should include any I/O that was awaited before that end time, even if it resolved later.
This PR adds a `unstable_reactFragments?: Set<FragmentInstance>` property to DOM nodes that belong to a Fragment with a ref (top level host components). This allows you to access a FragmentInstance from a DOM node. This is flagged behind `enableFragmentRefsInstanceHandles`. The primary use case to unblock is reusing IntersectionObserver instances. A fairly common practice is to cache and reuse IntersectionObservers that share the same config, with a map of node->callbacks to run for each entry in the IO callback. Currently this is not possible with Fragment Ref `observeUsing` because the key in the cache would have to be the `FragmentInstance` and you can't find it without a handle from the node. This works now by accessing `entry.target.fragments`. This also opens up possibilities to use `FragmentInstance` operations in other places, such as events. We can do `event.target.unstable_reactFragments`, then access `fragmentInstance.getClientRects` for example. In a future PR, we can assign an event's `currentTarget` as the Fragment Ref for a more direct handle when the event has been dispatched by the Fragment itself. The first commit here implemented a handle only on observed elements. This is awkward because there isn't a good way to document or expose this temporary property. `element.fragments` is closer to what we would expect from a DOM API if a standard was implemented here. And by assigning it to all top-level nodes of a Fragment, it can be used beyond the cached IntersectionObserver callback. One tradeoff here is adding extra work during the creation of FragmentInstances as well as keeping track of adding/removing nodes. Previously we only track the Fiber on creation but here we add a traversal which could apply to a large set of top-level host children. The `element.unstable_reactFragments` Set can also be randomly ordered.
…5039) For Edge Flight servers, that use Web Streams, we're defining the `debugChannel` option as: ``` debugChannel?: {readable?: ReadableStream, writable?: WritableStream, ...} ``` Whereas for Node.js Flight servers, that use Node.js Streams, we're defining it as: ``` debugChannel?: Readable | Writable | Duplex | WebSocket ``` For the Edge Flight clients, there is currently only one direction of the debug channel supported, so we define the option as: ``` debugChannel?: {readable?: ReadableStream, ...} ``` Consequently, for the Node.js Flight clients, we define the option as: ``` debugChannel?: Readable ``` The presence of a readable debug channel is passed to the Flight client internally via the `hasReadable` flag on the internal `debugChannel` option. For the Node.js clients, that flag was accidentally derived from the public option `debugChannel.readable`, which is conceptually incorrect, because `debugChannel` is a `Readable` stream, not an options object with a `readable` property. However, a `Readable` also has a `readable` property, which is a boolean that indicates whether the stream is in a readable state. This meant that the `hasReadable` flag was incidentally still set correctly. Regardless, this was confusing and unintentional, so we're now fixing it to always set `hasReadable` to `true` when a `debugChannel` is provided to the Node.js clients. We'll revisit this in case we ever add support for writable debug channels in Node.js (and Edge) clients.
This is a combination of a) a subagent for investigating compiler errors and b) testing that agent by fixing bugs with for loops within try/catch. My recent diffs to support maybe-throw within value blocks was incomplete and handled many cases, like optionals/logicals/etc within try/catch. However, the handling for for loops was making more assumptions and needed additional fixes. Key changes: * `maybe-throw` terminal `handler` is now nullable. PruneMaybeThrows nulls the handler for blocks that cannot throw, rather than changing to a `goto`. This preserves more information, and makes it easier for BuildReactiveFunction's visitValueBlock() to reconstruct the value blocks * Updates BuildReactiveFunction's handling of `for` init/test/update (and similar for `for..of` and `for..in`) to correctly extract value blocks. The previous logic made assumptions about the shape of the SequenceExpression which were incorrect in some cases within try/catch. The new helper extracts a flattened SequenceExpression. Supporting changes: * The agent itself (tested via this diff) * Updated the script for invoking snap to keep `compiler/` as the working directory, allowing relative paths to work more easily * Add an `--update` (`-u`) flag to `yarn snap minimize`, which updates the fixture in place w the minimized version
#35688) More snap improvements for use with agents: * `yarn snap compile [--debug] <path>` for compiling any file, optionally with debug logs * `yarn snap minimize <path>` now accepts path as a positional param for consistency w 'compile' command * Both compile/minimize commands properly handle paths relative to the compiler/ directory. When using `yarn snap` the current working directory is compiler/packages/snap, but you're generally running it from the compiler directory so this matches expectations of callers better.
* A few new minimization strategies, removing function params and array/object pattern elements * Ensure that we preserve the same set of errors based on not just category+reason but also description.
…#35377) (#35419) ## Summary Fix react-hooks/set-state-in-effect false negatives when Hooks are called via a namespace import (e.g. `import * as React from 'react'` and `React.useEffect(...))`. The validation now checks the MethodCall property (the actual hook function) instead of the receiver object. Issue: Bug: #35377 ## How did you test this change? Added a regression fixture; Ran tests and verified it reports `EffectSetState` and matches the expected output. <img width="461" height="116" alt="Screenshot 2025-12-27 at 14 13 38" src="https://github.com/user-attachments/assets/fff5aab9-0f2c-40e9-a6a5-b864c3fa6fbd" />
Summary:
I noticed there's a bug where the lint will recognize the type on a cast
annotation as a missing dependency;
```
function MyComponent() {
type ColumnKey = 'id' | 'name';
type Item = {id: string, name: string};
const columns = useMemo(
() => [
{
type: 'text',
key: 'id',
} as TextColumn<ColumnKey, Item>,
^^^^^^^^ here
],
[],
);
}
```
This is due to the AST of AsExpressions being something like:
AsExpression
└── typeAnnotation: GenericTypeAnnotation
└── typeParameters: TypeParameterInstantiation
└── params[0]: GenericTypeAnnotation
└── id: Identifier (name: "ColumnKey")
Where `ColumnKey` never has a TypeParameter Annotation. So we need to
consider it to be a flow type due to it belonging to a
GenericTypeAnnotation
Test Plan:
Added unit tests
Before:
```
Test Suites: 1 failed, 2 passed, 3 total
Tests: 2 failed, 5065 passed, 5067 total
Snapshots: 0 total
Time: 16.517 s
Ran all test suites.
error Command failed with exit code 1.
```
After:
```
PASS __tests__/ReactCompilerRuleTypescript-test.ts
PASS __tests__/ESLintRulesOfHooks-test.js (6.192 s)
PASS __tests__/ESLintRuleExhaustiveDeps-test.js (9.97 s)
Test Suites: 3 passed, 3 total
Tests: 5067 passed, 5067 total
Snapshots: 0 total
Time: 10.21 s, estimated 11 s
Ran all test suites.
✨ Done in 12.66s.
```
#35612) Database libraries like Gel/EdgeDB can create very long linear chains of async sequences through temporal async sequencing in connection pools. The recursive traversal of `node.previous` chains in `visitAsyncNode` causes stack overflow on these deep chains. The fix converts the `previous` chain traversal from recursive to iterative. We collect the chain into an array, then process from deepest to shallowest. The `awaited` traversal remains recursive since its depth is bounded by promise dependency depth, not by the number of event loop turns. Each `awaited` branch still benefits from the iterative `previous` handling within its own traversal. I've verified that this fixes the [repro](https://github.com/jere-co/next-debug) provided in #35246. closes #35246
## Overview Adds a feature flag `enableParallelTransitions` to experiment with engantling transitions less often. ## Motivation Currently we over-entangle transition lanes. It's a common misunderstanding that React entangles all transitions, always. We actually will complete transitions independently in many cases. For example, [this codepen](https://codepen.io/GabbeV/pen/pvyKBrM) from [@GabbeV](https://bsky.app/profile/gabbev.bsky.social/post/3m6uq2abihk2x) shows transitions completing independently. However, in many cases we entangle when we don't need to, instead of letting the independent transitons complete independently. We still want to entangle for updates that happen on the same queue. ## Example As an example of what this flag would change, consider two independent counter components: ```js function Counter({ label }) { const [count, setCount] = useState(0); return ( <div> <span>{use(readCache(`${label} ${count}`))} </span> <Button action={() => { setCount((c) => c + 1); }} > Next {label} </Button> </div> ); } ``` ```js export default function App() { return ( <> <Counter label="A" /> <Counter label="B" /> </> ); } ``` ### Before The behavior today is to entange them, meaning they always commit together: https://github.com/user-attachments/assets/adead60e-8a98-4a20-a440-1efdf85b2142 ### After In this experiment, they will complete independently (if they don't depend on each other): https://github.com/user-attachments/assets/181632b5-3c92-4a29-a571-3637f3fab8cd ## Early Research This change is in early research, and is not in the experimental channel. We're going to experiment with this at Meta to understand how much of a breaking change, and how beneficial it is before commiting to shipping it in experimental and beyond.
Small optimization for useEffectEvent. Not sure we even need a flag for it, but it will be a nice killswitch. As an added benefit, it fixes a bug when `enableViewTransition` is on, where we were not updating the useEffectEvent callback when a tree went from hidden to visible.
…35702) There is an existing issue with serialisation logic for the traces from Profiler panel. I've discovered that `TREE_OPERATION_UPDATE_TREE_BASE_DURATION` operation for some reason appears earlier in a sequence of operations, before the `TREE_OPERATION_ADD` that registers the new node. It ends up cloning non-existent node, which just creates an empty object and adds it to the map of nodes. This change only adds additional layer of validation to cloning logic, so we don't swallow the error, if we attempt to clone non-existent node.
Accidentally enabled this
…eam (#35724) ## Summary - Fixes the `createRequest` call in `renderToPipeableStream` to pass `debugChannelReadable !== undefined` instead of `debugChannel !== undefined` in the turbopack, esm, and parcel Node.js server implementations - The webpack version already had the correct check; this brings the other bundler implementations in line The bug was introduced in #33754. With `debugChannel !== undefined`, the server could signal that debug info should be emitted even when only a write-only debug channel is provided (no readable side), potentially causing the client to block forever waiting for debug data that never arrives.
`encodeReply` throws "React Element cannot be passed to Server Functions from the Client without a temporary reference set" when a React element is the root value of a `serializeModel` call (either passed directly or resolved from a promise), even when a temporary reference set is provided. The cause is that `resolveToJSON` hits the `REACT_ELEMENT_TYPE` switch case before reaching the `existingReference`/`modelRoot` check that regular objects benefit from. The synthetic JSON root created by `JSON.stringify` is never tracked in `writtenObjects`, so `parentReference` is `undefined` and the code falls through to the throw. This adds a `modelRoot` check in the `REACT_ELEMENT_TYPE` case, following the same pattern used for promises and plain objects. The added `JSX as root model` test also uncovered a pre-existing crash in the Flight Client: when the JSX element round-trips back, it arrives as a frozen object (client-created elements are frozen in DEV), and `Object.defineProperty` for `_debugInfo` fails because frozen objects are non-configurable. The same crash can occur with JSX exported as a client reference. For now, we're adding `!Object.isFrozen()` guards in `moveDebugInfoFromChunkToInnerValue` and `addAsyncInfo` to prevent the crash, which means debug info is silently dropped for frozen elements. The proper fix would likely be to clone the element so each rendering context gets its own mutable copy with correct debug info. closes #34984 closes #35690
…35731) When using a partial prerender stream, i.e. a prerender that is intentionally aborted before all I/O has resolved, consumers of `createFromReadableStream` would need to keep the stream unclosed to prevent React Flight from erroring on unresolved chunks. However, some browsers (e.g. Chrome, Firefox) keep unclosed ReadableStreams with pending reads as native GC roots, retaining the entire Flight response. With this PR we're adding an `unstable_allowPartialStream` option, that allows consumers to close the stream normally. The Flight Client's `close()` function then transitions pending chunks to halted instead of erroring them. Halted chunks keep Suspense fallbacks showing (i.e. they never resolve), and their `.then()` is a no-op so no new listeners accumulate. Inner stream chunks (ReadableStream/AsyncIterable) are closed gracefully, and `getChunk()` returns halted chunks for new IDs that are accessed after closing the response. Blocked chunks are left alone because they may be waiting on client-side async operations like module loading, or on forward references to chunks that appeared later in the stream, both of which resolve independently of closing.
…35723) Fixes #33423, #35245, #19732. As demoed [here](#33423 (comment)), React DevTools incorrectly highlights re-renders for descendants of filtered-out nodes that didn't actually render. There were multiple fixes suggesting changes in `didFiberRender()` function, but these doesn't seem right, because this function is used in a context of whether the Fiber actually rendered something (updated), not re-rendered compared to the previous Fiber. Instead, this PR adds additional validation at callsites that either used for highlighting re-renders or capturing tree base durations and are relying on `didFiberRender`. I've also added a few tests that reproduce the failure scenario. Without the changes, the tests are failing.
…filing (#35718) After #34089, when updating (possibly, mounting) inside disconnected subtree, we don't record this as an operation. This only happens during reconnect. The issue is that `recordProfilingDurations()` can be called, which diffs tree base duration and reports it to the Frontend: https://github.com/facebook/react/blob/65db1000b944c8a07b5947c06b38eb8364dce4f2/packages/react-devtools-shared/src/backend/fiber/renderer.js#L4506-L4521 This operation can be recorded before the "Add" operation, and it will not be resolved properly on the Frontend side. Before the fix: ``` commit tree › Suspense › should handle transitioning from fallback back to content during profiling Could not clone the node: commit tree does not contain fiber "5". This is a bug in React DevTools. 162 | const existingNode = nodes.get(id); 163 | if (existingNode == null) { > 164 | throw new Error( | ^ 165 | `Could not clone the node: commit tree does not contain fiber "${id}". This is a bug in React DevTools.`, 166 | ); 167 | } at getClonedNode (packages/react-devtools-shared/src/devtools/views/Profiler/CommitTreeBuilder.js:164:13) at updateTree (packages/react-devtools-shared/src/devtools/views/Profiler/CommitTreeBuilder.js:348:24) at getCommitTree (packages/react-devtools-shared/src/devtools/views/Profiler/CommitTreeBuilder.js:112:20) at ProfilingCache.getCommitTree (packages/react-devtools-shared/src/devtools/ProfilingCache.js:40:46) at Object.<anonymous> (packages/react-devtools-shared/src/__tests__/profilingCommitTreeBuilder-test.js:257:44) ```
…tate (#35740) Co-authored-by: Ruslan Lesiutin <28902667+hoxyq@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )