Use native scheduler if defined #1
Closed
Conversation
This file contains 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
<!-- 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 debug-test --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 <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> This is the other approach for unifying default and sync lane facebook#25524. The approach in that PR is to merge default and continuous lane into the sync lane, and use a new field to track the priority. But there are a couple places that field will be needed, and it is difficult to correctly reset the field when there is no sync lane. In this PR we take the other approach that doesn't remove any lane, but batch them to get the behavior we want. ## 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. --> yarn test Co-authored-by: Andrew Clark <[email protected]>
…me (facebook#25862) ~~[Fizz] Duplicate completeBoundaryWithStyles to not reference globals~~ ## Summary Follow-up / cleanup PR to facebook#25437 - `completeBoundaryWithStylesInlineLocals` is used by the Fizz external runtime, which bundles together all Fizz instruction functions (and is able to reference / rename `completeBoundary` and `resourceMap` as locals). - `completeBoundaryWithStylesInlineGlobals` is used by the Fizz inline script writer, which sends Fizz instruction functions on an as-needed basis. This version needs to reference `completeBoundary($RC)` and `resourceMap($RM)` as globals. Ideally, Closure would take care of inlining a shared implementation, but I couldn't figure out a zero-overhead inline due to lack of an `@inline` compiler directive. It seems that Closure thinks that a shared `completeBoundaryWithStyles` is too large and will always keep it as a separate function. I've also tried currying / writing a higher order function (`getCompleteBoundaryWithStyles`) with no luck ## How did you test this change? - generated Fizz inline instructions should be unchanged - bundle size for unstable_external_runtime should be slightly smaller (due to lack of globals) - `ReactDOMFizzServer-test.js` and `ReactDOMFloat-test.js` should be unaffected
This setting is an incremental path to the next Flow version enforcing type annotations on most functions (except some inline callbacks). Used ``` node_modules/.bin/flow codemod annotate-functions-and-classes --write . ``` to add a majority of the types with some hand cleanup when for large inferred objects that should just be `Fiber` or weird constructs including `any`. Suppressed the remaining issues. Builds on facebook#25918
This enables the "exact_empty_objects" setting for Flow which makes empty objects exact instead of building up the type as properties are added in code below. This is in preparation to Flow 191 which makes this the default and removes the config. More about the change in the Flow blog [here](https://medium.com/flow-type/improved-handling-of-the-empty-object-in-flow-ead91887e40c).
After the previous changes these upgrade are easy. - removes config options that were removed - object index access now requires an indexer key in the type, this cause a handful of errors that were fixed - undefined keys error in all places, this needed a few extra suppressions for repeated undefined identifiers. Flow's [CHANGELOG.md](https://github.com/facebook/flow/blob/main/Changelog.md).
Reuse variable `remoteRepoDir` , same with `join(__dirname, 'remote-repo')`.
## Summary I was reading the source code of `ReactFiberLane.js` and I found the third parameter of the function markRootPinged was not used. So I think we can remove it. ## How did you test this change? There is no logic changed, so I think there is no need to add unit tests. So I run `yarn test` and `yarn test --prod` locally and all tests are passed. Co-authored-by: Jan Kassens <[email protected]>
These suppressions are no longer required. Generated using: ```sh flow/tool update-suppressions . ``` followed by adding back 1 or 2 suppressions that were only triggered in some configurations.
This mock exists in 2 directories (with identical implementation) and Jest just picks one at random. This removes one which makes it at least deterministic and fixes a Jest warning on startup. It existed in these 2 places: - `packages/react-server-dom-relay/src/__mocks__/JSResourceReferenceImpl.js` - `packages/react-server-native-relay/src/__mocks__/JSResourceReferenceImpl.js` (removed)
…book#25978) This feature flag was always set to true, we can easily clean it up.
SSR currently stack overflows when the component tree is extremely large
…cebook#25575) These values are never imported into `ReactFeatureFlags.www.js`, so they're unused: - `allowConcurrentByDefault` - `consoleManagedByDevToolsDuringStrictMode` These values are never set in the WWW module (https://fburl.com/code/dsb2ohv8), so they're always `undefined` on www: - `createRootStrictEffectsByDefault` - `enableClientRenderFallbackOnTextMismatch`
…nts and warnAboutStringRefs (facebook#25980) These feature flags are fully rolled out and easy to clean up. Let's remove them!
…#25992) This `warnAboutDeprecatedLifecycles` is always true, and should be safe to remove.
This isn't configured to a dynamic value on www, so hardcode here to false.
This shim is no longer needed on www, in fact I had already deleted it there and it's currently not on www. See D42503692 which is trying to add it back as I didn't realize this file was synced from GitHub.
## Summary Should unblock facebook#25970 If the callback for `toWarnDev` was `async` and threw, we didn't ultimately reject the await Promise from the matcher. This resulted in tests failing even though the failure was expected due to a test gate. ## How did you test this change? - [x] tested in facebook#25970 with `yarn test --r=stable --env=development packages/react-dom/src/__tests__/ReactDOMFizzServer-test.js --watch` - [x] `yarn test` - [x] CI
I noticed this was an experiment concluded 16 months ago (facebook#21679) that this extra work is beneficial to break up cycles leaking memory in product code.
…26064) Need to add types to these two maps to unblock React Native sync.
The old token was revoked, this updates the token by reading from CI secrets instead, I'm not sure there's benefit in making it publicly visible.
## Summary resolves facebook#26051 After we upgrade to Manifest V3, the browser no longer allow us to run `eval` within the extension. It's not a problem for prod build, but for dev build, webpack has been using eval to inject the source map for devtool. This PR changes it to an alternative method.
This renames Module References to Client References, since they are in the server->client direction. I also changed the Proxies exposed from the `node-register` loader to provide better error messages. Ideally, some of this should be replicated in the ESM loader too but neither are the source of truth. We'll replicate this in the static form in the Next.js loaders. cc @huozhi @shuding - All references are now functions so that when you call them on the server, we can yield a better error message. - References that are themselves already referring to an export name are now proxies that error when you dot into them. - `use(...)` can now be used on a client reference to unwrap it server side and then pass a reference to the awaited value.
Revert facebook@353c30252. The commit breaks old React Native where `nativeFabricUIManager` is undefined. I need to add unit test for this to make sure it doesn't happen in the future and create a mechanism to deal with undefined `nativeFabricUIManager`. This is to unblock React sync to React Native.
…acebook#26016) ## Summary The flag was first added in facebook#16157 and was rolled out to employees in D17430095. facebook#25997 removed this flag because it wasn't dynamically set to a value in www. The www side was mistakenly removed in D41851685 due to deprecation of a TypedJSModule but we still want to keep this flag, so let's add it back in + add a GK on the www side to match the previous rollout. See D42574435 for the dynamic value change in www ## How did you test this change? ``` yarn test yarn test --prod ```
I fully enabled this flag internally now and unless I see complications, we should be able to clean this up in the code.
The old version of prettier we were using didn't support the Flow syntax to access properties in a type using `SomeType['prop']`. This updates `prettier` and `rollup-plugin-prettier` to the latest versions. I added the prettier config `arrowParens: "avoid"` to reduce the diff size as the default has changed in Prettier 2.0. The largest amount of changes comes from function expressions now having a space. This doesn't have an option to preserve the old behavior, so we have to update this.
## Summary Removing package jest-mock-scheduler introduced in PR facebook#14358, as it is no longer referenced in the main branch code. The following files previously referenced it: - packages/scheduler/src/__tests__/Scheduler-test.js - packages/scheduler/src/__tests__/SchedulerDOM-test.js - packages/shared/__tests__/ReactDOMFrameScheduling-test.js - scripts/jest/setupTests.js - scripts/rollup/bundles.js ## How did you test this change? ci green
## Summary This PR removes the unused dependency 'abort-controller' from the project. it helps to keep the project clean and maintainable. ## How did you test this change? ci green
## Overview I'm landing this flag internally so we can delete this
…k#26492) ## Summary - Drop extension support for Chrome / Edge <v102 since they have less than 0.1% usage ([see data](https://caniuse.com/usage-table)) - Improve script injection logic when possible so that the scripts injected by the extension are no longer shown in Network (which caused a lot of confusion in the past) ## How did you test this change? Built and tested locally, works as usual on Firefox. For Chrome/Edge **Before:** Scripts shown in Network tab <img width="1279" alt="Untitled 2" src="https://user-images.githubusercontent.com/1001890/228074363-1d00d503-d4b5-4339-8dd6-fd0467e36e3e.png"> **After:** No scripts shown <img width="1329" alt="image" src="https://user-images.githubusercontent.com/1001890/228074596-2084722b-bf3c-495e-a852-15f122233155.png"> --------- Co-authored-by: Ruslan Lesiutin <[email protected]>
## Overview There's a known infinite loop with this but we're not running an experiment any time soon.
This updates the Suspense fuzz tester to use `act` to recursively flush timers instead of doing it manually. This still isn't great because ideally the fuzz tester wouldn't fake timers at all. It should resolve promises using a custom queue instead of Jest's fake timer queue, like we've started doing in our other Suspense tests (i.e. the `resolveText` pattern). That's because our internal `act` API (not the public one, the one we use in our tests) uses Jest's fake timer queue as a way to force Suspense fallbacks to appear. However I'm not interested in upgrading this test suite to a better strategy right now because if I were writing a Suspense fuzzer today I would probably use an entirely different approach. So this is just an incremental improvement to make it slightly less decoupled to React implementation details.
Token is not required for GET
…book#26501) I use a shared helper when setting properties into a helper whether it's initial or update. I moved the special cases per tag to commit phase so we can check it only once. This also effectively inlines getHostProps which can be done in a single check per prop key. The diffProperties operation is simplified to mostly just generating a plain diff of all properties, generating an update payload. This might generate a few more entries that are now ignored in the commit phase. that previously would've been ignored earlier. We could skip this and just do the whole diff in the commit phase by always scheduling a commit phase update. I tested the attribute table (one change documented below) and a few select DOM fixtures.
## Summary Adds support for sending `BigInt` to Flight and Flight Reply ## How did you test this change? - added tests
…acebook#26478) ## Summary With facebook#26349 we now serialize `undefined`. However, deserializing it on the client is currently indistinguishable from the value missing entirely due to how `JSON.parse` treats `undefined` return value of reviver functions. This leads to inconsistent behavior of the `Object.hasOwn` or `in` operator (used for narrowing in TypeScript). In TypeScript-speak, `{ prop: T | undefined}` will arrive as `{ prop?: T }`. ## How did you test this change? - Added test that is expected to fail. Though ideally the implementation of the component would not care whether it's used on the client or server.
This deletes the ReactIncrementalTriangle test suite, which I originally added back in 2017 when I was working on Fiber's "resuming" feature. It was meant to simulate a similar scenario as Seb's "Sierpinski Triangle" Fiber demo. We eventually ended up removing resuming, but we kept this fuzz tester around since it wasn't really harming anything. However, over the years, we've had to make many small tweaks to decouple it from implementation details, to the point that it doesn't test anything useful anymore. And the thing that it originally tested has long since been removed. If or when we do add back resuming, we would write a different fuzz tester from scratch rather than build on this one. So rather than continue to contrive ways to prevent it from breaking, I propose we delete it. We still have other fuzz testers for things like Suspense and context propagation. Only this particular one has outlived its usefulness.
Continuing my journey to migrate all the Scheduler flush* methods to async versions of the same helpers.
…ptURLs is on (facebook#26507) We currently throw an error when disableJavaScriptURLs is on and trigger an error boundary. I kind of thought that's what would happen with CSP or Trusted Types anyway. However, that's not what happens. Instead, in those environments what happens is that the error is triggered when you try to actually visit those links. So if you `preventDefault()` or something it'll never show up and since the error just logs to the console or to a violation logger, it's effectively a noop to users. We can simulate the same without CSP by simply generating a different `javascript:` url that throws instead of executing the potential attack vector. This still allows these to be used - at least as long as you preventDefault before using them in practice. This might be legit for forms. We still don't recommend using them for links-as-buttons since it'll be possible to "Open in a New Tab" and other weird artifacts. For links we still recommend the technique of assigning a button role etc. It also is a little nicer when an attack actually happens because at least it doesn't allow an attacker to trigger error boundaries and effectively deny access to a page.
This is not really part of the bindings, it's more part of the package entry points. /shared/ is not really right neither because it's more like an isomorphic entry point and not some utility.
…facebook#26510) ## Summary Updates the `useMemoCache()` tests to validate that the memo cache persists when a component does a setState during render or throws during render. Forget's compilation output follows the general pattern used in this test and is resilient to rendering running partway and then again with different inputs. ## How did you test this change? `yarn test` (this is a test-only change)
This is a change to some undefined behavior that we though we would do at one point but decided not to roll out. It's already disabled everywhere, so this just deletes the branch from the implementation and the tests.
This is a step towards getting rid of the meta programming in DOMProperty and CSSProperty. This moves isAttributeNameSafe and isUnitlessNumber to a separate shared modules. isUnitlessNumber is now a single switch instead of meta-programming. There is a slight behavior change here in that I hard code a specific set of vendor-prefixed attributes instead of prefixing all the unitless properties. I based this list on what getComputedStyle returns in current browsers. I removed Opera prefixes because they were [removed in Opera](https://dev.opera.com/blog/css-vendor-prefixes-in-opera-12-50-snapshots/) itself. I included the ms ones mentioned [in the original PR](facebook@5abcce5). These shouldn't really be used anymore anyway so should be pretty safe. Worst case, they'll fallback to the other property if you specify both. Finally I inline the mustUseProperty special cases - which are also the only thing that uses propertyName. These are really all controlled components and all booleans. I'm making a small breaking change here by treating `checked` and `selected` specially only on the `input` and `option` tags instead of all tags. That's because those are the only DOM nodes that actually have those properties but we used to set them as expandos instead of attributes before. That's why one of the tests is updated to now use `input` instead of testing an expando on a `div` which isn't a real use case. Interestingly this also uncovered that we update checked twice for some reason but keeping that logic for now. Ideally `multiple` and `muted` should move into `select` and `audio`/`video` respectively for the same reason. No change to the attribute-behavior fixture.
Follow up of facebook#26499 A Circle CI team member got back to me. It is indeed not necessary, but they had a regression not long ago on fetching without token. https://discuss.circleci.com/t/is-api-token-required-when-fetching-artifacts/47606/5 To mitigate the impact of this kind of issues, let's add this token to requests' header when it's available.
Normally we allow any attribute/property on custom elements. However it's a shared namespace. The `aria-` namespace applies to all generic elements which are shared with custom elements. So arguably adding custom extensions there is a really bad idea since it can conflict with future additions. It's possible there is a new standard one that's polyfilled by a custom element but the same issue applies to React in general that we might warn for very new additions so we just have to be quick on that. cc @josepharhar
## Summary Our toy webpack plugin for Server Components is pretty broken right now because, now that `.client.js` convention is gone, it ends up adding every single JS file it can find (including `node_modules`) as a potential async dependency. Instead, it should only look for files with the `'use client'` directive. The ideal way is to implement this by bundling the RSC graph first. Then, we would know which `'use client'` files were actually discovered — and so there would be no point to scanning the disk for them. That's how Next.js bundler does it. We're not doing that here. This toy plugin is very simple, and I'm not planning to do heavy lifting. I'm just bringing it up to date with the convention. The change is that we now read every file we discover (alas), bail if it has no `'use client'`, and parse it if it does (to verify it's actually used as a directive). I've changed to use `acorn-loose` because it's forgiving of JSX (and likely TypeScript/Flow). Otherwise, this wouldn't work on uncompiled source. ## Test plan Verified I can get our initial Server Components Demo running after this change. Previously, it would get stuck compiling and then emit thousands of errors. Also confirmed the fixture still works. (It doesn’t work correctly on the first load after dev server starts, but that’s already the case on main so seems unrelated.)
…6524) This PR has a bunch of surrounding refactoring. See individual commits. The main change is that we no longer special case `typeof is === 'string'` as a special case according to the `enableCustomElementPropertySupport` flag. Effectively this means that you can't use custom properties/events, other than the ones React knows about on `<input is="my-input">` extensions. This is unfortunate but there's too many paths that are forked in inconsistent ways since we fork based on tag name. I think __the solution is to let all React elements set unknown properties/events in the same way as this flag__ but that's a bigger change than this flag implies. Since `is` is not universally supported yet anyway, this doesn't seem like a huge loss. Attributes still work. We still support passing the `is` prop and turn that into the appropriate createElement call. @josepharhar
# Overview Landing this flag internally, will test this PR in React Native before merging.
…ay (facebook#26521) This flag is already enabled everywhere except for www, which is blocked by a few tests that assert on the old behavior. Once www is ready, I'll land this.
When React receives new input (via `setState`, a Suspense promise resolution, and so on), it needs to ensure there's a rendering task associated with the update. Most of this happens `ensureRootIsScheduled`. If a single event contains multiple updates, we end up running the scheduling code once per update. But this is wasteful because we really only need to run it once, at the end of the event (or in the case of flushSync, at the end of the scope function's execution). So this PR moves the scheduling logic to happen in a microtask instead. In some cases, we will force it run earlier than that, like for `flushSync`, but since updates are batched by default, it will almost always happen in the microtask. Even for discrete updates. In production, this should have no observable behavior difference. In a testing environment that uses `act`, this should also not have a behavior difference because React will push these tasks to an internal `act` queue. However, tests that do not use `act` and do not simulate an actual production environment (like an e2e test) may be affected. For example, before this change, if a test were to call `setState` outside of `act` and then immediately call `jest.runAllTimers()`, the update would be synchronously applied. After this change, that will no longer work because the rendering task (a timer, in this case) isn't scheduled until after the microtask queue has run. I don't expect this to be an issue in practice because most people do not write their tests this way. They either use `act`, or they write e2e-style tests. The biggest exception has been... our own internal test suite. Until recently, many of our tests were written in a way that accidentally relied on the updates being scheduled synchronously. Over the past few weeks, @tyao1 and I have gradually converted the test suite to use a new set of testing helpers that are resilient to this implementation detail. (There are also some old Relay tests that were written in the style of React's internal test suite. Those will need to be fixed, too.) The larger motivation behind this change, aside from a minor performance improvement, is we intend to use this new microtask to perform additional logic that doesn't yet exist. Like inferring the priority of a custom event.
I originally made it so that a Suspensey commit — i.e. a commit that's waiting for a stylesheet, image, or font to load before proceeding — could not be interrupted by transitions. My reasoning was that Suspensey commits always time out after a short interval, anyway, so if the incoming update isn't urgent, it's better to wait to commit the current frame instead of throwing it away. I don't think this rationale was correct, for a few reasons. There are some cases where we'll suspend for a longer duration, like stylesheets — it's nearly always a bad idea to show content before its styles have loaded, so we're going to be extend this timeout to be really long. But even in the case where the timeout is shorter, like fonts, if you get a new update, it's possible (even likely) that update will allow us to avoid showing a fallback, like by navigating to a different page. So we might as well try. The behavior now matches our behavior for interrupting a suspended render phase (i.e. `use`), which makes sense because they're not that conceptually different.
We almost never want to show content before its styles have loaded. But eventually we will give up and allow unstyled content. So this extends the timeout to a full minute. This somewhat arbitrary — big enough that you'd only reach it under extreme circumstances. Note that, like regular Suspense, the app is still interactive while we're waiting for content to load. Only the unstyled content is blocked from appearing, not updates in general. A new update will interrupt it. We should figure out what the browser engines do during initial page load and consider aligning our behavior with that. It's supposed to be render blocking by default but there may be some cases where they, too, give up and FOUC.
Continuation of facebook#26420 Fixes facebook#26385 and facebook#26419 --------- Co-authored-by: eps1lon <[email protected]> Co-authored-by: Andrew Clark <[email protected]>
…#26522) ## Summary Fixes facebook#24781 Restricting from editing props, which are class instances, because their internals should be opaque. Proposed changes: 1. Adding new data type `class_instance`: based on prototype chain of an object we will check if its plain or not. If not, then will be marked as `class_instance`. This should not affect `arrays`, ..., because we do this in the end of an `object` case in `getDataType` function. Important detail: this approach won't work for objects created with `Object.create`, because of the custom prototype. This can also be bypassed by manually deleting a prototype ¯\\\_(ツ)_/¯ I am not sure if there might be a better solution (which will cover all cases) to detect if object is a class instance. Initially I was trying to use `Object.getPrototypeOf(object) === Object.prototype`, but this won't work for cases when we are dealing with `iframe`. 2. Objects with a type `class_instance` will be marked as unserializable and read-only. ## Demo `person` is a class instance, `object` is a plain object https://user-images.githubusercontent.com/28902667/228914791-ebdc8ab0-eb5c-426d-8163-66d56b5e8790.mov
There was a bug in the attribute seralization for stylesheet resources injected by the Fizz runtime. For boolean properties the attribute value was set to an empty string but later immediately set to a string coerced value. This PR fixes that bug and refactors the code paths to be clearer
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
fetchPriorityto<img>and<link>(AddfetchPriorityto<img>and<link>facebook/react#25927)useandrenderDidSuspendDelayIfPossibleimplementations (UnifyuseandrenderDidSuspendDelayIfPossibleimplementations facebook/react#25922)semverusages withcompare-versionsfor smaller bundle size (Replace DevToolssemverusages withcompare-versionsfor smaller bundle size facebook/react#26122)transformOriginprop (Add support for SVGtransformOriginprop facebook/react#26130)scaleas a unitless property (Addscaleas a unitless property facebook/react#25601)yarn starttoyarn devandyarn start:prodtoyarn start(Renameyarn starttoyarn devandyarn start:prodtoyarn startfacebook/react#26209)itemProp& hydrate more tolerantly in hoist contexts ([Float][Fizz][Fiber] - Do not hoist elements withitemProp& hydrate more tolerantly in hoist contexts facebook/react#26256)act: Call scope function after an async gap (Internalact: Call scope function after an async gap facebook/react#26347)undefinedfrom render ([Flight] Add support for returningundefinedfrom render facebook/react#26349).internaloverride from untrusted URL tests (Remote.internaloverride from untrusted URL tests facebook/react#26372)actfrom DevTools e2e test (Remove internalactfrom DevTools e2e test facebook/react#26376)react-dom/unstable_testing(Remove FeatureFlags fork forreact-dom/unstable_testingfacebook/react#26383)use([Flight fixture] Remove redundantusefacebook/react#26373)"react-dom/server.bun"entry in package.json"exports"(Add missing"react-dom/server.bun"entry in package.json"exports"facebook/react#26402)act(Update Suspense fuzz tests to useactfacebook/react#26498)is(Limit the meaning of "custom element" to not includeisfacebook/react#26524)Summary
How did you test this change?