Use console.timeStamp instead of performance.measure in Component Performance Track#32736
CLA Signed
React Core Team
@sebmarkbage:This is a new extension that Chrome added to the existing `console.timeStamp` similar to the extensions added to `performance.measure`. This one should be significantly faster because it doesn't have the extra object indirection, it doesn't return a `PerformanceMeasure` entry and doesn't register itself with the global system of entries.
I also use `performance.measure` in DEV for errors since we can attach the error to the `properties` extension which doesn't exist for `console.timeStamp`.
A downside of using this API is that there's no programmatic API for the site itself to collect its own logs from React. Which the previous allowed us to use the standard `performance.getEntries()` for. The recommendation instead will be for the site to patch `console.timeStamp` if it wants to collect measurements from React just like you're recommended to patch `console.error` or `fetch` or whatever to collect other instrumentation metrics.
This extension works in Chrome canary but it doesn't yet work fully in Chrome stable. We might want to wait until it has propagated to Chrome to stable.
Last updated: 1
[Fizz] Add Owner Stacks when render is aborted#32735
CLA Signed
React Core Team
@eps1lon:
## Summary
`captureOwnerStack` now returns the corresponding owner stack to the parent stack when we abort a Fizz render.
## How did you test this change?
- added test (initial commit has current behavior)
Last updated: 1
Rename <ViewTransition className="..."> to <ViewTransition default="...">#32734
CLA Signed
React Core Team
@sebmarkbage:It was always confusing that this is not a CSS class but a view-transition-class.
The `className` sticks out a bit among its siblings `enter`, `exit`, `update` and `share`. The idea is that the most specific definition override is the class name that gets applied and this prop is really just the fallback, catch-all or "any" that is applied if you didn't specify a more specific one.
It has also since evolved not just to take a string but also a map of Transition Type to strings.
The "class" is really the type of the value. We could add a suffix to all of them like `defaultClass`, `enterClass`, `exitClass`, `updateClass` and `shareClass`. However, this doesn't necessarily make sense with the mapping of Transition Type to string. It also makes it a bit too DOM centric. In React Native this might still be called a "class" but it might be represented by an object definition. We might even allow some kind of inline style form for the DOM too. Really this is about picking which "animation" that runs which can be a string or instance. "Animation" is too broad because there's also a concept of a CSS Animation and these are really sets of CSS animations (group, image-pair, old, new). It could maybe be `defaultTransition`, `enterTransition`, etc but that seems unnecessarily repetitive and still doesn't say anything about it being a class.
We also already have the name "default" in the map of Transition Types. In fact you can now specify a default for default:
```
<ViewTransition default={{"navigation-back": "slide-out", "default": "fade-in"}}>
```
One thing I don't like about the name `"default"` is that it might be common to just apply a named class that does it matching to enter/exit/update in the CSS selectors (such as the `:only-child` rule) instead of doing that mapping to each one using React. In that can you end up specifying only `default={...}` a lot and then what is it the "default" for? It's more like "all". I think it's likely that you end up with either "default" or the specific forms instead of both at once.
Last updated: 1
Fix ownerStackLimit feature gating for tests#32726
CLA Signed
@rickhanlonii:https://github.com/facebook/react/pull/32529 added a dynamic flag for this, but that breaks tests since the flags are not defined everywhere.
However, this is a static value and the flag is only for supporting existing tests. So we can override it in the test config, and make it static at built time instead.
Last updated: 1
Add compareDocumentPosition to fragment instances#32722
CLA Signed
@jackpope:This adds `compareDocumentPosition(otherNode)` to fragment instances.
The semantics implemented are meant to match typical element positioning, with some fragment specifics. See the unit tests for all expectations.
- An element preceding a fragment is `Node.DOCUMENT_POSITION_PRECEDING`
- An element after a fragment is `Node.DOCUMENT_POSITION_FOLLOWING`
- An element containing the fragment is `Node.DOCUMENT_POSITION_PRECEDING` and `Node.DOCUMENT_POSITION_CONTAINING`
- An element within the fragment is `Node.DOCUMENT_POSITION_CONTAINED_BY`
- An element compared against an empty fragment will result in `Node.DOCUMENT_POSITION_DISCONNECTED` and `Node.DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC`
Since we assume a fragment instances target children are DOM siblings and we want to compare the full fragment as a pseudo container, we can compare against the first target child outside of handling the special cases (empty fragments and contained elements).
Last updated: 1
[React 19] React Server Components: `flushScheduled` Initialization in `startWork` Can Be Improved#32721
React 19
@KairuiLiu:## Issue Description
Currently in the React Server Components implementation, the `startWork` function initializes the `flushScheduled` flag based on whether a destination exists:
```javascript
export function startWork(request: Request): void {
request.flushScheduled = request.destination !== null;
// ...
}
```
I've analyzed the behavior of this flag across three different scenarios:
1. When `startFlowing` is called **before** `startWork` (setting `destination` before beginning rendering) - **Effective**: Prevents duplicate flush scheduling for the initial render completion.
2. When `startFlowing` is called **after** the initial render completes - **No difference**: Whether this flag is set or not has no impact on behavior.
3. When `startFlowing` is called **during** the initial render process - **Ineffective**: The flag cannot correctly control flush behavior in this scenario.
This suggests there's room for improvement in how flush timing is controlled in the current implementation.
## Problem
This approach is not robust enough if we want to ensure that no flushing occurs until the initial render is fully complete. The current design relies on indirect state and the timing of API calls, making it brittle and hard to reason about.
The code could be more explicit about its intent to batch initial render output, especially since `flushScheduled` is primarily used to prevent duplicate flush scheduling rather than controlling flush timing.
## Proposed Solution
I propose implementing a more explicit approach to control flushing behavior:
```javascript
// Add to Request type
type Request = {
// ...
flushMode: 'immediate' | 'afterInitialRender',
};
// In startWork
export function startWork(request: Request): void {
request.initialRenderInProgress = true;
// ...
}
// After all initial tasks complete in performWork
if (request.pingedTasks.length === 0) {
request.initialRenderInProgress = false;
if (request.destination !== null && request.completedRegularChunks.length > 0) {
flushCompletedChunks(request, request.destination);
}
}
// Modify enqueueFlush and related functions
function enqueueFlush(request) {
if (
!request.initialRenderInProgress &&
!request.flushScheduled &&
request.pingedTasks.length === 0 &&
request.destination !== null
) {
// Schedule flush...
}
}
```
This makes the intent clearer and provides more predictable behavior regardless of when `startFlowing` is called.
## Benefits
1. More explicit control over flushing behavior
2. Clearer intent in the code
3. More predictable behavior across different usage patterns
Thank you for considering this improvement
Last updated:
Bug: `renderToStaticMarkup` throws error on client components#32715
Status: Unconfirmed
@jonathanhefner:React version: 19.0.0
## Steps To Reproduce
1. Create a client component with the `'use client'` directive.
2. Create a server (universal) component that uses the client component.
3. Call `renderToStaticMarkup` with the server component.
Link to code example: https://codesandbox.io/p/devbox/keen-williamson-wg9p8w (using Next.js to demonstrate `'use client'`)
## The current behavior
`renderToStaticMarkup` throws an `Error` when it encounters a client component:
> Error: Attempted to call MyClientComponent() from the server but MyClientComponent is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.
## The expected behavior
When `renderToStaticMarkup` encounters a client component, it renders non-interactive HTML for the component, just as pre-rendering would during SSR.
Last updated:
Bug: Maximum update depth exceeded#32714
Status: Unconfirmed
@d07RiV:React erroneously complains about setState calls when the application is doing enough work to keep the browser busy between updates.
React version: 18 & 19
## Steps To Reproduce
1. Create a new project in Vite or any other build tool
2. Start dev server with following code
```ts
import { useEffect, useState } from 'react'
import './App.css'
function Display({ value }: { value: number }) {
const [state, setState] = useState(0)
useEffect(() => {
// Adjust the loop length based on your system
for (let i = 0; i < 100000000; ++i) { /* do nothing */ }
setState(value)
}, [value])
return <div>Value: {state}</div>
}
function App() {
const [count, setCount] = useState(0)
useEffect(() => {
function frame() {
setCount(c => c + 1)
frameId = window.requestAnimationFrame(frame)
}
let frameId = window.requestAnimationFrame(frame)
return () => {
window.cancelAnimationFrame(frameId)
}
}, [])
return (
<Display value={count} />
)
}
export default App
```
## The current behavior
After a few seconds starts repeatedly printing this in console:
`Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.`
## The expected behavior
There is no invalid useState calls as far as I'm aware?
Last updated: 1
[DevTools Bug]: Apple CloudKit JS sign in button doesn't work when extension is enabled#32713
Type: Bug
Status: Unconfirmed
Component: Developer Tools
@infinitepower18:### Website or app
https://web.submanager.app
### Repro steps
1. Have the extension installed and enabled on your browser
2. Go to https://web.submanager.app
3. Click Sign in with Apple ID
The sign in button disappears and reappears when you click it which should not happen. This also breaks authentication which means after logging in nothing happens. The sign in button is supposed to stay dimmed when you click it, which it does when the extension is turned off.
https://github.com/user-attachments/assets/58334d7c-2d1a-4cbf-a480-a2500ff88a23
This issue is also reproducible on Apple's own [CloudKit Catalog site](https://cdn.apple-cloudkit.com/cloudkit-catalog/#authentication), click run code at the top then scroll down to the bottom and try the sign in button.
### How often does this bug happen?
Every time
### DevTools package (automated)
_No response_
### DevTools version (automated)
_No response_
### Error message (automated)
_No response_
### Error call stack (automated)
```text
```
### Error component stack (automated)
```text
```
### GitHub query string (automated)
```text
```
Last updated:
[refresh] Fix default export signatures for memo/forwardRef/hoc#32705
CLA Signed
React Core Team
@rickhanlonii:## Overview
Not actually sure this is the right fix.
Fixes a bug in react-refresh that does not detect changes between default exports for memo/forwardRef/Hoc.
## Explanation of bug
Consider changing a file between these three exports:
```js
export default Child;
// edit 1
export default memo(Child);
// edit 2
export default forwardRef(Child);
// edit 3
export default hoc(Child);
```
The babel plugin will insert `$RefreshReg$` as:
```js
$RefreshReg$(Child, "Child");
// edit 1
$RefreshReg$(Child, "Child");
$RefreshReg$(memo(Child), "%default%"); // <- same id
// edit 2
$RefreshReg$(Child, "Child");
$RefreshReg$(forwardRef(Child), "%default%"); // <- same id
// edit 3
$RefreshReg$(Child, "Child");
$RefreshReg$(hoc(Child), "%default%"); // <- same id
```
However, these need to be registered with different IDs or they will be treated like an update:
https://github.com/facebook/react/blob/86d5ac0882305c5bbff0fd7b40385e7d50d0d2b4/packages/react-refresh/src/ReactFreshRuntime.js#L319-L325
## Fix
Fixes to add the `$React.memo|forwardRef|hoc` suffix like we do when you do `memo(forwardRef))`:
https://github.com/facebook/react/blob/bc1a49d8b54990fde0d4f612c8d2ba1249afcfad/packages/react-refresh/src/__tests__/__snapshots__/ReactFreshBabelPlugin-test.js.snap#L404-L405
```js
$RefreshReg$(Child, "Child");
// edit 1
$RefreshReg$(Child, "Child");
$RefreshReg$(memo(Child), "%default%$React.memo"); // <- different id
// edit 2
$RefreshReg$(Child, "Child");
$RefreshReg$(forwardRef(Child), "%default%$React.forwardRef"); // <- different id
// edit 3
$RefreshReg$(Child, "Child");
$RefreshReg$(hoc(Child), "%default%hoc"); // <- different id
```
Last updated: 1
[DevTools] Use Popover API for component inspect overlays#32703
CLA Signed
@yongsk0066:Following the Popover API integration in https://github.com/facebook/react/pull/32614, this PR adds the same capability to Component Inspector highlighting in React DevTools.
## Summary
When selecting a component in the Components tab, the highlighting overlays currently appear behind elements that use the browser's top-layer (such as <dialog> elements or components using the Popover API). This makes it difficult to see component structure and dimensions when they are inside or behind top-layer elements.
This change modifies the Overlay.js module to use the Popover API, ensuring that component highlighting always appears above all other content, including elements in the browser's top-layer. The implementation centrally manages popover controls and follows the same pattern as the recently merged [TraceUpdates PR](https://github.com/facebook/react/pull/32614) for consistency.
## How did you test this change?
I tested this change in the following ways:
1. Manual testing with a test application that includes:
- Components inside <dialog> elements
- Components inside elements using the Popover API
- Selection of complex nested component hierarchies
2. Verification steps:
- Selected components in the Components tab with DevTools
- Confirmed highlighting appears correctly on top of dialog and popover elements
- Verified all highlighting elements (margins, borders, padding, content) display correctly
- Ensured the tooltip with component name and dimensions appears properly
- Checked that existing functionality and visual styling remains consistent
All functionality works as expected, with component highlighting now correctly appearing on top of all content, including top-layer elements.
[demo-page](https://devtools-toplayer-demo.vercel.app/)
[demo-repo](https://github.com/yongsk0066/devtools-toplayer-demo)
### AS-IS
https://github.com/user-attachments/assets/7c025ccb-3c5e-4f9e-89a3-150a7d4811b3
### TO-BE
https://github.com/user-attachments/assets/da081e59-05ce-4935-880e-93d05f8528ad
Last updated: 1
[Flight Reply] Don't create temporary references for objects whose parts were consumed during serialization#32702
CLA Signed
@lubieowoce:This PR fixes a bug with passing "consumable" values from the client to the server and back. Consumable values include Iterators, AsyncIterators, and ReadableStreams -- "one-shot" values that we can only iterate over once.
The problem occurs if we attempt to roundtrip an object like `{ wrapper: iterator }`.
When decoding the reply, we'd currently create a temporary reference for the object, and since in the server is passing it back unchanged, we'd just return a temporary reference instead of serializing again.
However, the iterator was already consumed when the client was encoding the reply, so the final response would contain a non-usable, exhausted iterator. Same goes for AsyncIterators and ReadableStreams (which would throw when read instead of silently being done).
This PR fixes that by making `reviveModel` check if an object contains parts that were already consumed during serialization. If it does, we skip the creation of a temporary reference for the object itself. This propagates outwards: `{ outer: { inner: iterator }}` should also not be returned as a temporary reference for the same reasons.
Then, when serializing the response, we won't have a temporary reference for the object(s), so we'll re-serialize them and the deserialized iterator, and thus give the client a usable value.
Note that roundtripping a plain iterator (without any wrapper objects around it) is not affected by this bug, because we don't currently create temporary references for values with special decoding logic (i.e. ones returned by `parseModelString`), only for plain objects / arrays, so the value would already always be re-serialized. I added tests for this as well just to make sure.
Last updated: 3
Feature Request: Official React VSCode Extension with Practical Enhancements#32694
React 19
@sir-siren:I just want to say how much I love working with React. You all do an incredible job, and it’s awesome to see how it keeps getting better. I’ve been thinking about how we could level up the development experience, especially for those of us who live in VSCode all day. An official React VSCode extension sounds like a dream, so I wanted to share some practical feature ideas that I think would make a big difference. These come from real struggles I’ve faced and chats I’ve had with other developers.
I’d be super excited if you’d take a look at these suggestions:
### Suggested Features
- **Enhanced IntelliSense for React**
- Smart auto-completion for component names, props, and hooks based on what’s in the project.
- Cuts down on typos and makes coding faster.
- **Integrated Debugging Tools**
- Let us set breakpoints right in JSX.
- Check component state and props without leaving VSCode.
- See re-renders in action to spot issues quickly.
- **Linting and Formatting for React**
- Ready-to-go ESLint rules tailored for React.
- Works with Prettier to keep code looking sharp and consistent.
- **Improved JSX Support**
- Better syntax highlighting that pops.
- Catches JSX mistakes as you type and offers quick fixes.
- **Component Visualization**
- Shows a visual map of the component tree.
- Makes it easy to see how everything connects and where props go.
- **Testing Integration**
- Run and debug tests like Jest or React Testing Library right in VSCode.
- Keeps the testing flow smooth without jumping between tools.
- **Code Snippets and Templates**
- Fast shortcuts to create boilerplate for components or hooks.
- Keeps things uniform across the codebase.
- **Performance Optimization Tools**
- Highlights how long components take to render.
- Gives tips like memoization to speed things up.
- **Integration with React Ecosystem Tools**
- Built-in support for stuff like Create React App or Storybook.
- Simplifies starting and managing projects.
Last updated: 2
test:- Added a test for Form reset & case of prevent default.#32689
CLA Signed
@Biki-das:## Summary
Added a test for form reset action & when `e.preventDefault` is done , the form inputs should not be reset to their default values. this test asserts the form reset behaviour. Just good to have i think along with the other tests.
## How did you test this change?
ran ` yarn test packages/react-dom/src/__tests__/ReactDOMEventListener-test.js`
<img width="700" alt="Screenshot 2025-03-21 at 12 39 26 AM" src="https://github.com/user-attachments/assets/664de5e9-a49f-40e6-a63a-e99dd0e73b8d" />
Tests are passing.
Last updated: 2
Cleanup enableObjectFiber experiment#32676
CLA Signed
React Core Team
@kassens:
We observed no signficant change in performance from this, so we can clean this up.
Keeping the class variant as that might give better values in memory profilers.
Last updated: 1
feat: Add isValidNode function to validate React nodes#32667
CLA Signed
@hichemfantar:## Summary
This PR adds a comprehensive `isValidReactNode` utility function that correctly validates all possible types of React nodes according to the React documentation. The implementation accounts for primitive values such as strings, numbers, booleans, null, and undefined - all of which are valid React nodes.
Based on https://react.dev/reference/react/isValidElement#react-elements-vs-react-nodes
initially tested in Nextra https://github.com/shuding/nextra/pull/4366/files#diff-3c9997fb445c0f1b6cb3a813ca5743ad7785c6a36220c373b681f310c8817f47
This new utility function properly validates:
- React elements (using `isValidElement`)
- `null` and `undefined` values
- String values
- Number values
- Boolean values (`true` and `false`)
- Arrays of React nodes (recursively checking each item)
This addresses potential issues where devs create custom checkers for React nodes which might be incorrect, improving the developer experience and preventing false error conditions.
## How did you test this change?
I verified this implementation with the following tests:
```typescript
import { isValidReactNode } from './isValidReactNode';
import { createElement, Fragment } from 'react';
describe('isValidReactNode', () => {
it('accepts React elements', () => {
const element = createElement('div', null, 'Hello');
expect(isValidReactNode(element)).toBe(true);
});
it('accepts JSX elements', () => {
const jsx = <div>Hello</div>;
expect(isValidReactNode(jsx)).toBe(true);
});
it('accepts fragments', () => {
const fragment = <Fragment>Hello</Fragment>;
expect(isValidReactNode(fragment)).toBe(true);
});
it('accepts strings', () => {
expect(isValidReactNode('Hello')).toBe(true);
});
it('accepts numbers', () => {
expect(isValidReactNode(42)).toBe(true);
});
it('accepts booleans', () => {
expect(isValidReactNode(true)).toBe(true);
expect(isValidReactNode(false)).toBe(true);
});
it('accepts null and undefined', () => {
expect(isValidReactNode(null)).toBe(true);
expect(isValidReactNode(undefined)).toBe(true);
});
it('accepts arrays of valid React nodes', () => {
const arr = ['Hello', <div>World</div>, 42, null, true];
expect(isValidReactNode(arr)).toBe(true);
});
it('rejects arrays containing invalid React nodes', () => {
const arr = ['Hello', <div>World</div>, {}];
expect(isValidReactNode(arr)).toBe(false);
});
it('rejects objects that are not React elements', () => {
expect(isValidReactNode({})).toBe(false);
expect(isValidReactNode({ type: 'div' })).toBe(false);
});
it('rejects functions', () => {
expect(isValidReactNode(() => {})).toBe(false);
});
});
```
All tests pass. I also manually verified the function behavior in a React application by testing it with various types of content that should be renderable.
Last updated:
[eprh] Try to fix tests#32662
CLA Signed
React Core Team
@poteto:
Summary:
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32662).
* __->__ #32662
* #32661
* #32615
Last updated: 1
[eprh] Remove __EXPERIMENTAL__#32661
CLA Signed
React Core Team
@poteto:
`__EXPERIMENTAL__` flag doesn't have any use outside of the React repo. Let's remove these flags for now.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32661).
* #32662
* __->__ #32661
* #32615
Last updated: 2
[DevTools Bug]: cannot double click anymore on component name to filter the tree view (in Components tab) (since v6.1.1)#32659
Type: Bug
Status: Unconfirmed
Component: Developer Tools
@clementcitiz:### Website or app
None
### Repro steps
```
const A = () => {
return <div>A</div>;
};
const B = () => {
return (
<>
<div>B</div>
<C/>
<D/>
</>
);
};
const C = () => {
return <div>C</div>;
};
const D = () => {
return <div>D</div>;
};
function App() {
return (
<>
<A />
<B />
</>
);
}
export default App;
```
1. Open dev tools, Component tab
2. Double click on B: nothing happens
With version 6.0.1, double clicking on B filters the tree by showing only B and its direct children
Tested on Chrome and Firefox with version 6.1.1
### How often does this bug happen?
Every time
### DevTools package (automated)
_No response_
### DevTools version (automated)
_No response_
### Error message (automated)
_No response_
### Error call stack (automated)
```text
```
### Error component stack (automated)
```text
```
### GitHub query string (automated)
```text
```
Last updated: 1
Bug: help#32658
Status: Unconfirmed
@decadezzz:<!--
Please provide a clear and concise description of what the bug is. Include
screenshots if needed. Please test using the latest version of the relevant
React packages to make sure your issue has not already been fixed.
-->
React version: 18.2.0
## Steps To Reproduce
If I dipatch a AsyncThunk in useEffect ,can I use the latest state in the useEffect function immediately ?
Link to code example:
const user = useAppSelector((store) => store.user,shallowEqual);
useEffect(() => {
（）=>{
dispatch(load()).then(() => {
console.log(user);}
}, []);
Last updated: 1
Add fb local build command and checkbox to toggle fb internal features#32644
CLA Signed
@aohua:<!--
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
-->
## Summary
1. Having a development build for FB will be convenient for fb internal feature development
2. Add a new checkbox to toggle new internal features added to React Devtools.
## How did you test this change?
1. yarn test
2. set extra env variables in bash profile and build an internal version with the new script.
3. toggle on/off the new checkbox, the value is stored in local storage correctly.
Last updated:
perf(react-reconciler): simplify loop with sentinel node pattern#32643
CLA Signed
@0bipinnata0:I've implemented the optimization mentioned in the comment "TODO: Move out of the loop. This only happens for the first run."
The key improvement was simplifying the code by introducing a sentinel node pattern. This eliminates the need for conditional checks within the loop, making the code more efficient and readable.
Specifically:
1. Added a sentinel node at the beginning of the process
2. Removed the if/else branch that was only needed for the first iteration
3. Improved overall code clarity and performance by reducing conditional logic
This change maintains the same functionality while making the code more maintainable and slightly more performant by avoiding unnecessary condition checking in each loop iteration.
Last updated: 1
[eslint-plugin-react-compiler] fix recommended config usage with defineConfig#32622
CLA Signed
@kosmotema:<!--
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
-->
## Summary
Recently ESLint released [`defineConfig`](https://eslint.org/blog/2025/03/flat-config-extends-define-config-global-ignores/#introducing-defineconfig()-for-eslint) utility to work with flat configs. Now when using recommended config from `eslint-plugin-react-compiler`, a typing error appears because the severity for the `react-compiler/react-compiler` rule in the .d.ts file is of type `string` rather than the more specific `"error"`. [Here](https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgEwKYDNgDtUGEJaYDmcAvnOlBCHAOSoDOANtjAPQDGBxtA3AFChIsOACo4AQwZwoqCRxj5wwJqigUqNes1YBaMEwCuRbLtnyYurstVQ+-fmkw58hYEQAU5hUrAq1AHRcbkQMAbLWIKhYaMgAlLxAA) is a simple reproduction.
## How did you test this change?
Just recreated the recommended config in [TypeScript playground](https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBDAnmApnA3nAMsAdjFKOAXzgDMoIQ4ByFAZwBs8YaBuAKFElgzgBMUZPCgDCEXMIDmJcpWp0mLAPQBjCdPZdw0eACo4AQ3pwoKQ6pjjwwRoTlVaDZvgC0YRgFcpeV2Yswruo2dlBaHILCuGIawFIAFOgccClwHt549ABcGMmpKTT+lkFUYLaENDlJ+flQnnbZuTU1hebFwWWhlaZtVqXlUAB0dQ0A2q0BJSEVALoANHnNxAtLK6nLi6b1DFWbBUWBHQPKB1OdFTl0UJRhaymk9IYwwPTCDNgshIMAStv03yh1FB+GtiABKNhAA) with the suggested changes
Last updated: 2
[Compiler Bug]: return without value causes bailout#32620
Type: Bug
Status: Unconfirmed
Component: Optimizing Compiler
@aeharding:### What kind of issue is this?
- [x] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)
### Link to repro
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAsgJ4DCEAtgA6EKY4AUAlEcADrFFyFg5eACwRwA1kQC8RKGAQBBWrQDKCADaicEGM2YCAhjgTtJAPiIBCCwaOsA3N25EieNEWYW4I8exgIcsJgOmE5EfgEwxADkQnhRwQC+3CAJQA
### Repro steps
I noticed that `return` without a value (e.g. `return` vs `return undefined`) causes compiler to bailout. Please see the below examples:
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAsgJ4DCEAtgA6EKY4AUAlEcADrFFyFg5eACwRwA1kQC8RKGAQBBWrQDKCADaicEGM2YCAhjgTtJAPiIBCCwaOsA3N25EieNEWYW4I8exgIcsJgOmE5EfgEwxADkQnhRwQC+3CAJQA
vs
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAsgJ4DCEAtgA6EKY4AUAlEcADrFFyFg5eACwRwA1kQC8RKGAQBBWrQDKCADaicEGM2YCAhjgTtJAPiIBCCwaOsA3N25EieNEWYW4I8exgIcsMRYACYIaHiYCMEOmE5EfgEwxADkQnjJMQC+3CCZQA
prior discussion: https://github.com/reactwg/react-compiler/discussions/61
### How often does this bug happen?
Every time
### What version of React are you using?
0.0.0-experimental-6aa8254b-20250312
### What version of React Compiler are you using?
0.0.0-experimental-ecdd742-20250312
Last updated: 2
[eprh] Move to compiler directory#32615
CLA Signed
React Core Team
@poteto:
Moves the plugin into the compiler directory.
- Remove eslint-plugin-react-hooks from bundles.js
- Remove eslint-plugin-react-hooks from ReactVersions.js
- Remove jest.config.js
- Remove babel.config-react-compiler.js
- Replace babel.config.js with copy from eslint-plugin-react-compiler
- Add tsup.config.ts to eslint-plugin-react-hooks
- Add eslint-plugin-react-hooks to compiler release scripts
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32615).
* #32662
* #32661
* __->__ #32615
Last updated: 1
[DevTools] Use Popover API for TraceUpdates highlighting#32614
CLA Signed
@yongsk0066:## Summary
When using React DevTools to highlight component updates, the highlights would sometimes appear behind elements that use the browser's [top-layer](https://developer.mozilla.org/en-US/docs/Glossary/Top_layer) (such as `<dialog>` elements or components using the Popover API). This made it difficult to see which components were updating when they were inside or behind top-layer elements.
This PR fixes the issue by using the Popover API to ensure that highlighting appears on top of all content, including elements in the top-layer. The implementation maintains backward compatibility with browsers that don't support the Popover API.
## How did you test this change?
I tested this change in the following ways:
1. Manually tested in Chrome (which supports the Popover API) with:
- Created a test application with React components inside `<dialog>` elements and custom elements using the Popover API
- Verified that component highlighting appears above these elements when they update
- Confirmed that highlighting displays correctly for nested components within top-layer elements
2. Verified backward compatibility:
- Tested in browsers without Popover API support to ensure fallback behavior works correctly
- Confirmed that no errors occur and highlighting still functions as before
3. Ran the React DevTools test suite:
- All tests pass successfully
- No regressions were introduced
[demo-page](https://devtools-toplayer-demo.vercel.app/)
[demo-repo](https://github.com/yongsk0066/devtools-toplayer-demo)
### AS-IS
https://github.com/user-attachments/assets/dc2e1281-969f-4f61-82c3-480153916969
### TO-BE
https://github.com/user-attachments/assets/dd52ce35-816c-42f0-819b-0d5d0a8a21e5
Last updated: 4
[Compiler Bug]: `enableFunctionOutlining` breaks `react-native-reanimated` API callbacks#32580
Type: Bug
Status: Unconfirmed
Component: Optimizing Compiler
@tjzel:### What kind of issue is this?
- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [x] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)
### Link to repro
https://playground.react.dev/#N4Igzg9grgTgxgUxALhHCA7MAXABAFQRwGEIBbAB0wQzwF5cAKYXDKMgIwRlwF8BKXHQB8uYAB0MuXOix4A1ggCe+CAEkMAEwQAPIbihgEAEW4BLAG4JNANQCGAGygJGjQSMnTpAbQCMAGlwAJkCAZgBdADoyOwpXd1E2Bwd+T1x+AG5JNJgEbFgpJIcsjF4SkF4gA
### Repro steps
Current version the Compiler started to transform `react-native-reanimated` API callbacks too much, breaking the code. I compared it with an older version `babel-plugin-react-compiler@19.0.0-beta-9ee70a1-20241017` and the problem didn't happen there. It seems to be due to the `enableFunctionOutlining` feature.
Given the code:
```jsx
const TestComponent = ({ number }) => {
const keyToIndex = useDerivedValue(() =>
[1, 2, 3].map(() => null)
);
return null;
};
```
Compiler changes it to
```jsx
const TestComponent = (t0) => {
useDerivedValue(_temp2);
return null;
};
function _temp() {
return null;
}
function _temp2() {
return [1, 2, 3].map(_temp);
}
```
Note that `_temp` and `_temp2` are extracted outside. It's ok to extract `_temp2`, the callback of `useDerivedValue`, it's handled on our side as a part of the support for the Compiler. It's not ok to extract `_temp`.
The problem lies in the fact that we can (and we do) deduce that `_temp2` must be a worklet, but we cannot **in general** infer if `_temp` should be a worklet. This leads to `_temp` not being workletized and causing a runtime error. We also can't workletize it regardless, in some flows it actually shouldn't be a worklet.
To fix it we need to keep all functions defined in a worklet to stay in this worklet.
### How often does this bug happen?
Every time
### What version of React are you using?
19
### What version of React Compiler are you using?
19.0.0-beta-bafa41b-20250307
Last updated: 19
Bug: Uncontrolled `<input />` element has value attribute removed#32576
Status: Unconfirmed
@imjordanxd:<!--
Please provide a clear and concise description of what the bug is. Include
screenshots if needed. Please test using the latest version of the relevant
React packages to make sure your issue has not already been fixed.
-->
React version: React 19
## Steps To Reproduce
1. Pass an `value={undefined}` as a prop to an `<input />` element
2. Observe the DOM and see the `value` attribute is absent
<!--
Your bug will get fixed much faster if we can run your code and it doesn't
have dependencies other than React. Issues without reproduction steps or
code examples may be immediately closed as not actionable.
-->
Link to code example:
[React 18](https://codesandbox.io/p/sandbox/34dw4q)
[React 19](https://codesandbox.io/p/sandbox/3p7hp9)
<!--
Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
repository on GitHub, or provide a minimal code example that reproduces the
problem. You may provide a screenshot of the application if you think it is
relevant to your bug report. Here are some tips for providing a minimal
example: https://stackoverflow.com/help/mcve.
-->
## The current behavior
React 18 passed a _booleanish_ attribute i.e. `<input value />`. React 19 omitted the attribute altogether i.e. `<input />`. This is causing a lot of failures in our snapshot tests. I'm not sure if this behaviour is expected in React 19 and I can't find anything in the release notes apart from [this loosely related PR](https://github.com/facebook/react/pull/18513). If this behaviour is expected in 19, it would be great to mention that somewhere!
Last updated: 3
[Compiler Bug]: eslint-plugin-react-compiler has incorrect type definitions#32575
Type: Bug
Status: Unconfirmed
Component: Optimizing Compiler
@printfn:### What kind of issue is this?
- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [x] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)
### Link to repro
https://stackblitz.com/edit/vitejs-vite-c52sauuy?file=eslint.config.js
### Repro steps
* Install eslint-plugin-react-compiler version 19.0.0-beta-bafa41b-20250307
* Add `reactCompiler.configs.recommended` to eslint.config.js (with `@ts-check` enabled)
* `npx tsc -b`
Error:
```
eslint.config.js:11:3 - error TS2345: Argument of type '{ plugins: { 'react-compiler': { rules: { 'react-compiler': RuleModule; }; }; }; rules: { 'react-compiler/react-compiler': string; }; }' is not assignable to parameter of type 'InfiniteDepthConfigWithExtends'.
Type '{ plugins: { 'react-compiler': { rules: { 'react-compiler': RuleModule; }; }; }; rules: { 'react-compiler/react-compiler': string; }; }' is not assignable to type 'ConfigWithExtends'.
Types of property 'rules' are incompatible.
Type '{ 'react-compiler/react-compiler': string; }' is not assignable to type 'Partial<Record<string, RuleEntry>>'.
Property ''react-compiler/react-compiler'' is incompatible with index signature.
Type 'string' is not assignable to type 'RuleEntry | undefined'.
11 reactCompiler.configs.recommended,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Found 1 error.
```
### How often does this bug happen?
Every time
### What version of React are you using?
19.0.0
### What version of React Compiler are you using?
19.0.0-beta-bafa41b-20250307
Last updated: 1
[React 19] Need Bring Back `_debugSource` or Provide an Equivalent for Better Developer Experience#32574
React 19
@zthxxx:
### **Problem**
React 19 removed the `_debugSource` property from Fiber nodes ([PR #28265](https://github.com/facebook/react/pull/28265)), which has **broken critical developer tools** that enable "click to open the source from browser" functionality.
This removal directly impacts the workflow of thousands of React developers who rely on these tools for rapid debugging and code navigation.
### **Affected Ecosystem**
The following tools/packages as far as I known are affected by React 19:
- [react-dev-inspector](https://github.com/zthxxx/react-dev-inspector)
- [locatorjs](https://github.com/infi-pc/locatorjs)
- [code-inspector](https://github.com/zh-lx/code-inspector)
- [click-to-component](https://github.com/ericclemmons/click-to-component)
- [radon-ide](https://github.com/software-mansion/radon-ide)
- [vite-plugin-react-click-to-component](https://github.com/ArnaudBarre/vite-plugin-react-click-to-component)
- [react-inspector](https://github.com/hand-dot/react-inspector)
- [figment](https://github.com/dankoster/figment)
(see issues of them)
### **Impact**
This change:
1. Degrades React's developer experience compared to frameworks like Vue, where source mapping is a first-class feature
2. Forces developers to abandon established debugging workflows
3. Undermines community-driven tooling that compensates for React's lack of official devtools in this area. <br/>
Past issues like #31981 have attempted to address this problem, but received no response from the React team. Does the core team lack prioritization on this matter?
### **Critical Questions**
1. **Why was `_debugSource` need to be remove?** The original PR offers no justification for any user cases improvement.
2. **Will React commit to restoring this functionality?** either restore `_debugSource` or a supported API, `_debugStack` isn’t a viable replacement
3. I known the removal was intentional, **what is the recommended path forward** for tools requiring source position mapping? `_debugStack` cannot parse for path on filesystem
### **Call to Action**
We appeal to the React team to:
- Explain the reasoning behind this design
- Either reintroduce `_debugSource` or provide an equivalent official mechanism for source mapping
- Collaborate with the community to preserve critical debugging workflows
### **Final**
The React community has spent 5+ years in building tools to close DX gaps. Arbitrarily removing internal properties like `_debugSource` without warning or alternatives undermines community efforts.
**Vue developers enjoy seamless click-to-source workflows – why can't React developers have parity?**
Thanks in advance!
