entz-rn

The entz client for React Native (docs/EDITOR.md section 10.3): connect, open and a DocumentHandle for applications that read and write documents from JavaScript on a phone, over the client's own native library and nothing else. The editor is a second package, entz-rn-editor (client/mobile-editor), which takes a connection the way entz-editor takes one from entz-js on the web: an application that only syncs links this package alone.

import { connect } from "entz-rn";
import { EntzEditor } from "entz-rn-editor";

const client = await connect({ uri, databaseName, token: getToken });
const handle = await client.open(docId);
handle.transact([{ op: "insertBlock", index: 0, kind: "paragraph", text: "hello" }]);
<EntzEditor client={client.describe()} docId={docId} presence={{ name }} />;

How it is built

• client/ffi (entz-ffi, a member of the client/rust workspace) is the C ABI: connect, the admin and document calls by name, open, and a document handle read through its JSON form and written through container operations or update blobs (entz_client_*, entz_handle_*; the header is client/ffi/include/entz.h). scripts/build-ios.sh packages it as ios/EntzFFI.xcframework and writes include/ beside it, the header and a module map, which the podspec puts on Swift's include path for import EntzFFI; scripts/build-android.sh drops the .sos into android/src/main/jniLibs. Both need the Rust targets and, for Android, cargo-ndk, plus perl and make for the vendored OpenSSL (on Windows: Git Bash and Strawberry Perl, the script lends Git's perl the modules it lacks). ENTZ_IOS_TARGETS and ENTZ_ANDROID_ABIS narrow the slices each builds, which is how the cloud builds of apps/entz compile one rather than two (apps/entz/scripts/eas-native.sh). An npm consumer compiles none of it: scripts/fetch-native.js, the package's postinstall, downloads the slices for its version from https://native.entz.app/entz-rn/<version>/ (an R2 bucket that .github/workflows/native-release.yml fills on the tag entz-rn-v<version>, before it publishes the package: the stripped XCFramework with its module and the stripped .sos with the header, as two tarballs; ENTZ_RN_NATIVE_BASE points at a mirror). Inside this repository the script does nothing and the scripts above build from source; ENTZ_RN_NATIVE=source says the same anywhere. A download that fails is a warning, and the native build then says what is missing.
• ios/ holds the Swift Hybrid Objects; android/ the Kotlin objects, the JNI shim and dev/entz/rn/EntzNativePackage.kt, the BaseReactPackage autolinking looks for (it registers nothing itself: the objects register through Nitro when the library loads). The Android module links with a 16 KB maximum page size, as Play requires of apps targeting Android 15 and later (the Rust library is built so by cargo-ndk).
• src/specs/EntzNative.nitro.ts is the Nitro spec; npx nitrogen generates the bindings into nitrogen/. The library exports no symbol under a name the editor's library (libentz_editor_ffi) uses, so an application that installs both packages links both, on iOS into one binary; the one runtime symbol Rust leaves global in a static library, rust_eh_personality, is made private by scripts/build-ios.sh for the same reason (a step written without a Mac at hand: the first iOS build of the package is what tests it).
• src/client.ts gives the objects the TypeScript package's names and types; describe() is the connection as an editor takes it ({ uri, databaseName, token }, the token read before each of the editor's connects); src/hooks.ts is useEntzDocument and useEntzPresence; test/client.test.ts runs the wrapper over a fake Hybrid Object.
• src/client.web.ts stands in for src/client.ts on the web, where Nitro cannot load: the same names and types, and connect, open and the constructors throw, since the client on the web is entz-js.

Expo Go cannot load native modules: use a development build or a bare application. See apps/entz for an Expo application over this package and entz-rn-editor that runs on all three platforms from one source.