Fix: Optimistic update does not get reset #27453

acdlite · 2023-10-03T18:28:32Z

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update.

Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to hook.memoizedState. However, when implementing optimistic state rebasing, I incorrectly reset hook.memoizedState to the incoming base state, even though I only needed to reset hook.baseState. This was just a mistake on my part.

This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render.

I fixed the bug and added a regression test.

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update. Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to `hook.memoizedState`. However, when implementing optimistic state rebasing, I incorrectly reset `hook.memoizedState` to the incoming base state, even though I only needed to reset `hook.baseState`. This was just a mistake on my part. This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render. I fixed the bug and added a regression test.

react-sizebot · 2023-10-03T18:34:10Z

Comparing: db69f95...e6a8f50

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	=	167.58 kB	167.58 kB	=	52.14 kB	52.14 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	176.25 kB	176.22 kB	=	54.84 kB	54.84 kB
facebook-www/ReactDOM-prod.classic.js	=	564.43 kB	564.39 kB	=	99.37 kB	99.37 kB
facebook-www/ReactDOM-prod.modern.js	=	548.16 kB	548.12 kB	=	96.45 kB	96.45 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against e6a8f50

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update. Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to `hook.memoizedState`. However, when implementing optimistic state rebasing, I incorrectly reset `hook.memoizedState` to the incoming base state, even though I only needed to reset `hook.baseState`. This was just a mistake on my part. This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render. I fixed the bug and added a regression test. DiffTrain build for [85c2b51](85c2b51)

### Based on #27453 If optimistic state is updated, and there's no startTransition on the stack, there are two likely scenarios. One possibility is that the optimistic update is triggered by a regular event handler (e.g. `onSubmit`) instead of an action. This is a mistake and we will warn. The other possibility is the optimistic update is inside an async action, but after an `await`. In this case, we can make it "just work" by associating the optimistic update with the pending async action. Technically it's possible that the optimistic update is unrelated to the pending action, but we don't have a way of knowing this for sure because browsers currently do not provide a way to track async scope. (The AsyncContext proposal, if it lands, will solve this in the future.) However, this is no different than the problem of unrelated transitions being grouped together — it's not wrong per se, but it's not ideal. Once AsyncContext starts landing in browsers, we will provide better warnings in development for these cases.

### Based on #27453 If optimistic state is updated, and there's no startTransition on the stack, there are two likely scenarios. One possibility is that the optimistic update is triggered by a regular event handler (e.g. `onSubmit`) instead of an action. This is a mistake and we will warn. The other possibility is the optimistic update is inside an async action, but after an `await`. In this case, we can make it "just work" by associating the optimistic update with the pending async action. Technically it's possible that the optimistic update is unrelated to the pending action, but we don't have a way of knowing this for sure because browsers currently do not provide a way to track async scope. (The AsyncContext proposal, if it lands, will solve this in the future.) However, this is no different than the problem of unrelated transitions being grouped together — it's not wrong per se, but it's not ideal. Once AsyncContext starts landing in browsers, we will provide better warnings in development for these cases. DiffTrain build for [88d56b8](88d56b8)

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update. Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to `hook.memoizedState`. However, when implementing optimistic state rebasing, I incorrectly reset `hook.memoizedState` to the incoming base state, even though I only needed to reset `hook.baseState`. This was just a mistake on my part. This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render. I fixed the bug and added a regression test.

…#27454) ### Based on facebook#27453 If optimistic state is updated, and there's no startTransition on the stack, there are two likely scenarios. One possibility is that the optimistic update is triggered by a regular event handler (e.g. `onSubmit`) instead of an action. This is a mistake and we will warn. The other possibility is the optimistic update is inside an async action, but after an `await`. In this case, we can make it "just work" by associating the optimistic update with the pending async action. Technically it's possible that the optimistic update is unrelated to the pending action, but we don't have a way of knowing this for sure because browsers currently do not provide a way to track async scope. (The AsyncContext proposal, if it lands, will solve this in the future.) However, this is no different than the problem of unrelated transitions being grouped together — it's not wrong per se, but it's not ideal. Once AsyncContext starts landing in browsers, we will provide better warnings in development for these cases.

