TurboModules solve the problem of calling native functions from JavaScript quickly. They don't solve a different, equally common problem: rendering a genuinely native view — a map, a video player, a camera preview, a charting library's canvas — inside a React Native screen, positioned and styled by the same Flexbox layout everything else uses, updating its native properties as React re-renders. That is the job of a Fabric native component, the New Architecture's replacement for the legacy `ViewManager` pattern.
The legacy approach worked, but the layout and property-update path went through the same asynchronous, serializing bridge as everything else: a prop change computed by React had to be serialized, queued, crossed to native, and applied to the actual native view, with the same per-crossing cost TurboModules removed for method calls. Fabric restructures this specifically for views: layout is computed on a background thread against a C++ shadow tree, and committing that tree to the actual native view hierarchy happens through a more direct path than the legacy bridge's message queue, which matters most for exactly the kind of component that tends to need custom native views in the first place — something animating, scrolling, or updating at high frequency.
This lesson builds a Fabric native component end to end: the same codegen-first discipline as a TurboModule, but for a view instead of a module, tracing how a `<MyMapView />` in JSX becomes an actual `MKMapView` or Android `MapView` on screen, laid out by Yoga, and kept in sync as props change.
Analogy🏏Cricket
🏏 Think of it like cricket: A ground's video-replay screen and its physical scoreboard are both driven by the same match state, but the screen is a genuinely different piece of technology from a hand-cranked numbers board — it has its own refresh cycle, its own rendering pipeline, its own hardware. Getting a boundary announcement to appear correctly on that screen is not the same problem as getting the correct total onto the manual scoreboard; the screen needs its own dedicated feed, built and tested against its own display technology, even though both are ultimately showing "what happened in the match" to the crowd. A ground that tried to drive the video screen through the same slow, manual process used for the numbers board would have a screen that visibly lags behind live play, which is unacceptable for a big-screen replay the crowd expects to be near-instant. A Fabric native component is exactly this dedicated feed for a genuinely different piece of technology — an actual native view, not a React-rendered `<div>`-equivalent — and it needs its own build, layout, and update path suited to that technology, the same way the video screen needs its own feed suited to displaying video rather than repurposing the numbers board's mechanism. The insight is that a fundamentally different kind of display, embedded inside the same overall show, deserves a rendering path built for what it actually is, not a repurposed version of the path built for something else.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.