Saltar al contenido

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

Rust
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.