…experimental prefix for server action APIs (#56809) The latest React canary builds have a few changes that need to be adopted for compatability. 1. the `useFormState` and `useFormStatus` hooks in `react-dom` and the `formData` opiont in `react-dom/server` are no longer prefixed with `experimental_` 2. server content (an undocumented React feature) has been removed. Next only had trivial intenral use of this API and did not expose a coherent feature to Next users (no ability to seed context on refetches). It is still possible that some users used the React server context APIs which is why this should go into Next 14. ### React upstream changes - facebook/react#27513 - facebook/react#27514 - facebook/react#27511 - facebook/react#27508 - facebook/react#27502 - facebook/react#27474 - facebook/react#26789 - facebook/react#27500 - facebook/react#27488 - facebook/react#27458 - facebook/react#27471 - facebook/react#27470 - facebook/react#27464 - facebook/react#27456 - facebook/react#27462 - facebook/react#27461 - facebook/react#27460 - facebook/react#27459 - facebook/react#27454 - facebook/react#27457 - facebook/react#27453 - facebook/react#27401 - facebook/react#27443 - facebook/react#27445 - facebook/react#27364 - facebook/react#27440 - facebook/react#27436 --------- Co-authored-by: Zack Tanner <zacktanner@gmail.com> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Jiachi Liu <inbox@huozhi.im>

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update. Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to `hook.memoizedState`. However, when implementing optimistic state rebasing, I incorrectly reset `hook.memoizedState` to the incoming base state, even though I only needed to reset `hook.baseState`. This was just a mistake on my part. This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render. I fixed the bug and added a regression test.

…#27454) ### Based on facebook#27453 If optimistic state is updated, and there's no startTransition on the stack, there are two likely scenarios. One possibility is that the optimistic update is triggered by a regular event handler (e.g. `onSubmit`) instead of an action. This is a mistake and we will warn. The other possibility is the optimistic update is inside an async action, but after an `await`. In this case, we can make it "just work" by associating the optimistic update with the pending async action. Technically it's possible that the optimistic update is unrelated to the pending action, but we don't have a way of knowing this for sure because browsers currently do not provide a way to track async scope. (The AsyncContext proposal, if it lands, will solve this in the future.) However, this is no different than the problem of unrelated transitions being grouped together — it's not wrong per se, but it's not ideal. Once AsyncContext starts landing in browsers, we will provide better warnings in development for these cases.

I found a bug where if an optimistic update causes a component to rerender, and there are no other state updates during that render, React bails out without applying the update. Whenever a hook detects a change, we must mark the component as dirty to prevent a bailout. We check for changes by comparing the new state to `hook.memoizedState`. However, when implementing optimistic state rebasing, I incorrectly reset `hook.memoizedState` to the incoming base state, even though I only needed to reset `hook.baseState`. This was just a mistake on my part. This wasn't caught by the existing tests because usually when the optimistic state changes, there's also some other state that marks the component as dirty in the same render. I fixed the bug and added a regression test. DiffTrain build for commit 85c2b51.

### Based on #27453 If optimistic state is updated, and there's no startTransition on the stack, there are two likely scenarios. One possibility is that the optimistic update is triggered by a regular event handler (e.g. `onSubmit`) instead of an action. This is a mistake and we will warn. The other possibility is the optimistic update is inside an async action, but after an `await`. In this case, we can make it "just work" by associating the optimistic update with the pending async action. Technically it's possible that the optimistic update is unrelated to the pending action, but we don't have a way of knowing this for sure because browsers currently do not provide a way to track async scope. (The AsyncContext proposal, if it lands, will solve this in the future.) However, this is no different than the problem of unrelated transitions being grouped together — it's not wrong per se, but it's not ideal. Once AsyncContext starts landing in browsers, we will provide better warnings in development for these cases. DiffTrain build for commit 88d56b8.

facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Oct 3, 2023

acdlite mentioned this pull request Oct 3, 2023

Warn if optimistic state is updated outside of a transition #27454

Merged

acdlite requested review from sophiebits and sebmarkbage October 3, 2023 18:47

sebmarkbage approved these changes Oct 3, 2023

View reviewed changes

acdlite merged commit 85c2b51 into facebook:main Oct 3, 2023
36 checks passed

sophiebits mentioned this pull request Oct 3, 2023

Add <form> Component reference documentation reactjs/react.dev#6312

Merged

gnoff mentioned this pull request Oct 4, 2023

Update React from d900fadbf to 6f1324395 vercel/next.js#56220

Closed

shuding mentioned this pull request Oct 11, 2023

Upgrade vendored React vercel/next.js#56705

Closed

gnoff mentioned this pull request Oct 13, 2023

Update React from d900fadbf to 09fbee89d. Removes server context and experimental prefix for server action APIs vercel/next.js#56809

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix: Optimistic update does not get reset #27453

Fix: Optimistic update does not get reset #27453

acdlite commented Oct 3, 2023

react-sizebot commented Oct 3, 2023

Fix: Optimistic update does not get reset #27453

Fix: Optimistic update does not get reset #27453

Conversation

acdlite commented Oct 3, 2023

react-sizebot commented Oct 3, 2023

Critical size changes

Significant size changes