Hey, we use Tauri for an application at work!
You should use Builder::manage()
to tell Tauri to manage a piece of state and make it accessible to your commands later on. All you'll need to do is add a universe: tauri::State<Universe>
argument to your command function.
I'll copy the example here:
use std::{collections::HashMap, sync::Mutex};
use tauri::State;
// here we use Mutex to achieve interior mutability
struct Storage {
store: Mutex<HashMap<u64, String>>,
}
struct Connection;
struct DbConnection {
db: Mutex<Option<Connection>>,
}
#[tauri::command]
fn connect(connection: State<DbConnection>) {
// initialize the connection, mutating the state with interior mutability
*connection.db.lock().unwrap() = Some(Connection {});
}
#[tauri::command]
fn storage_insert(key: u64, value: String, storage: State<Storage>) {
// mutate the storage behind the Mutex
storage.store.lock().unwrap().insert(key, value);
}
tauri::Builder::default()
.manage(Storage { store: Default::default() })
.manage(DbConnection { db: Default::default() })
.invoke_handler(tauri::generate_handler![connect, storage_insert])
// on an actual app, remove the string argument
.run(tauri::generate_context!("test/fixture/src-tauri/tauri.conf.json"))
.expect("error while running tauri application");
Global variables really hurt you in the long run because it makes it hard to manage access to the state, and their singleton nature makes testing quite difficult.