State Management
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
State management in ONNX-Station is centralized through the WorkbenchContext, which utilizes the React Context API to provide a unified data layer across the application. The system is designed to manage complex configurations for ONNX model exports, track real-time orchestration logs, and handle the asynchronous lifecycle of model compilation and benchmarking processes.
The state architecture ensures that UI components like the Sidebar, CenterCanvas, and Console remain synchronized with the underlying ExportConfig, while also facilitating local storage persistence for user-defined optimization profiles.
Sources: src/WorkbenchContext.tsx:1-50, src/App.tsx:10-25
Core State Architecture
The application follows a provider-consumer pattern where the WorkbenchProvider encapsulates the global state and exposes it through the useWorkbench hook.
The Workbench Context
The WorkbenchContextType interface defines the structure of the shared state, including configuration objects, status flags, and action handlers.
| State Element | Type | Description |
|---|---|---|
config | ExportConfig | The primary object containing all ONNX export parameters. |
logs | LogEntry[] | An array of chronological messages for the terminal console. |
isExporting | boolean | Flag indicating an active ONNX compilation process. |
isBenchmarking | boolean | Flag indicating an active performance benchmark run. |
isCompiled | boolean | Tracks if the current configuration has been successfully validated. |
benchmarkResult | BenchmarkResult | Stores metrics like latency and throughput after a run. |
Sources: src/WorkbenchContext.tsx:50-77, src/types.ts:47-92
Data Flow Diagram
The following diagram illustrates how user interactions trigger state updates that propagate through the context to various functional modules.
The diagram shows the central role of WorkbenchContext in mediating between UI components, asynchronous runners (Benchmarking/Exporting), and persistence layers.
Sources: src/WorkbenchContext.tsx:100-300, src/components/Sidebar.tsx:15-50
Configuration Management
Model configurations are managed through the ExportConfig interface. This state includes model identification (Hub ID or local path), task definitions, and low-level ONNX parameters like opset versions and optimization levels.
Dynamic Task Mapping
When a user changes the modality (audio, text, or vision), the context automatically resets the task to the first valid option for that modality to maintain state integrity.
This sequence ensures that only valid task strings are ever held in the active configuration state.
Sources: src/WorkbenchContext.tsx:126-133, src/types.ts:3-23
Preset System
The system supports two types of configuration presets:
- SYSTEM_PRESETS: Immutable hard-coded profiles for common targets (e.g., "WebGPU fp16 Target", "CPU fp32 Portable").
- Saved Presets: User-defined configurations persisted in
localStorageunder the keyonnx_workbench_presets.
Sources: src/WorkbenchContext.tsx:7-48, src/WorkbenchContext.tsx:340-360
Asynchronous Process Management
Export and Compilation
The export process is a simulated orchestration that transitions through multiple logical states. It manages the isExporting flag and populates the compiledModelInfo state using the generateCompiledModelInfo utility.
- Initialization: Validates required fields (e.g.,
modelPath). - Orchestration: A
setIntervalloop simulates various steps (Resolving providers, tracing operations, graph abstraction). - Validation: Performs structural checks (e.g., checking for quantized operators on CUDA) and adds warnings to the logs.
Sources: src/WorkbenchContext.tsx:180-264, src/utils/modelInfo.ts:5-20
Benchmarking Lifecycle
Benchmarking interacts with external libraries (onnxruntime-web) and is managed via an AbortController to allow user cancellation.
The benchmark state flow ensures that memory and network resources are tracked through the isBenchmarking and benchmarkResult states.
Sources: src/lib/benchmark.ts:100-240, src/WorkbenchContext.tsx:266-318
Terminal and Orchestration Logging
The logs state is an array of LogEntry objects managed within the context. Components can append logs with different LogLevel values (info, warn, error, success).
- Log Identification: Each log entry is assigned a unique UUID via
crypto.randomUUID(). - Synchronized View: The
Consolecomponent monitors thelogsarray and automatically scrolls to the latest entry. - Statistics: The context calculates counts for warnings and errors based on the current log state for display in the footer.
Sources: src/WorkbenchContext.tsx:109-124, src/components/Console.tsx:15-35
Local File Ingestion
State management for local models involves handling File objects and generating temporary blob: URLs.
| Component | State Logic |
|---|---|
| Ingestion | Uses URL.createObjectURL(file) to create a reference for the benchmarking engine. |
| Cleanup | Invokes URL.revokeObjectURL(url) when a model is removed or replaced to prevent memory leaks. |
| Config Sync | Automatically updates config.modelPath to the local file name upon ingestion. |
Sources: src/WorkbenchContext.tsx:135-150, src/components/Sidebar.tsx:135-175
Conclusion
State management in ONNX-Station provides a robust framework for handling the complex requirements of ONNX model optimization. By centralizing logic within the WorkbenchContext, the application achieves seamless synchronization between configuration parameters, asynchronous runtime processes, and user interface feedback. This architecture allows for advanced features like live performance profiling and dynamic command preview generation while maintaining a responsive user experience.