## Summary
Migrate internal `Libraries/` import subpaths from `react-native` to the
incoming dedicated entry points in React Native 0.87.
**Motivation**
See [**RFC0894: Removing deep imports from
react-native**](https://github.com/react-native-community/discussions-and-proposals/pull/894)
**Changes**
The `react-private-interface` entry point has been created explicitly
for the private contract between React ↔ React Native, and is 1:1 with
the previous `ReactNativePrivateInterface` module.
Both of the below `Libraries/` paths still exist, but are deprecated —
this is a lagging migration that will enable cleanup in a future RN
version.
- `react-native/Libraries/Core/InitializeCore` →
`react-native/setup-env`
[react/react-native#57475](https://github.com/react/react-native/pull/57475)
- `react-native/Libraries/ReactPrivate/ReactNativePrivateInterface` →
`react-native/react-private-interface`
[react/react-native#57495](https://github.com/react/react-native/pull/57495)
## Test Plan
Flow
When a Fragment has no children, React would consider scrolling to
siblings first and then to parents. However, React only considered
`HostComponent` for the siblings.
Since we already have a heuristic for scrolling to `HostText`, we can
reuse that same heuristic.
---------
Co-authored-by: Hanzo Dev <[email protected]>
## Summary
Microtasks are enabled by default in RN already, so there's no need to
gate their use in Fabric atm.
## How did you test this change?
Existing tests. Tested e2e at Meta.
## Summary
This diff bumps a few hermes-parser related dependencies so that it can
consume modern Flow syntax. In addition, it makes targeted changes to
two files that will be synced to react-native so that we can enforce we
only use modern flow syntax in react-native.
## How did you test this change?
flow
## Summary
Mostly changing the casting syntax from `(x: Y)` to `x as Y`, as the old
syntax was deprecated and always causing an error in Flow
## How did you test this change?
`yarn flow-ci`
## Summary
Notable changes:
- Only $FlowFixMe, $FlowExpectedError suppression comments are supported
- All suppression comments need error code
- A lot of new invalid-compare and constant-condition errors suppressed.
These errors reveal potential logical bugs
## How did you test this change?
`yarn flow-ci`
## Summary
- Adds a null check before calling
`fabricSuspendOnActiveViewTransition()` in the Fabric renderer's
`suspendOnActiveViewTransition` export
- Prevents crashes on hosts where `nativeFabricUIManager` does not yet
implement `suspendOnActiveViewTransition`
## Test plan
- Verified the change compiles correctly
- Hosts with `suspendOnActiveViewTransition` implemented continue to
work as before
- Hosts without `suspendOnActiveViewTransition` no longer crash when
view transitions are active
## Summary
- Wires up the native `fabricCreateViewTransitionInstance` call in
`createViewTransitionInstance` which will create a ShadowNode for old
pseudo element
- Extracts tag allocation logic into a shared `allocateTag()` function
exported from `ReactFiberConfigFabric`
- Imports `allocateTag` in `ReactFiberConfigFabricWithViewTransition`
- Reuses `allocateTag()` in `createInstance` and `createTextInstance`
instead of inline tag incrementing
- Wires up native `fabricSuspendOnActiveViewTransition` call in
`suspendOnActiveViewTransition` which suspends another view transition
when the previous one is not yet finished
## Test plan
- Existing Fabric renderer tests should continue to pass
- ViewTransition instance creation now properly allocates a tag and
calls the native module
## Summary
- Imports `startViewTransitionReadyFinished` from
`nativeFabricUIManager` in `ReactFiberConfigFabricWithViewTransition`
- Calls `fabricStartViewTransitionReadyFinished()` when the view
transition `ready` promise resolves
This is not a config function, but it's helpful to have it notify fabric
ViewTransition runtime when ready callback is done. Right now we're
testing animation kicked off from view transition event handlers, this
is signal to know when animations that belong to a transition have all
started.
## Test plan
- Existing Fabric renderer tests should continue to pass
- View transition ready callback now notifies the native module when
finished
## Summary
We found a bug in the logic in
https://github.com/facebook/react/pull/36253 and we realized it's very
inconvenient to iterate on the implementation when it's in this
repository, as we're forced to then synchronize it to RN to test
changes.
This moves the entire implementation to RN for simplicity and also to
simplify some clean ups in the future (like removing `top` prefixes from
native event types).
## How did you test this change?
The changes are gated. Will test e2e in RN.
## Summary
Set up the experiment to migrate event dispatching in the React Native
renderer to be based on the native EventTarget API.
Behind the `enableNativeEventTargetEventDispatching` flag, events are
dispatched through `dispatchTrustedEvent` instead of the legacy plugin
system.
Regular event handler props are NOT registered via addEventListener at
commit time. Instead, a hook on EventTarget
(`EVENT_TARGET_GET_DECLARATIVE_LISTENER_KEY`) extracts handlers from
`canonical.currentProps` at dispatch time, shifting cost from every
render to only when events fire. The hook is overridden in
ReactNativeElement to look up the prop name via a reverse mapping from
event names (built lazily from the view config registry).
Responder events bypass EventTarget entirely. `negotiateResponder` walks
the fiber tree directly (capture then bubble phase), calling handlers
from `canonical.currentProps` and checking return values inline.
Lifecycle events (`responderGrant`, `responderMove`, etc.) call handlers
directly from props and inspect return values — `onResponderGrant`
returning `true` blocks native responder,
`onResponderTerminationRequest` returning `false` refuses termination.
This eliminates all commit-time cost for responder events (no wrappers,
no addEventListener, no `responderWrappers` on canonical).
## How did you test this change?
Flow
Tested e2e in RN using Fantom tests (that will land after this).
## Summary
Enables Basic View Transition support for React Native Fabric renderer.
**Implemented:**
- Added FabricUIManager bindings for view transition methods:
`applyViewTransitionName`, `startViewTransition`
- Implemented `startViewTransition` with proper callback orchestration
(mutation → layout → afterMutation → spawnedWork → passive)
- Added fallback behavior that flushes work synchronously when Fabric's
`startViewTransition` returns null (e.g., when the ViewTransition
ReactNativeFeatureFlag is not enabled)
- Added Flow type declarations for new FabricUIManager methods
- Stubbed with `__DEV__` warnings for all the other view transition
config functions that are not yet implemented
This allows React Native apps using Fabric to leverage the View
Transition API for coordinated animations during state transitions, with
graceful degradation when the native side doesn't support it.
Below are diagrams of proposed architecture in fabric, and observation
of what/when config functions get called during a basic shared
transition example
<img width="2290" height="1529" alt="Untitled-2026-03-19-1240"
src="https://github.com/user-attachments/assets/192c9169-bc25-449c-a33b-dfec67179e7f"
/>
## How did you test this change?
- [x] `yarn flow fabric` - Flow type checks pass
- [x] `yarn lint` - Lint checks pass
- [x] Manually tested in Android catalyst app with
`enableViewTransition` and `enableViewTransitionForPersistenceMode `in
`ReactFeatureFlags.test-renderer.native-fb.js` and View Transition
enabled via ReactNativeFeatureFlag
- [x] Verified in the minified `ReactFabric-dev.fb.js` that the 'shim'
config functions are not included
- [x] Verified fallback behavior logs warning in `__DEV__` and flushes
work synchronously when ViewTransition flag isn't enabled in Fabric
https://github.com/facebook/react/pull/34935 Introduced
`unstable_reactFragments` handle on DOM nodes to enable caching of
Observers.
This has been tested in production and is stable so it can be rolled out
with the Fragment Refs feature.
## Summary
This defines the same fiber configuration for RN as used in DOM, so we
can expose event timing information in the React scheduler tracks in
performance traces.
This was unblocked by #35913 and #35912.
## How did you test this change?
Manually compiled the renderer and tested e2e in FB infra:
<img width="1217" height="161" alt="Screenshot 2026-03-03 at 10 10 44"
src="https://github.com/user-attachments/assets/6ca1512e-dcaf-49cf-8da9-1c6ae554733a"
/>
## Summary
This fixes the semantics of the `timeStamp` property of events in React
Native.
Currently, most events just assign `Date.now()` (at the time of creating
the event object in JavaScript) as the `timeStamp` property. This is a
divergence with Web and most native platforms, that use a monotonic
timestamp for the value (on Web, the same timestamp provided by
`performance.now()`).
Additionally, many native events specify a timestamp in the event data
object as `timestamp` and gets ignored by the logic in JS as it only
looks at properties named `timeStamp` specifically (camel case).
This PR fixes both issues by:
1. Using `performance.now()` instead of `Date.now()` by default (if
available).
2. Checking for a `timestamp` property before falling back to the
default (apart from `timeStamp`).
## How did you test this change?
Added unit tests for verify the new behavior.
## Summary
Add "RCTSelectableText" to the list of component names recognized as
being inside a text element, alongside "RCTText".
React Native's new text stack, tries to optimize and allows
differentiating between a custom TextView, with lower level control,
that can reuse the work performed during Fabric/Yoga layout, and a
native TextView, used for fidelity. On Android at least, the only place
we've needed native TextView for fidelity/native UX has been support for
`selectable` text, which has many unique UI interactions.
## How did you test this change?
When I patch this in, alongside
https://github.com/facebook/react-native/pull/55552, we no longer see
warnings when we render text inside of RCTSelectableText component.
---------
Co-authored-by: Eli White <[email protected]>
Follow up to https://github.com/facebook/react/pull/35630
We don't currently have any operations that depend on the updating of
text nodes added or removed after Fragment mount. But for the sake of
completeness and extending the ability to any other host configs, this
change calls `commitNewChildToFragmentInstance` and
`deleteChildFromFragmentInstance` on HostText fibers.
Both DOM and Fabric configs early return because we cannot attach event
listeners or observers to text. In the future, there could be some
stateful Fragment feature that uses text that could extend this.
Stacked on #35556 and #35559.
Given that we don't automatically clean up all view transition
animations since #35337 and browsers are buggy, it's important that you
clean up any `Animation` started manually from the events. However,
there was no clean up function for when the View Transition is forced to
stop. This also makes it harder to clean up custom timers etc too.
This lets you return a clean up function from all the events on
`<ViewTransition>`.
This PR adds a `unstable_reactFragments?: Set<FragmentInstance>`
property to DOM nodes that belong to a Fragment with a ref (top level
host components). This allows you to access a FragmentInstance from a
DOM node.
This is flagged behind `enableFragmentRefsInstanceHandles`.
The primary use case to unblock is reusing IntersectionObserver
instances. A fairly common practice is to cache and reuse
IntersectionObservers that share the same config, with a map of
node->callbacks to run for each entry in the IO callback. Currently this
is not possible with Fragment Ref `observeUsing` because the key in the
cache would have to be the `FragmentInstance` and you can't find it
without a handle from the node. This works now by accessing
`entry.target.fragments`.
This also opens up possibilities to use `FragmentInstance` operations in
other places, such as events. We can do
`event.target.unstable_reactFragments`, then access
`fragmentInstance.getClientRects` for example. In a future PR, we can
assign an event's `currentTarget` as the Fragment Ref for a more direct
handle when the event has been dispatched by the Fragment itself.
The first commit here implemented a handle only on observed elements.
This is awkward because there isn't a good way to document or expose
this temporary property. `element.fragments` is closer to what we would
expect from a DOM API if a standard was implemented here. And by
assigning it to all top-level nodes of a Fragment, it can be used beyond
the cached IntersectionObserver callback.
One tradeoff here is adding extra work during the creation of
FragmentInstances as well as keeping track of adding/removing nodes.
Previously we only track the Fiber on creation but here we add a
traversal which could apply to a large set of top-level host children.
The `element.unstable_reactFragments` Set can also be randomly ordered.
Now that RN is only on the New Architecture, we can stop stop syncing
the legacy React Native renderers.
In this diff, I just stop syncing them. In a follow up I'll delete the
code for them so only Fabric is left.
This will also allow us to remove the `enableLegacyMode` feature flag.
Stacked on #34544
We only have getBoundingClientRect available from RN currently. This
should work as a substitute for this case because the equivalent of
multi-rect elements in RN is a nested Text component. We only include
the rects of top-level host components here so we can assume that
calling getBoundingClientRect on each child is the same result.
Tested in react-native with Fantom.
Stacked on #34533 for root fragment handling
This is the same approach as DOM, where we call getRootNode on the
parent.
Tests are in react-native using Fantom.
## Summary
Experimentation has completed for this at Meta and we've observed
positive impact on key React Native surfaces.
## How did you test this change?
yarn flow fabric
Stacked on #34546.
Same as #34538 but for gestures.
Includes various fixes.
This shows how it ends with a Transition when you release in the
committed state. Note how the Animation of the Gesture continues until
the Transition is done so that the handoff is seamless.
<img width="853" height="134" alt="Screenshot 2025-09-20 at 7 37 29 PM"
src="https://github.com/user-attachments/assets/6192a033-4bec-43b9-884b-77e3a6f00da6"
/>
The root instance doesn't have a canonical property so we were not
returning a public instance that we can call compareDocumentPosition on
when a Fragment had no other host parent in Fabric. In this case we need
to get the ReactNativeElement from the ReactNativeDocument.
I've also added test coverage for this case in DOM for consistency,
though it was already working there because we use DOM elements as root.
This same test will be copied to RN using Fantom.
Stacked on #34522.
<img width="1025" height="200" alt="Screenshot 2025-09-19 at 6 37 28 PM"
src="https://github.com/user-attachments/assets/f25900f6-6503-48b1-876d-bd6697a29c6f"
/>
We already cover the time between "Starting Animation" and "Remaining
Effects" as "Animating". However, if the effects are forced then we can
still be animating after that. This fills in that gap.
This also fills in the gap if another render starts before the animation
finishes on the same track. It'll mark the blank space between the
previous render finishing and the next render starting as "Animating".
This should correspond roughly to the native "Animations" track.
Stacked on #34511.
We currently log all Suspended Commit as "Suspended on Images or CSS"
but it can really be other reasons too now. Like waiting on the previous
View Transition. This allows the host config configure this reason.
Now when one animation starts before another one finishes we log that as
"Waiting for the previous Animation".
<img width="592" height="257" alt="Screenshot 2025-09-17 at 11 53 45 PM"
src="https://github.com/user-attachments/assets/817af8b5-37ae-46d8-bfd1-cd3fc637f3f3"
/>
Stacked on #34510.
The "Commit" phase for a View Transition starts before the snapshot
phase (before mutation) and then stretches into the async gap of
`startViewTransition`, encompasses the mutation phase inside of its
update callback and finally the layout phase.
However, between the mutation phase and the layout phase we may suspend
the start of the view transition on fonts and/or images. In that case we
now split the Commit phase into first one before we suspend and then we
log "Waiting for Images and/or Fonts" and then another Commit phase
around the layout effects.
<img width="897" height="119" alt="Screenshot 2025-09-16 at 11 37 26 PM"
src="https://github.com/user-attachments/assets/0fe21388-bb48-4456-a594-62227d12d9b7"
/>
Stacked on #34481.
We currently track the suspended state temporarily with a global which
is safe as long as we always read it during a sync pass. However, we
sometimes read it in closures and then we have to be carefully to pass
the right one since it's possible another commit on a different root has
started at that point. This avoids this footgun.
Another reason to do this is that I want to read it in
`startViewTransition` which is in an async gap after which point it's no
longer safe. So I have to pass that through the `commitRoot` bound
function.
Currently suspensey images doesn't account for how long we've already
been waiting. This means that you can for example wait for 300ms for the
throttle + 500ms for the images. If a Transition takes a while to
complete you can also wait that time + an additional 500ms for the
images.
This tracks the start time of a Transition so that we can count the
timeout starting from when the user interacted or when the last fallback
committed (which is where the 300ms throttle is computed from). Creating
a single timeline.
This also moves the timeout to a central place which I'll use in a
follow up.
This update was a bit more involved.
- `React$Component` was removed, I replaced it with Flow component
types.
- Flow removed shipping the standard library. This adds the environment
libraries back from `flow-typed` which seemed to have changed slightly
(probably got more precise and less `any`s). Suppresses some new type
errors.
After an easy couple version with #34252, this version is less flexible
(and safer) on inferring exported types mainly.
We require to annotate some exported types to differentiate between
`boolean` and literal `true` types, etc.
Stacked on https://github.com/facebook/react/pull/34069
Same basic semantics as the react-dom for determining document position
of a Fragment compared to a given node. It's simpler here because we
don't have to deal with inserted nodes or portals. So we can skip a
bunch of the validation logic.
The logic for handling empty fragments is the same so I've split out
`compareDocumentPositionForEmptyFragment` into a shared module. There
doesn't seem to be a great place to put shared DOM logic between Fabric
and DOM configs at the moment. There may be more of this coming as we
add more and more DOM APIs to RN.
For testing I've written Fantom tests internally which pass the basic
cases on this build. The renderer we have configured for Fabric tests in
the repo doesn't support the Element APIs we need like
`compareDocumentPosition`.
## Summary
ReactNativeAttributePayloadFabric was synced to react-native in
https://github.com/facebook/react-native/commit/0e42d33cbcfadcf5d787108da785d56a83d07a9f.
We should now consume these methods from the
ReactNativePrivateInterface.
Moving these methods to the React Native repo gives us more flexibility
to experiment with new techniques for bridging and diffing props
payloads.
I did have to leave some stub implementations for existing unit tests,
but moved all detailed tests to the React Native repo.
## How did you test this change?
* `yarn prettier`
* `yarn test ReactFabric-test`
