A React Native barcode-scanner library moves from bridge events to a JSI HostObject: what changes, and what threading rule must its C++ code obey?

## The starting point: a bridge-era scanner Picture a barcode-scanner library written for React Native's legacy architecture. The camera pipeline detects a code on a native thread, and the library sends it to JavaScript as an **event** through the bridge: - every detection becomes a message whose payload (the code, its format, a timestamp) is converted into JSON-compatible data; - the message waits in the bridge queue and reaches JavaScript asynchronously, batched with other traffic; - in this library's bridge API, JavaScript cannot ask "what is the last code?" and get an immediate answer; it calls a method and waits for a callback or a promise; - scanning continuously means a steady stream of serialized messages. ## The JSI design On the New Architecture, the library can expose a **host object** instead. A host object is a C++ subclass of `jsi::HostObject`; JavaScript sees an ordinary object, but its property reads call the subclass's `get` method, writes call `set`, and enumeration calls `getPropertyNames`. It is exposed with `jsi::Object::createFromHostObject`, either returned from a Turbo Native Module method or installed on the runtime's global object. ```cpp class ScannerHostObject : public jsi::HostObject { public: explicit ScannerHostObject(std::shared_ptr<react::CallInvoker> jsInvoker) : jsInvoker_(std::move(jsInvoker)) {} jsi::Value get(jsi::Runtime& rt, const jsi::PropNameID& name) override { if (name.utf8(rt) == "lastCode") { std::lock_guard<std::mutex> lock(mutex_); if (lastCode_.empty()) return jsi::Value::null(); return jsi::String::createFromUtf8(rt, lastCode_); } return jsi::Value::undefined(); } // Called by the camera pipeline on its own thread. void onCodeDetected(std::string code) { { std::lock_guard<std::mutex> lock(mutex_); lastCode_ = code; } jsInvoker_->invokeAsync([code](jsi::Runtime& rt) { // Now on the JS thread: safe to call a stored JS listener here. }); } private: std::shared_ptr<react::CallInvoker> jsInvoker_; std::mutex mutex_; std::string lastCode_; }; ``` What changes for the JavaScript caller: | Concern | Bridge events | JSI host object | |---|---|---| | Reading the last code | Call a method, wait for a promise | `scanner.lastCode`, answered synchronously | | Payload | Serialized on every detection | C++ builds a JS string only when asked | | Native state | Copied into messages | JavaScript holds a reference to the live C++ object | | Delivery | Queued and batched | Direct call, or one scheduled callback per detection | ## The threading rule A `jsi::Runtime` **must not be used from multiple threads concurrently**. JSI's own header says so, and the runtime has no internal lock for you. Three consequences for the scanner: 1. **`get` and `set` run on whichever thread is executing JavaScript**, normally the JS thread, because JavaScript is the caller. They may use the runtime, but they run while JavaScript waits, so they must be quick and must not block on the camera. 2. **The camera thread must never touch the runtime.** It must not create a `jsi::String` or call a stored `jsi::Function` there. It updates plain C++ state under a mutex and then schedules work onto the JS thread with the module's `CallInvoker` (`jsInvoker_->invokeAsync(...)`), whose callback receives the `jsi::Runtime&` on the right thread. 3. **The host object's destructor runs when the garbage collector finalizes the JavaScript object**, on a thread you do not control and possibly as late as runtime shutdown. It must not use the runtime or do expensive work; anything nontrivial goes onto a queue you manage. Shared state between the camera thread and `get` needs its own synchronization, which is why the example guards `lastCode_` with a mutex. ## Choosing the right level - A **typed Turbo Native Module** covers most of this with less risk: synchronous methods, promises, and events generated from a spec. Reach for a raw host object when you need a live, stateful native object in JavaScript, not just a set of methods. - Keep synchronous surfaces **cheap reads**. Starting the camera, requesting permission or decoding an image stays asynchronous. - Deliver high-frequency results **sparingly**: coalesce duplicate detections in C++ before scheduling anything onto the JS thread, because each callback still costs JS-thread time. The interview signal is that you name both halves: the host object removes serialization and makes reads synchronous, and the price is owning thread safety that the bridge used to hide behind its queue.