This document outlines the planned architectural improvements to evolve the spreadsheet engine into a high-performance, WebAssembly-driven calculation platform.
(Status: Planned)
Problem: Circular dependency checks currently return POSITIVE_INFINITY for non-numeric types (strings, booleans), causing infinite loops until maxIterations is hit.
Solution: Implement strict equality checks (===) for non-numeric values in the convergence detection logic.
Impact: Prevents wasted CPU cycles and unresponsive workers during circular reference evaluation involving status toggles or text.
Problem: A new FormulaParser instance is created for every single cell during evaluation, causing massive memory churn and initialization overhead.
Solution:
Implement a singleton FormulaParser in the worker.
Use a mutable TaskContext to swap out the scopeMap and sheetId for each evaluation pass without recreating the parser.
Impact: Significant reduction in garbage collection pauses and faster batch processing.
Problem: Rapid user inputs (e.g., dragging a handle, fast typing) can flood the worker with calculation requests.
Solution: Set a default coalesceDelayMs (e.g., 16ms) in useCalculationWorker.
Impact: Smoother UI interactions by batching rapid-fire updates into single calculation frames.
(Status: Design Phase)
Move the authoritative state from React/JS to the Web Worker (Rust/WASM).
Current Architecture:
React holds state → Serializes JSON → Worker calculates → Returns JSON.
Performance bottleneck: Data serialization and Main Thread blocking.
New Architecture:
Worker/WASM: Acts as the In-Memory Database. Stores Grid { cells: HashMap<Coord, CellData> }.
React: Acts as the "View". Stores only the ViewportCache (visible cells) and Y.Doc (for sync).
Flow:
React sends lightweight "Delta" (A1 = 5) to Worker.
Worker updates internal WASM state.
Worker recalculates affected dependencies in-memory (Zero-Copy).
Worker sends back only the diffs (B1 changed to 10).
Impact: 60 FPS rendering regardless of dataset size (1M+ rows).
Goal: Replace fast-formula-parser (JS) with a Rust-based evaluation engine.
Why: JS parsing is slow; Rust allows SIMD optimizations for array formulas and strictly typed math.
Plan:
Expand dag-wasm to include an EvaluationEngine.
Port standard Excel functions to Rust.
Expose evaluate(formula: &str) directly to the DAG.
Goal: Efficiently sync concurrent edits (CRDTs) with the linear memory of WASM.
Implementation:
Use Y.Doc on the Main Thread for networking and conflict resolution.
Create a "Bridge" that observes Y.Doc changes and pushes binary/flat updates to the Worker.
Worker treats these updates as "External Inputs" and never writes back to Yjs directly (Unidirectional Data Flow).
Date Systems: Add support for both 1900 and 1904 date systems (Excel compatibility).
Number Precision: Handle IEEE 754 floating-point quirks (e.g., 0.1 + 0.2) to match Excel's 15-digit precision behavior.
Problem: Dependencies on large ranges (e.g., SUM(A1:A10000)) trigger massive data transfers.
Solution: With the In-Memory Cell Store, range functions read directly from WASM memory. No data transfer is required between the calculation logic and the data store.
Last updated
