Gestionar el estado de la aplicación

En egui, el estado de su aplicación son datos normales de Rust que viven en la estructura que implementa eframe::App. No existe ningún almacén especial ni un modelo administrado por el framework.

Los campos contienen todo: entradas de formularios, selecciones, datos cargados y marcas de estado. En cada frame, update lee y modifica estos campos directamente mediante &mut self.

eframe crea su aplicación en un cierre que se pasa a run_native. El patrón más sencillo consiste en usar #[derive(Default)] y crearla con App::default().

Para valores iniciales que no sean los predeterminados, implemente Default manualmente o añada un constructor que reciba CreationContext para realizar tareas de configuración, como cargar fuentes o datos persistentes.

Como los widgets toman prestados sus campos subyacentes mediante &mut, la estructura es siempre la única fuente de la verdad. No existe un estado de vista separado que deba mantenerse sincronizado.

Una casilla vinculada a &mut self.enabled refleja y actualiza ese booleano directamente: si lo lee en cualquier otro lugar del mismo frame, verá el valor actual.

Hay un problema sutil con los préstamos: a menudo se recorre un Vec mientras se desea eliminar elementos de él. No puede modificar el vector mientras exista un préstamo compartido.

La solución consiste en registrar la acción prevista en una variable local durante el bucle y aplicarla después de que este termine.

En aplicaciones con varias pantallas, modele la vista actual como un campo de tipo enum. El método update hace un match sobre él para decidir qué dibujar.

Así, la navegación queda explícita y exhaustiva: el compilador le obliga a gestionar todas las pantallas y elimina toda una clase de errores de enrutamiento.

Parte del estado corresponde exclusivamente a la interfaz, no al dominio: secciones contraídas, posiciones de desplazamiento y estado de arrastre. egui lo almacena en ctx.memory, asociado a un Id de widget.

Rara vez tendrá que acceder a ello directamente, pero ctx.data_mut le permite guardar valores pequeños asociados a cada id que persisten entre frames sin recargar la estructura de su aplicación.

Nunca bloquee update con operaciones de E/S lentas: congelaría el bucle de 60 fps. Cree un hilo y comuníquese mediante un canal std::sync::mpsc.

El worker envía los resultados; update vacía el receptor sin bloquear mediante try_recv en cada frame. Llame a ctx.request_repaint() desde el worker para que la interfaz se reactive cuando lleguen datos.

Clone Context y el sender dentro del hilo. La clonación es económica —internamente es un Arc— y permite que el worker solicite repaints.

Mueva la propiedad de las entradas de trabajo al cierre para satisfacer al borrow checker y evitar problemas de tiempo de vida.

eframe puede serializar su aplicación entre ejecuciones. Habilite la característica persistence, derive serde::Serialize / Deserialize e implemente App::save.

Al iniciar, lea el estado guardado desde cc.storage en el constructor y use los valores predeterminados como alternativa cuando no haya nada almacenado.

Como update se ejecuta en cada frame, evite recalcular allí datos derivados costosos. Guarde los resultados en campos y vuelva a calcularlos solo cuando cambien las entradas.

Un patrón habitual consiste en mantener una marca dirty establecida por Response::changed() y reconstruir las cachés al principio de update únicamente cuando esté activa.

El tema recurrente es que egui se apoya en la propiedad de Rust en lugar de en frameworks para gestionar el estado. Su estructura es propietaria de los datos, &mut self concede acceso exclusivo en cada frame y los hilos se comunican mediante canales.

No hay suscripciones ocultas ni grafos de callbacks, por lo que razonar sobre cuándo y cómo cambia el estado sigue siendo algo local y explícito.

El estado de la aplicación son campos normales de la estructura eframe::App, modificados mediante &mut self en cada frame, lo que convierte a la estructura en la única fuente de la verdad.

Posponga las mutaciones durante los recorridos, modele las pantallas con enums, delegue el trabajo lento a hilos mediante canales y persista el estado con el almacenamiento de eframe. Mantenga update ligero almacenando en caché los datos derivados mediante marcas dirty. A continuación: empaquetar la aplicación para su distribución.