Aplazar todo lo que se pueda
El trabajo del arranque ordenado en tres grupos: lo que va antes de la ventana, lo que va después, y lo que puede esperar a que haga falta.
Los tres grupos
La primera fila es la lección: si tu función de arranque tiene más de veinte líneas antes de crear la ventana, hay trabajo mal colocado.
El orden concreto
fn main() { tauri::Builder::default() .plugin(single_instance::init(...)) // grupo 1: tiene que ir aquí .setup(|app| { let estado = Estado::vacio(); // grupo 1: sin tocar disco app.manage(estado); // la ventana se crea con lo mínimo, y aparece let w = crear_ventana(app)?; // grupo 2: en segundo plano, en cuanto la ventana existe let handle = app.handle().clone(); tauri::async_runtime::spawn(async move { inicializar(&handle).await; // base, migraciones, sesión let _ = handle.emit("listo", ()); }); Ok(()) }) .run(...)}Y el grupo 3 no aparece: se dispara cuando alguien lo pide. La comprobación de actualizaciones, unos minutos después de arrancar o al volver del segundo plano; la conexión al servicio, la primera vez que hace falta.
Lo que el usuario ve mientras tanto
Mover trabajo después de la ventana crea una situación nueva: la ventana existe y aún no hay datos. Y eso hay que diseñarlo:
La segunda opción es la que más rinde y encaja con el nivel 44.1: guardar el estado de la vista incluye poder pintarlo antes de tener los datos frescos.
Lo que hay que tener en cuenta al mover
Tres cosas, y las tres producen fallos si se olvidan:
- La interfaz tiene que tolerar el estado «aún no». Cada pantalla que dependa de algo del grupo 2 necesita un camino para cuando no está — igual que el camino de «no está» del nivel 37.5.
- Los comandos pueden llegar antes que la inicialización. Si el usuario pulsa algo en el primer medio segundo, el comando puede encontrarse la base sin abrir. Hay que esperar a que esté, no fallar.
- Y los errores del grupo 2 hay que comunicarlos. Una migración que falla en segundo plano no puede pasar desapercibida: nivel 43.2.
El segundo es el que más se olvida, y su solución es sencilla: que el acceso a la base espere a la inicialización en vez de suponerla hecha.