Threads: keep the caller responsive

Part 6 · Best practices

Threads: keep the caller responsive

Prerequisites: 03-fabric-path, 05-expo-module-contract

Queue ownership for an illustrative operation; the exact dispatch path depends on the module API and implementation. Nodes: JS thread, Worker / native queue, UI/main thread, Promise / event. — Queue ownership for an illustrative operation; the exact dispatch path depends on the module API and implementation. [S02] [S07] [S12]

Mental model verified

The JS thread runs application logic and usually render work; the UI thread alone manipulates host views. React Native may schedule some rendering on the UI thread. Expo Function runs on JS; AsyncFunction can dispatch to a native queue, with .runOnQueue(.main) when UI access is required.

[S02] [S07]

Worked example synthesis

For a document picker: start platform UI on main, perform file reading away from main, resolve the Promise with a URI and metadata, then update React state on JS. Avoid sending the whole file through a JS value when a URI suffices.

[S02] [S07]

Engineering choice synthesis

Bound synchronous work, use async for I/O, and isolate native state touched from multiple queues. Keep main-thread sections short and check cancellation when an activity or view goes away.

[S07] [S12]

Pitfall and next step synthesis

A Promise can still hide blocking native work if its implementation uses the main queue for CPU-heavy processing. Trace queue hops with profiling and measure both JS and UI frames in a release build.

[S07] [S12]

Keep this: Decide on a queue from the work itself: short sync work on JS, platform UI mutations on main, slow work away from both.

Check yourself: Why can a native synchronous method cause a dropped JS frame?

It executes on the JS caller thread and prevents JS work from progressing until it returns.