Fabric Native Components

WHY IT EXISTS The legacy architecture serialized every UI update across an asynchronous JSON bridge between JavaScript and native. That introduced latency, batching delays, and visible tearing during gestures or rapid updates. Fabric was built to remove the bridge as the hot path and give React Native a modern renderer aligned with React's concurrent features.

THE MENTAL MODEL Think of a Fabric Native Component as a typed contract. You declare props and events in a JS or TS spec file, codegen generates C++ and platform interfaces, and you implement an actual platform view behind that contract. React owns a shadow tree describing the UI; Fabric reconciles it and mounts real views.

HOW IT WORKS JSI lets JavaScript hold direct references to C++ host objects, so calls happen synchronously without serialization. The shadow tree is computed in C++ using Yoga for layout, shared across iOS and Android. When React commits an update, Fabric diffs the new tree, performs view flattening to drop unnecessary container views, then mounts changes on the main thread. Components can expose imperative commands and support measured layout synchronously.

WHEN IT MATTERS It matters for animation-heavy screens, long lists, gesture-driven UIs, and apps wrapping complex platform widgets like maps or video players. Synchronous layout reading also fixes classes of flicker bugs that were awkward under the old bridge.

ONE CONCRETE EXAMPLE Suppose you wrap a native color picker view. You write a spec named MyColorPickerNativeComponent declaring a color string prop and an onColorChange event. After codegen, you implement the Android view in Kotlin and the iOS view in Objective-C or Swift, returning the platform view and wiring prop setters. JavaScript imports the generated component and renders it like any other element, with prop changes applied synchronously through Fabric rather than queued over a bridge.