Use concurrent root in RTR #28498

jackpope · 2024-03-05T21:22:57Z

Based on

Reusing the disableLegacyMode flag, we set ReactTestRenderer to always render with concurrent root where legacy APIs are no longer available. If disableLegacyMode is false, we continue to allow the unstable_isConcurrent option determine the root type.

Also checking a global IS_REACT_NATIVE_TEST_ENVIRONMENT so we can maintain the existing behavior for RN until we remove legacy root support there.

react-sizebot · 2024-03-05T21:26:21Z

Comparing: 1f9befe...a5b7ae1

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	175.91 kB	175.91 kB	=	54.53 kB	54.53 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	172.39 kB	172.39 kB	=	53.70 kB	53.70 kB
facebook-www/ReactDOM-prod.classic.js	=	589.86 kB	589.86 kB	=	103.60 kB	103.60 kB
facebook-www/ReactDOM-prod.modern.js	=	573.39 kB	573.39 kB	=	100.66 kB	100.66 kB
test_utils/ReactAllWarnings.js	Deleted	64.83 kB	0.00 kB	Deleted	16.08 kB	0.00 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
test_utils/ReactAllWarnings.js	Deleted	64.83 kB	0.00 kB	Deleted	16.08 kB	0.00 kB

Generated by 🚫 dangerJS against a5b7ae1

Reverting some of #27804 which renamed this option to stable. This PR just replaces internal usage to make upcoming PRs cleaner. Keeping isConcurrent unstable for the next major release in order to enable a broader deprecation of RTR and be consistent with concurrent rendering everywhere for next major. (#28498) - Next major will use concurrent root - The old behavior (legacy root by default, concurrent root with unstable option) will be preserved for React Native until new architecture is fully shipped. - Flag and legacy root usage can be removed after RN dependency is unblocked without an additional breaking change

Reverting some of #27804 which renamed this option to stable. This PR just replaces internal usage to make upcoming PRs cleaner. Keeping isConcurrent unstable for the next major release in order to enable a broader deprecation of RTR and be consistent with concurrent rendering everywhere for next major. (#28498) - Next major will use concurrent root - The old behavior (legacy root by default, concurrent root with unstable option) will be preserved for React Native until new architecture is fully shipped. - Flag and legacy root usage can be removed after RN dependency is unblocked without an additional breaking change DiffTrain build for [3832730](3832730)

- Make all test cases in ReactLazy use RTR with concurrent root - Except, two cases with "legacy mode" specified in description. These are moved to a separate description block where the disableLegacyMode flag is turned off to allow RTR to use legacy root after #28498

Based on - #28497 - #28419 Reusing the disableLegacyMode flag, we set ReactTestRenderer to always render with concurrent root where legacy APIs are no longer available. If disableLegacyMode is false, we continue to allow the unstable_isConcurrent option determine the root type. Also checking a global `IS_REACT_NATIVE_TEST_ENVIRONMENT` so we can maintain the existing behavior for RN until we remove legacy root support there. DiffTrain build for [bb66aa3](bb66aa3)

Stacked on top of #28498 for test fixes. ### Don't Rethrow When we started React it was 1:1 setState calls a series of renders and if they error, it errors where the setState was called. Simple. However, then batching came and the error actually got thrown somewhere else. With concurrent mode, it's not even possible to get setState itself to throw anymore. In fact, all APIs that can rethrow out of React are executed either at the root of the scheduler or inside a DOM event handler. If you throw inside a React.startTransition callback that's sync, then that will bubble out of the startTransition but if you throw inside an async callback or a useTransition we now need to handle it at the hook site. So in 19 we need to make all React.startTransition swallow the error (and report them to reportError). The only one remaining that can throw is flushSync but it doesn't really make sense for it to throw at the callsite neither because batching. Just because something rendered in this flush doesn't mean it was rendered due to what was just scheduled and doesn't mean that it should abort any of the remaining code afterwards. setState is fire and forget. It's send an instruction elsewhere, it's not part of the current imperative code. Error boundaries never rethrow. Since you should really always have error boundaries, most of the time, it wouldn't rethrow anyway. Rethrowing also actually currently drops errors on the floor since we can only rethrow the first error, so to avoid that we'd need to call reportError anyway. This happens in RN events. The other issue with rethrowing is that it logs an extra console.error. Since we're not sure that user code will actually log it anywhere we still log it too just like we do with errors inside error boundaries which leads all of these to log twice. The goal of this PR is to never rethrow out of React instead, errors outside of error boundaries get logged to reportError. Event system errors too. ### Breaking Changes The main thing this affects is testing where you want to inspect the errors thrown. To make it easier to port, if you're inside `act` we track the error into act in an aggregate error and then rethrow it at the root of `act`. Unlike before though, if you flush synchronously inside of act it'll still continue until the end of act before rethrowing. I expect most user code breakages would be to migrate from `flushSync` to `act` if you assert on throwing. However, in the React repo we also have `internalAct` and the `waitForThrow` helpers. Since these have to use public production implementations we track these using the global onerror or process uncaughtException. Unlike regular act, includes both event handler errors and onRecoverableError by default too. Not just render/commit errors. So I had to account for that in our tests. We restore logging an extra log for uncaught errors after the main log with the component stack in it. We use `console.warn`. This is not yet ignorable if you preventDefault to the main error event. To avoid confusion if you don't end up logging the error to console I just added `An error occurred`. ### Polyfill All browsers we support really supports `reportError` but not all test and server environments do, so I implemented a polyfill for browser and node in `shared/reportGlobalError`. I don't love that this is included in all builds and gets duplicated into isomorphic even though it's not actually needed in production. Maybe in the future we can require a polyfill for this. ### Follow Ups In a follow up, I'll make caught vs uncaught error handling be configurable too. --------- Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>

