Batch async actions even if useTransition is unmounted #28078

acdlite · 2024-01-24T23:09:18Z

If there are multiple updates inside an async action, they should all be rendered in the same batch, even if they are separate by an async operation (await). We currently implement this by suspending in the useTransition hook to block the update from committing until all possible updates have been scheduled by the action. The reason we did it this way is so you can "cancel" an action by navigating away from the UI that triggered it.

The problem with that approach, though, is that even if you navigate away from the useTransition hook, the action may have updated shared parts of the UI that are still in the tree. So we may need to continue suspending even after the useTransition hook is deleted.

In other words, the lifetime of an async action scope is longer than the lifetime of a particular useTransition hook.

The solution is to suspend whenever any update that is part of the async action scope is unwrapped during render. So, inside useState and useReducer.

This fixes a related issue where an optimistic update is reverted before the async action has finished, because we were relying on the useTransition hook to prevent the optimistic update from finishing.

This also prepares us to support async actions being passed to the non-hook form of startTransition (though this isn't implemented yet).

The error handling path has an invariant that a fiber that errors must have a parent, or else the renderer will panic. This is because the HostRoot fiber is the only fiber without a parent, and the HostRoot is supposed to handle all errors that weren't captured by an inner error boundary. However, this check currently exists in the same path that handles suspending. Unlike errors, we shouldn't panic if the HostRoot suspends; it should behave the same as if a component in the shell suspended. To fix this, I moved the check into an error-handling specific path, so it doesn't affect the Suspense case. We should consider refactoring this a bit more to fork the two paths earlier in the program flow. I didn't add any tests, because there's no (idiomatic) way to trigger this scenario currently, but I'm about to submit a fix for async actions that does.

If there are multiple updates inside an async action, they should all be rendered in the same batch, even if they are separate by an async operation (`await`). We currently implement this by suspending in the `useTransition` hook to block the update from committing until all possible updates have been scheduled by the action. The reason we did it this way is so you can "cancel" an action by navigating away from the UI that triggered it. The problem with that approach, though, is that even if you navigate away from the `useTransition` hook, the action may have updated shared parts of the UI that are still in the tree. So we may need to continue suspending even after the `useTransition` hook is deleted. In other words, the lifetime of an async action scope is longer than the lifetime of a particular `useTransition` hook. The solution is to suspend whenever _any_ update that is part of the async action scope is unwrapped during render. So, inside useState and useReducer. This fixes a related issue where an optimistic update is reverted before the async action has finished, because we were relying on the `useTransition` hook to prevent the optimistic update from finishing. This also prepares us to support async actions being passed to the non-hook form of `startTransition` (though this isn't implemented yet).

This implements the previous fix for class components and root-level updates, too. I put this in its own step because there are some extra changes related to avoiding a context stack mismatch.

react-sizebot · 2024-01-24T23:17:18Z

Comparing: 72411c4...f032dfe

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	+0.06%	176.24 kB	176.34 kB	+0.08%	54.88 kB	54.93 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.06%	178.34 kB	178.44 kB	+0.08%	55.53 kB	55.57 kB
facebook-www/ReactDOM-prod.classic.js	+0.15%	571.94 kB	572.79 kB	+0.24%	100.56 kB	100.80 kB
facebook-www/ReactDOM-prod.modern.js	+0.15%	555.70 kB	556.55 kB	+0.27%	97.62 kB	97.88 kB
test_utils/ReactAllWarnings.js	Deleted	67.55 kB	0.00 kB	Deleted	16.54 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
oss-stable-semver/react-art/cjs/react-art.production.js	+0.29%	594.91 kB	596.62 kB	+0.42%	132.95 kB	133.51 kB
oss-stable/react-art/cjs/react-art.production.js	+0.29%	594.94 kB	596.65 kB	+0.42%	132.98 kB	133.54 kB
oss-experimental/react-art/cjs/react-art.production.js	+0.28%	602.34 kB	604.06 kB	+0.46%	134.68 kB	135.29 kB
oss-stable-semver/react-test-renderer/cjs/react-test-renderer.production.js	+0.27%	607.49 kB	609.16 kB	+0.42%	135.95 kB	136.52 kB
oss-stable/react-test-renderer/cjs/react-test-renderer.production.js	+0.27%	607.52 kB	609.19 kB	+0.42%	135.98 kB	136.55 kB
oss-experimental/react-test-renderer/cjs/react-test-renderer.production.js	+0.27%	608.92 kB	610.59 kB	+0.42%	136.30 kB	136.87 kB
oss-stable-semver/react-reconciler/cjs/react-reconciler.production.js	+0.25%	686.83 kB	688.55 kB	+0.43%	149.87 kB	150.51 kB
oss-stable/react-reconciler/cjs/react-reconciler.production.js	+0.25%	686.86 kB	688.58 kB	+0.43%	149.90 kB	150.54 kB
oss-experimental/react-reconciler/cjs/react-reconciler.production.js	+0.25%	694.40 kB	696.12 kB	+0.43%	151.55 kB	152.21 kB
react-native/implementations/ReactFabric-dev.js	+0.24%	976.98 kB	979.36 kB	+0.37%	197.10 kB	197.83 kB
react-native/implementations/ReactNativeRenderer-dev.js	+0.24%	993.26 kB	995.65 kB	+0.36%	201.37 kB	202.10 kB
react-native/implementations/ReactFabric-dev.fb.js	+0.24%	1,007.15 kB	1,009.53 kB	+0.34%	202.21 kB	202.89 kB
oss-stable-semver/react-reconciler/cjs/react-reconciler.profiling.js	+0.24%	728.03 kB	729.75 kB	+0.40%	157.23 kB	157.87 kB
oss-stable/react-reconciler/cjs/react-reconciler.profiling.js	+0.24%	728.06 kB	729.78 kB	+0.41%	157.26 kB	157.90 kB
oss-experimental/react-reconciler/cjs/react-reconciler.profiling.js	+0.23%	735.60 kB	737.32 kB	+0.42%	158.94 kB	159.61 kB
react-native/implementations/ReactNativeRenderer-dev.fb.js	+0.23%	1,021.76 kB	1,024.14 kB	+0.34%	206.06 kB	206.76 kB
facebook-www/ReactART-dev.modern.js	+0.20%	1,026.80 kB	1,028.89 kB	+0.29%	202.31 kB	202.89 kB
oss-stable-semver/react-test-renderer/cjs/react-test-renderer.development.js	+0.20%	824.76 kB	826.42 kB	+0.28%	180.87 kB	181.38 kB
oss-stable/react-test-renderer/cjs/react-test-renderer.development.js	+0.20%	824.78 kB	826.44 kB	+0.28%	180.91 kB	181.42 kB
oss-experimental/react-test-renderer/cjs/react-test-renderer.development.js	+0.20%	826.04 kB	827.70 kB	+0.27%	181.17 kB	181.66 kB
facebook-www/ReactART-dev.classic.js	+0.20%	1,039.40 kB	1,041.48 kB	+0.30%	204.69 kB	205.31 kB
facebook-react-native/react-test-renderer/cjs/ReactTestRenderer-prod.js	=	314.05 kB	313.42 kB	=	55.55 kB	55.46 kB
facebook-react-native/react-test-renderer/cjs/ReactTestRenderer-profiling.js	=	330.02 kB	329.32 kB	=	57.98 kB	57.91 kB
react-native/implementations/ReactNativeRenderer-profiling.fb.js	=	365.35 kB	364.43 kB	=	64.22 kB	63.96 kB
react-native/implementations/ReactNativeRenderer-prod.fb.js	=	338.03 kB	337.17 kB	=	60.02 kB	59.74 kB
react-native/implementations/ReactNativeRenderer-prod.js	=	332.22 kB	331.36 kB	=	58.72 kB	58.45 kB
react-native/implementations/ReactFabric-profiling.fb.js	=	357.82 kB	356.89 kB	=	62.76 kB	62.56 kB
react-native/implementations/ReactNativeRenderer-profiling.js	=	351.72 kB	350.79 kB	=	61.88 kB	61.62 kB
react-native/implementations/ReactFabric-prod.fb.js	=	330.55 kB	329.65 kB	=	58.62 kB	58.39 kB
react-native/implementations/ReactFabric-profiling.js	=	342.54 kB	341.61 kB	=	60.13 kB	59.93 kB
react-native/implementations/ReactFabric-prod.js	=	323.06 kB	322.16 kB	=	57.00 kB	56.77 kB
test_utils/ReactAllWarnings.js	Deleted	67.55 kB	0.00 kB	Deleted	16.54 kB	0.00 kB

Generated by 🚫 dangerJS against f032dfe

If there are multiple updates inside an async action, they should all be rendered in the same batch, even if they are separate by an async operation (`await`). We currently implement this by suspending in the `useTransition` hook to block the update from committing until all possible updates have been scheduled by the action. The reason we did it this way is so you can "cancel" an action by navigating away from the UI that triggered it. The problem with that approach, though, is that even if you navigate away from the `useTransition` hook, the action may have updated shared parts of the UI that are still in the tree. So we may need to continue suspending even after the `useTransition` hook is deleted. In other words, the lifetime of an async action scope is longer than the lifetime of a particular `useTransition` hook. The solution is to suspend whenever _any_ update that is part of the async action scope is unwrapped during render. So, inside useState and useReducer. This fixes a related issue where an optimistic update is reverted before the async action has finished, because we were relying on the `useTransition` hook to prevent the optimistic update from finishing. This also prepares us to support async actions being passed to the non-hook form of `startTransition` (though this isn't implemented yet). DiffTrain build for [11c9fd0](11c9fd0)

If there are multiple updates inside an async action, they should all be rendered in the same batch, even if they are separate by an async operation (`await`). We currently implement this by suspending in the `useTransition` hook to block the update from committing until all possible updates have been scheduled by the action. The reason we did it this way is so you can "cancel" an action by navigating away from the UI that triggered it. The problem with that approach, though, is that even if you navigate away from the `useTransition` hook, the action may have updated shared parts of the UI that are still in the tree. So we may need to continue suspending even after the `useTransition` hook is deleted. In other words, the lifetime of an async action scope is longer than the lifetime of a particular `useTransition` hook. The solution is to suspend whenever _any_ update that is part of the async action scope is unwrapped during render. So, inside useState and useReducer. This fixes a related issue where an optimistic update is reverted before the async action has finished, because we were relying on the `useTransition` hook to prevent the optimistic update from finishing. This also prepares us to support async actions being passed to the non-hook form of `startTransition` (though this isn't implemented yet).

If there are multiple updates inside an async action, they should all be rendered in the same batch, even if they are separate by an async operation (`await`). We currently implement this by suspending in the `useTransition` hook to block the update from committing until all possible updates have been scheduled by the action. The reason we did it this way is so you can "cancel" an action by navigating away from the UI that triggered it. The problem with that approach, though, is that even if you navigate away from the `useTransition` hook, the action may have updated shared parts of the UI that are still in the tree. So we may need to continue suspending even after the `useTransition` hook is deleted. In other words, the lifetime of an async action scope is longer than the lifetime of a particular `useTransition` hook. The solution is to suspend whenever _any_ update that is part of the async action scope is unwrapped during render. So, inside useState and useReducer. This fixes a related issue where an optimistic update is reverted before the async action has finished, because we were relying on the `useTransition` hook to prevent the optimistic update from finishing. This also prepares us to support async actions being passed to the non-hook form of `startTransition` (though this isn't implemented yet). DiffTrain build for commit 11c9fd0.

acdlite added 3 commits January 24, 2024 17:45

Batch async updates to classes, roots too

f032dfe

This implements the previous fix for class components and root-level updates, too. I put this in its own step because there are some extra changes related to avoiding a context stack mismatch.

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

acdlite marked this pull request as ready for review January 24, 2024 23:14

sebmarkbage approved these changes Jan 24, 2024

View reviewed changes

acdlite merged commit 11c9fd0 into facebook:main Jan 25, 2024
36 checks passed

gnoff mentioned this pull request Feb 1, 2024

Update React from 60a927d04 to 2bc7d336a vercel/next.js#61522

Merged

ztanner mentioned this pull request Mar 19, 2024

(backport) Update React from 60a927d04 to 14898b6a9 vercel/next.js#63442

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Batch async actions even if useTransition is unmounted #28078

Batch async actions even if useTransition is unmounted #28078

acdlite commented Jan 24, 2024

react-sizebot commented Jan 24, 2024

Batch async actions even if useTransition is unmounted #28078

Batch async actions even if useTransition is unmounted #28078

Conversation

acdlite commented Jan 24, 2024

react-sizebot commented Jan 24, 2024

Critical size changes

Significant size changes