Fabric scheduling: JS, layout and UI are different budgets
Prerequisites: 02-fabric-trees
Common scheduling path
Frame diagnosis
Mental model verified
The common path renders on the JS thread, but a high-priority event can lead to synchronous render work on UI. Commit/layout may occur elsewhere, while mount applies host-view mutations on UI. Immutable shadow structures enable thread-safe scheduling.
[S05] [S06]Worked diagnosis synthesis
A scroll janks even when JS appears mostly idle. Inspect UI-thread work, layout and mount costs, not just React component time. A huge custom native view mutation can still stall the frame.
[S05] [S06] [S14]Engineering decision synthesis
Budget expensive native view changes; batch related state updates when appropriate and measure on actual devices. Avoid assuming a synchronous JSI call has no scheduling consequences.
[S04] [S05] [S06]Failure mode and improvement synthesis
A generic “bridge latency” diagnosis misses mount cost. Compare JS trace, renderer work and platform main-thread trace, then optimize the measured segment.
[S05] [S06] [S14]Check yourself: Can Fabric ever do render work on the UI thread?
Yes. The renderer supports high-priority UI-thread scenarios; do not model all work as an invariant JS-only chain.