Stacked on top of #28498 for test fixes. ### Don't Rethrow When we started React it was 1:1 setState calls a series of renders and if they error, it errors where the setState was called. Simple. However, then batching came and the error actually got thrown somewhere else. With concurrent mode, it's not even possible to get setState itself to throw anymore. In fact, all APIs that can rethrow out of React are executed either at the root of the scheduler or inside a DOM event handler. If you throw inside a React.startTransition callback that's sync, then that will bubble out of the startTransition but if you throw inside an async callback or a useTransition we now need to handle it at the hook site. So in 19 we need to make all React.startTransition swallow the error (and report them to reportError). The only one remaining that can throw is flushSync but it doesn't really make sense for it to throw at the callsite neither because batching. Just because something rendered in this flush doesn't mean it was rendered due to what was just scheduled and doesn't mean that it should abort any of the remaining code afterwards. setState is fire and forget. It's send an instruction elsewhere, it's not part of the current imperative code. Error boundaries never rethrow. Since you should really always have error boundaries, most of the time, it wouldn't rethrow anyway. Rethrowing also actually currently drops errors on the floor since we can only rethrow the first error, so to avoid that we'd need to call reportError anyway. This happens in RN events. The other issue with rethrowing is that it logs an extra console.error. Since we're not sure that user code will actually log it anywhere we still log it too just like we do with errors inside error boundaries which leads all of these to log twice. The goal of this PR is to never rethrow out of React instead, errors outside of error boundaries get logged to reportError. Event system errors too. ### Breaking Changes The main thing this affects is testing where you want to inspect the errors thrown. To make it easier to port, if you're inside `act` we track the error into act in an aggregate error and then rethrow it at the root of `act`. Unlike before though, if you flush synchronously inside of act it'll still continue until the end of act before rethrowing. I expect most user code breakages would be to migrate from `flushSync` to `act` if you assert on throwing. However, in the React repo we also have `internalAct` and the `waitForThrow` helpers. Since these have to use public production implementations we track these using the global onerror or process uncaughtException. Unlike regular act, includes both event handler errors and onRecoverableError by default too. Not just render/commit errors. So I had to account for that in our tests. We restore logging an extra log for uncaught errors after the main log with the component stack in it. We use `console.warn`. This is not yet ignorable if you preventDefault to the main error event. To avoid confusion if you don't end up logging the error to console I just added `An error occurred`. ### Polyfill All browsers we support really supports `reportError` but not all test and server environments do, so I implemented a polyfill for browser and node in `shared/reportGlobalError`. I don't love that this is included in all builds and gets duplicated into isomorphic even though it's not actually needed in production. Maybe in the future we can require a polyfill for this. ### Follow Ups In a follow up, I'll make caught vs uncaught error handling be configurable too. --------- Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com> DiffTrain build for [6786563](6786563)

Reverting some of facebook#27804 which renamed this option to stable. This PR just replaces internal usage to make upcoming PRs cleaner. Keeping isConcurrent unstable for the next major release in order to enable a broader deprecation of RTR and be consistent with concurrent rendering everywhere for next major. (facebook#28498) - Next major will use concurrent root - The old behavior (legacy root by default, concurrent root with unstable option) will be preserved for React Native until new architecture is fully shipped. - Flag and legacy root usage can be removed after RN dependency is unblocked without an additional breaking change

