Recordar el estado entre sesiones
Que la ventana vuelva a abrirse donde estaba es de las cosas que más separan una aplicación cuidada de una improvisada. El plugin que lo hace, qué guarda, dónde, y qué hay que añadirle para que no falle.
El plugin
bun run tauri add window-stateLos tres pasos del nivel 8.3, hechos de una vez. Y al registrarlo se elige qué recordar:
use tauri_plugin_window_state::StateFlags;.plugin( tauri_plugin_window_state::Builder::default() .with_state_flags( StateFlags::SIZE | StateFlags::POSITION | StateFlags::MAXIMIZED, ) .build(),)Qué guarda. Tamaño, posición, si estaba maximizada, si estaba en pantalla completa, si era visible, y si tenía el ajuste de estar siempre encima. Cada uno se activa por separado, y no todos convienen siempre: recordar la pantalla completa, por ejemplo, puede dejar a alguien atrapado si la aplicación arranca en pantalla completa y algo falla antes de que la interfaz responda.
Dónde lo guarda. En un fichero dentro del directorio de configuración de la aplicación, el que sale del identificador del nivel 7.1 y que el nivel 39 detalla. Eso tiene dos consecuencias: el usuario puede borrarlo —lo cual es una forma legítima de resolver una ventana que se abre mal— y cambiar el identificador pierde el estado guardado, como todo lo demás que cuelga de él.
Cuándo lo guarda. Al cerrar cada ventana y al salir de la aplicación. Si el proceso muere de golpe, se pierde el último estado y se restaura el anterior, que es un comportamiento razonable.
Lo que hay que añadirle
El plugin hace bien su parte y hay tres cosas que no puede decidir por ti.
1 · La comprobación de monitores. Es la del nivel 11.3, y es la que evita la ventana invisible. El plugin restaura lo que guardó; si el monitor ya no está, la restauración es fiel y el resultado, inútil. La comprobación va después de que el plugin haya restaurado, en el gancho de inicialización:
.setup(|app| { if let Some(win) = app.get_webview_window("main") { // El plugin ya restauró. Ahora se comprueba que tiene sentido. asegurar_visible(&win)?; } Ok(())})2 · Qué ventanas deben recordar. No todas. Una ventana principal, sí. Un diálogo de ajustes, casi siempre sí. Una ventana efímera —una vista previa, un asistente— no: que aparezca donde el usuario la dejó hace tres semanas es más desconcertante que útil. El plugin permite excluir ventanas por etiqueta, y merece la pena decidirlo en vez de aceptar el comportamiento general.
3 · Un camino de rescate. Si el estado guardado deja la aplicación en una situación mala —una combinación rara de pantalla completa y monitor desaparecido— el usuario necesita poder salir sin buscar en internet. Dos opciones, y conviene tener una:
- Una opción de menú que restablezca la ventana a sus valores por defecto.
- Un argumento de línea de comandos o una variable de entorno que arranque ignorando el estado guardado.
Lo que el plugin no cubre, y sí conviene recordar
Hay más estado de interfaz que merece sobrevivir a un cierre, y no es cosa de este plugin:
| qué | dónde guardarlo |
|---|---|
| tamaño, posición, maximizado | el plugin |
| la pestaña o vista abierta | almacenamiento del frontend, o el almacén de preferencias |
| el ancho de un panel lateral | igual |
| el orden de una tabla, el filtro aplicado | igual |
| el documento que estaba abierto | el almacén del core: es una decisión del programa |
| el texto sin guardar | el core, y en cada cambio, no al cerrar |
La última fila es la importante y la que separa de verdad una aplicación cuidada: lo que el usuario ha escrito y no ha guardado no se persiste al cerrar, se persiste mientras escribe. Al cerrar puede no haber ocasión —un apagón, un fallo, un cierre forzoso— y ese es justo el momento en que la persistencia importaría.