state management

12 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Using Manager API to manage application state

Tauri applications can manage state using the Manager API. State is managed via the Builder setup method using app.manage() to register state, and then accessed with app.state::<StateType>(). The Manager trait provides the state() method for accessing registered state.

Simple state management example with Builder

State is registered in the setup callback: Builder::default().setup(|app| { app.manage(AppData { welcome_message: "Welcome to Tauri!", }); Ok(()) }).run(tauri::generate_context!()).unwrap()

Interior mutability pattern with Mutex for stateful Rust modules

For state that needs to persist across multiple command invocations and be modified, use Mutex to wrap the state. Lock the Mutex with state.lock().unwrap() to get mutable access. The lock is automatically released when the MutexGuard is dropped at the end of scope, allowing other parts of the application to access and modify the data.

Mutex state management with counter example

Use std::sync::Mutex with app.manage(Mutex::new(AppState::default())) in setup. Access with: let state = app.state::<Mutex<AppState>>(); let mut state = state.lock().unwrap(); state.counter += 1;

Accessing state in Tauri commands

In commands, receive state as a parameter: #[tauri::command] fn increase_counter(state: State<'_, Mutex<AppState>>) -> u32 { let mut state = state.lock().unwrap(); state.counter += 1; state.counter }

Async commands with state access

Async commands can access state similarly. When using async commands with Tokio's async Mutex, call state.lock().await instead of state.lock().unwrap(). Async commands must return a Result type: #[tauri::command] async fn increase_counter(state: State<'_, Mutex<AppState>>) -> Result<u32, ()> { let mut state = state.lock().await; state.counter += 1; Ok(state.counter) }

Accessing state outside commands with Manager trait

To access state outside commands (in event handlers or other threads), use the Manager trait's state() method via AppHandle. Example: let app_handle = window.app_handle(); let state = app_handle.state::<Mutex<AppState>>(); let mut state = state.lock().unwrap();

State access in window event handler example

In on_window_event handler: fn on_window_event(window: &Window, _event: &WindowEvent) { let app_handle = window.app_handle(); let state = app_handle.state::<Mutex<AppState>>(); let mut state = state.lock().unwrap(); state.counter += 1; }

Arc is not needed for State-managed values in Tauri

Arc (Atomically Reference Counted) is not necessary for values stored in Tauri's State because Tauri handles the reference counting automatically. AppHandle can be moved to new threads instead, which is deliberately cheap to clone. AppHandle can then be used to access state via the Manager trait.

Standard library Mutex vs Tokio async Mutex

The standard library Mutex can typically be used in async code and is often preferred. Tokio's async Mutex is mainly needed for shared mutable access to IO resources like database connections. Standard Mutex should be used unless MutexGuard needs to be held across await points.

State type mismatch causes runtime panic not compile error

Using the wrong type in the State parameter causes a runtime panic, not a compile-time error. For example, using State<'_, AppState> instead of State<'_, Mutex<AppState>> will panic at runtime because the state type will not exist.

Using type alias to prevent state type mismatch errors

Type aliases can prevent state type mismatch errors. Define the full type: type AppState = Mutex<AppStateInner>; Then use State<'_, AppState> in commands. Do not re-wrap the type alias with Mutex, as that causes the same problem.

Give your agent this brain