- Make all test cases in ReactLazy use RTR with concurrent root - Except, two cases with "legacy mode" specified in description. These are moved to a separate description block where the disableLegacyMode flag is turned off to allow RTR to use legacy root after facebook#28498

Based on - facebook#28497 - facebook#28419 Reusing the disableLegacyMode flag, we set ReactTestRenderer to always render with concurrent root where legacy APIs are no longer available. If disableLegacyMode is false, we continue to allow the unstable_isConcurrent option determine the root type. Also checking a global `IS_REACT_NATIVE_TEST_ENVIRONMENT` so we can maintain the existing behavior for RN until we remove legacy root support there.

Stacked on top of facebook#28498 for test fixes. ### Don't Rethrow When we started React it was 1:1 setState calls a series of renders and if they error, it errors where the setState was called. Simple. However, then batching came and the error actually got thrown somewhere else. With concurrent mode, it's not even possible to get setState itself to throw anymore. In fact, all APIs that can rethrow out of React are executed either at the root of the scheduler or inside a DOM event handler. If you throw inside a React.startTransition callback that's sync, then that will bubble out of the startTransition but if you throw inside an async callback or a useTransition we now need to handle it at the hook site. So in 19 we need to make all React.startTransition swallow the error (and report them to reportError). The only one remaining that can throw is flushSync but it doesn't really make sense for it to throw at the callsite neither because batching. Just because something rendered in this flush doesn't mean it was rendered due to what was just scheduled and doesn't mean that it should abort any of the remaining code afterwards. setState is fire and forget. It's send an instruction elsewhere, it's not part of the current imperative code. Error boundaries never rethrow. Since you should really always have error boundaries, most of the time, it wouldn't rethrow anyway. Rethrowing also actually currently drops errors on the floor since we can only rethrow the first error, so to avoid that we'd need to call reportError anyway. This happens in RN events. The other issue with rethrowing is that it logs an extra console.error. Since we're not sure that user code will actually log it anywhere we still log it too just like we do with errors inside error boundaries which leads all of these to log twice. The goal of this PR is to never rethrow out of React instead, errors outside of error boundaries get logged to reportError. Event system errors too. ### Breaking Changes The main thing this affects is testing where you want to inspect the errors thrown. To make it easier to port, if you're inside `act` we track the error into act in an aggregate error and then rethrow it at the root of `act`. Unlike before though, if you flush synchronously inside of act it'll still continue until the end of act before rethrowing. I expect most user code breakages would be to migrate from `flushSync` to `act` if you assert on throwing. However, in the React repo we also have `internalAct` and the `waitForThrow` helpers. Since these have to use public production implementations we track these using the global onerror or process uncaughtException. Unlike regular act, includes both event handler errors and onRecoverableError by default too. Not just render/commit errors. So I had to account for that in our tests. We restore logging an extra log for uncaught errors after the main log with the component stack in it. We use `console.warn`. This is not yet ignorable if you preventDefault to the main error event. To avoid confusion if you don't end up logging the error to console I just added `An error occurred`. ### Polyfill All browsers we support really supports `reportError` but not all test and server environments do, so I implemented a polyfill for browser and node in `shared/reportGlobalError`. I don't love that this is included in all builds and gets duplicated into isomorphic even though it's not actually needed in production. Maybe in the future we can require a polyfill for this. ### Follow Ups In a follow up, I'll make caught vs uncaught error handling be configurable too. --------- Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>

Based on - #28497 - #28419 Reusing the disableLegacyMode flag, we set ReactTestRenderer to always render with concurrent root where legacy APIs are no longer available. If disableLegacyMode is false, we continue to allow the unstable_isConcurrent option determine the root type. Also checking a global `IS_REACT_NATIVE_TEST_ENVIRONMENT` so we can maintain the existing behavior for RN until we remove legacy root support there. DiffTrain build for commit bb66aa3.

