Fix useMutableSource tearing bug #18912
Conversation
If a source is mutated after initial read but before subscription is set up, it should still entangle all pending mutations even if snapshot of new subscription happens to match. Test case illustrates how not doing this can lead to tearing.
Fix is to move the entanglement call outside of the block that checks if the snapshot has changed.
facebook-github-bot added React Core Team 
| This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 43ce30b:
|
| This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit c3c4c3f:
|
bvaughn left a comment
bvaughn left a comment There was a problem hiding this comment.
This looks like an improvement!
Correct me if I'm wrong though, but this tearing case would still be possible for any source where version is not an auto-incremented value (e.g. window.location, maybe even Redux stores).
| // There is no mechanism currently to associate these updates though, | ||
| // so for now we fall back to synchronously flushing all pending updates. | ||
| // TODO: Improve this later. | ||
| markRootExpiredAtTime(root, getLastPendingExpirationTime(root)); |
There was a problem hiding this comment.
Ah, that's unfortunate. Even more deopts in old mode now.
Yeah sounds right to me. Something to think about. |
4 participants
If a source is mutated after initial read but before subscription is set up, it should still entangle all pending mutations even if snapshot of new subscription happens to match.
Test case illustrates how not doing this can lead to tearing.
The fix is to move the entanglement call outside of the block that checks if the snapshot has changed.