Implement UI consistency mechanism for JS thread by rubennorte · Pull Request #43581 · facebook/react-native

rubennorte · 2024-03-20T17:55:15Z

Summary:
Changelog: [internal]

This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.

Context

Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:

useEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  // do something
  const newRect = ref.current.getBoundingClientRect();
  // `rect` and `newRect` should always be the same
}, []);

This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.

You can find additional context about this in the RFC for DOM Traversal & Layout APIs in RN.

This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for IntersectionObserver) relies on the information in the shadow tree, but this is updated asynchronously on scroll.

There are 2 potential solutions for that problem:

Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
(Preferred/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1. When we start a new JS task.
2. When we commit a new tree from React (JS).

Changes

This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.

More specifically:

Creates ShadowTreeRevisionProvider as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like measure, etc.).
Creates ShadowTreeRevisionConsistencyManager as an abstract class to handle what trees are visible (with a lockRevision and unlockRevision to be called from RuntimeScheduler at the beginning and end of each JS task).
Creates 2 different implementations of these abstractions:
- One that preserves the current behavior (LatestShadowTreeRevisionProvider, which just returns the last committed revision at the time of the call).
- One that locks revisions lazily (the first time they're accessed) (LazyShadowTreeRevisionConsistencyManager).

Differential Revision: D55024832

facebook-github-bot · 2024-03-20T17:55:39Z