Stacked on top of #28498 for test fixes. ### Don't Rethrow When we started React it was 1:1 setState calls a series of renders and if they error, it errors where the setState was called. Simple. However, then batching came and the error actually got thrown somewhere else. With concurrent mode, it's not even possible to get setState itself to throw anymore. In fact, all APIs that can rethrow out of React are executed either at the root of the scheduler or inside a DOM event handler. If you throw inside a React.startTransition callback that's sync, then that will bubble out of the startTransition but if you throw inside an async callback or a useTransition we now need to handle it at the hook site. So in 19 we need to make all React.startTransition swallow the error (and report them to reportError). The only one remaining that can throw is flushSync but it doesn't really make sense for it to throw at the callsite neither because batching. Just because something rendered in this flush doesn't mean it was rendered due to what was just scheduled and doesn't mean that it should abort any of the remaining code afterwards. setState is fire and forget. It's send an instruction elsewhere, it's not part of the current imperative code. Error boundaries never rethrow. Since you should really always have error boundaries, most of the time, it wouldn't rethrow anyway. Rethrowing also actually currently drops errors on the floor since we can only rethrow the first error, so to avoid that we'd need to call reportError anyway. This happens in RN events. The other issue with rethrowing is that it logs an extra console.error. Since we're not sure that user code will actually log it anywhere we still log it too just like we do with errors inside error boundaries which leads all of these to log twice. The goal of this PR is to never rethrow out of React instead, errors outside of error boundaries get logged to reportError. Event system errors too. ### Breaking Changes The main thing this affects is testing where you want to inspect the errors thrown. To make it easier to port, if you're inside `act` we track the error into act in an aggregate error and then rethrow it at the root of `act`. Unlike before though, if you flush synchronously inside of act it'll still continue until the end of act before rethrowing. I expect most user code breakages would be to migrate from `flushSync` to `act` if you assert on throwing. However, in the React repo we also have `internalAct` and the `waitForThrow` helpers. Since these have to use public production implementations we track these using the global onerror or process uncaughtException. Unlike regular act, includes both event handler errors and onRecoverableError by default too. Not just render/commit errors. So I had to account for that in our tests. We restore logging an extra log for uncaught errors after the main log with the component stack in it. We use `console.warn`. This is not yet ignorable if you preventDefault to the main error event. To avoid confusion if you don't end up logging the error to console I just added `An error occurred`. ### Polyfill All browsers we support really supports `reportError` but not all test and server environments do, so I implemented a polyfill for browser and node in `shared/reportGlobalError`. I don't love that this is included in all builds and gets duplicated into isomorphic even though it's not actually needed in production. Maybe in the future we can require a polyfill for this. ### Follow Ups In a follow up, I'll make caught vs uncaught error handling be configurable too. --------- Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com> DiffTrain build for commit 6786563.

facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Mar 5, 2024

jackpope mentioned this pull request Mar 12, 2024

Update isConcurrent RTR option usage #28546

Merged

jackpope force-pushed the rtr-legacy-path branch from 48f7664 to b81525e Compare March 20, 2024 15:32

jackpope mentioned this pull request Mar 20, 2024

Update RTR usage in ReactLazy-test #28598

Merged

jackpope force-pushed the rtr-legacy-path branch 2 times, most recently from faea69c to a2ce03c Compare March 21, 2024 19:12

jackpope changed the title ~~[draft] Use concurrent root in RTR~~ Use concurrent root in RTR Mar 21, 2024

jackpope added the React 19 label Mar 21, 2024

jackpope marked this pull request as ready for review March 22, 2024 13:57

sebmarkbage approved these changes Mar 25, 2024

View reviewed changes

sebmarkbage mentioned this pull request Mar 25, 2024

[Fiber] Don't Rethrow Errors at the Root #28627

Merged

jackpope force-pushed the rtr-legacy-path branch from e73df6e to ca324ab Compare March 25, 2024 18:21

Only concurrent render in RTR

8ba5ae0

jackpope force-pushed the rtr-legacy-path branch from 7d69402 to 8ba5ae0 Compare March 26, 2024 22:13

Jack Pope added 2 commits March 26, 2024 18:30

fix test

4da108a

empty

a5b7ae1

jackpope merged commit bb66aa3 into facebook:main Mar 26, 2024
38 checks passed

jackpope deleted the rtr-legacy-path branch March 26, 2024 22:53

This was referenced Apr 24, 2024

Update React from c3048aab4 to cb151849e1 vercel/next.js#64994

Closed

Support React 19 in App and Pages router vercel/next.js#65058

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use concurrent root in RTR #28498

Use concurrent root in RTR #28498

jackpope commented Mar 5, 2024 •

edited

Loading

react-sizebot commented Mar 5, 2024 •

edited

Loading

Use concurrent root in RTR #28498

Use concurrent root in RTR #28498

Conversation

jackpope commented Mar 5, 2024 • edited Loading

react-sizebot commented Mar 5, 2024 • edited Loading

Critical size changes

Significant size changes

jackpope commented Mar 5, 2024 •

edited

Loading

react-sizebot commented Mar 5, 2024 •

edited

Loading