Ranger architecture

1 — What runs where

Written: 2026-08-15 · Established by: reading src/, rust/ and src-tauri/ at commit 93a9a67, plus package.json and vite.config.ts.

Ranger is one static bundle and nothing else. There is no server, no API and no account. A grep for fetch(, XMLHttpRequest, axios and WebSocket across src/ outside the tests returns nothing, so a program dropped into the tab never leaves the machine it was dropped on. That is the single most load-bearing fact about the architecture, and every other diagram here inherits it.

Three execution contexts do the work: the main thread, a pool of tri-dexel sweep workers, and one geometry-import worker. Two of the three reach WebAssembly.

Geometry-import lane

Simulation lane

Main thread

React UI

Zustand store

CodeMirror

R3F canvas

tri-dexel ×N
workers

tri-dexel kernel
wasm

step-import
one worker

occt-import-js
wasm

Static bundle

Tauri webview

What survives a reload, drawn separately so no edge has to cross the diagram above:

React UI

localStorage
settings and options

Zustand store

IndexedDB
imported geometry

Nothing else persists. A loaded program is not saved anywhere — closing the tab loses it, which is the deliberate consequence of having no server to save it to.

Box Where it lives Worth knowing
React UI src/App.tsx, src/sidebar, src/transforms, src/export
Zustand store src/store Six slices — diagram 3
CodeMirror src/codemirror Its own undo history is off
R3F canvas src/viewer THREE via @react-three/fiber
localStorage keys prefixed ranger: Viewer settings, export options, density limits, nav bindings, panel layout
IndexedDB database ranger-geometry src/utils/geometry-db.ts; imported bodies only
step-import worker src/workers/step-import.worker.ts One, spawned lazily by src/utils/geometry-worker.ts
tri-dexel workers src/workers/tri-dexel.worker.ts N = min(16, cores - 1), spawned by src/sim/pool.ts
occt-import-js npm package OpenCascade STEP reader, 7.6 MB of wasm
tri-dexel kernel rust/tri-dexel 13.4 kB, base64-inlined into src/sim/kernel-wasm.ts

What is worth knowing beyond the boxes

The sweep kernel is checked in, not built. src/sim/kernel-wasm.ts carries the compiled WebAssembly as a base64 string with a GENERATED — do not edit banner. rust/tri-dexel/build.sh rebuilds it from rust/tri-dexel/src/lib.rs, and the result is committed. So a clone needs no Rust toolchain to run or test the simulator.

Both workers are spawned from the store's side, not from a component. src/sim/pool.ts creates the sweep pool and src/utils/geometry-worker.ts creates the import worker; src/store/geometry-slice.ts is the only importer of the latter.

src/sim/inline-runner.ts is a third execution path that the app never takes. It implements the same SimulationRunner interface on the calling thread, so the whole engine can be driven from Vitest's node project. Every real run goes through the pool.

The desktop shell is thin. src-tauri/src/lib.rs registers a log plugin and opens a window. No Tauri command is defined, so nothing in src/ branches on whether it is running in a browser or in the shell.

Drag to pan · scroll to zoom · Esc to close