Check for store mutations before commit #22290
Merged
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
Because we already track `getSnapshot` and `value` on the store instance, we don't need to also track them as effect dependencies. And because the effect doesn't require any clean-up, we don't need to track a `destroy` function. So, we don't need to store any additional state for this effect. We can call `pushEffect` directly, and only during renders where something has changed. This saves some memory, but my main motivation is because I plan to use this same logic to schedule a pre-commit consistency check. (See the inline comments for more details.)
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 0fd195f...6ca37ef Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
acdlite
force-pushed
the
check-store-mutations-before-commit
branch
4 times, most recently
from
2008a36
to
fedf5e7
Compare
rickhanlonii
approved these changes
Sep 10, 2021
Lanes that are blocking (SyncLane, and DefaultLane inside a blocking- by-default root) are always blocking for a given root. Whereas expired lanes can expire while the render phase is already in progress. I want to check if a lane is blocking without checking whether it expired, so I split `shouldTimeSlice` into two separate functions. I'll use this in the next step.
When a store is read for the first time, or when `subscribe` or `getSnapshot` changes, during a concurrent render, we have to check at the end of the render phase whether the store was mutated by an concurrent event. In the userspace shim, we perform this check in a layout effect, and patch up any inconsistencies by scheduling another render + commit. However, even though we patch them up in the next render, the parent layout effects that fire in the original render will still observe an inconsistent tree. In the native implementation, we can instead check for inconsistencies right after the root is completed, before entering the commit phase. If we do detect a mutaiton, we can discard the tree and re-render before firing any effects. The re-render is synchronous to block further concurrent mutations (which is also what we do to recover from tearing bugs that result in an error). After the synchronous re-render, we can assume the tree the tree is consistent and continue with the normal algorithm for finishing a completed root (i.e. either suspend or commit). The result is that layout effects will always observe a consistent tree.
acdlite
force-pushed
the
check-store-mutations-before-commit
branch
from
fedf5e7
to
6ca37ef
Compare
salazarm
reviewed
Sep 13, 2021
facebook-github-bot
pushed a commit
to facebook/react-native
that referenced
this pull request
Sep 22, 2021
Summary: This sync includes the following changes: - **[f4ac680c7](facebook/react@f4ac680c7 )**: Fixed broken build script --unsafe-partial flag ([#22324](facebook/react#22324)) //<Brian Vaughn>// - **[67222f044](facebook/react@67222f044 )**: [Experiment] Warn if callback ref returns a function ([#22313](facebook/react#22313)) //<Dan Abramov>// - **[263cfa6ec](facebook/react@263cfa6ec )**: [Experimental] Add useInsertionEffect ([#21913](facebook/react#21913)) //<Ricky>// - **[806aaa2e2](facebook/react@806aaa2e2 )**: [useSES shim] Import prefixed native API ([#22310](facebook/react#22310)) //<Andrew Clark>// - **[fd5e01c2e](facebook/react@fd5e01c2e )**: [useSES/extra] Reuse old selection if possible ([#22307](facebook/react#22307)) //<Andrew Clark>// - **[33226fada](facebook/react@33226fada )**: Check for store mutations before commit ([#22290](facebook/react#22290)) //<Andrew Clark>// - **[86c7ca70a](facebook/react@86c7ca70a )**: Fix link ([#22296](facebook/react#22296)) //<Konstantin Popov>// - **[0fd195f29](facebook/react@0fd195f29 )**: update error message to include useLayoutEffect or useEffect on bad e… ([#22279](facebook/react#22279)) //<salazarm>// - **[8f96c6b2a](facebook/react@8f96c6b2a )**: [Bugfix] Prevent infinite update loop caused by a synchronous update in a passive effect ([#22277](facebook/react#22277)) //<Andrew Clark>// - **[4ce89a58d](facebook/react@4ce89a58d )**: Test bad useEffect return value with noop-renderer ([#22258](facebook/react#22258)) //<Sebastian Silbermann>// - **[a3fde2358](facebook/react@a3fde2358 )**: Detect subscriptions wrapped in startTransition ([#22271](facebook/react#22271)) //<salazarm>// Changelog: [General][Changed] - React Native sync for revisions 95d762e...e8feb11 jest_e2e[run_all_tests] Reviewed By: rickhanlonii Differential Revision: D30966369 fbshipit-source-id: 6c88e591005deb1fd93493628ef4695add49186c
zhengjitf
pushed a commit
to zhengjitf/react
that referenced
this pull request
Apr 15, 2022
* [useSyncExternalStore] Remove extra hook object Because we already track `getSnapshot` and `value` on the store instance, we don't need to also track them as effect dependencies. And because the effect doesn't require any clean-up, we don't need to track a `destroy` function. So, we don't need to store any additional state for this effect. We can call `pushEffect` directly, and only during renders where something has changed. This saves some memory, but my main motivation is because I plan to use this same logic to schedule a pre-commit consistency check. (See the inline comments for more details.) * Split shouldTimeSlice into two separate functions Lanes that are blocking (SyncLane, and DefaultLane inside a blocking- by-default root) are always blocking for a given root. Whereas expired lanes can expire while the render phase is already in progress. I want to check if a lane is blocking without checking whether it expired, so I split `shouldTimeSlice` into two separate functions. I'll use this in the next step. * Check for store mutations before commit When a store is read for the first time, or when `subscribe` or `getSnapshot` changes, during a concurrent render, we have to check at the end of the render phase whether the store was mutated by an concurrent event. In the userspace shim, we perform this check in a layout effect, and patch up any inconsistencies by scheduling another render + commit. However, even though we patch them up in the next render, the parent layout effects that fire in the original render will still observe an inconsistent tree. In the native implementation, we can instead check for inconsistencies right after the root is completed, before entering the commit phase. If we do detect a mutaiton, we can discard the tree and re-render before firing any effects. The re-render is synchronous to block further concurrent mutations (which is also what we do to recover from tearing bugs that result in an error). After the synchronous re-render, we can assume the tree the tree is consistent and continue with the normal algorithm for finishing a completed root (i.e. either suspend or commit). The result is that layout effects will always observe a consistent tree.
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.
When a store is read for the first time, or when
subscribeorgetSnapshotchanges, during a concurrent render, we have to check at the end of the render phase whether the store was mutated by a concurrent event.In the userspace shim, we perform this check in a layout effect, and patch up any inconsistencies by scheduling another render + commit. However, even though we patch them up in the next render, the parent layout effects that fire in the original render will still observe an inconsistent tree.
In the native implementation, we can instead check for inconsistencies right after the root is completed, before entering the commit phase. If we do detect a mutation, we can discard the tree and re-render before firing any effects. The re-render is synchronous to block further concurrent mutations (which is also what we do to recover from tearing bugs that result in an error). After the synchronous re-render, we can assume the tree the tree is consistent and continue with the normal algorithm for finishing a completed root (i.e. either suspend or commit).
The result is that layout effects will always observe a consistent tree.