Gérer l’état de l’application

Dans egui, l’état de votre application est constitué de données Rust ordinaires stockées dans la structure qui implémente eframe::App. Il n’existe ni magasin spécial ni modèle géré par le framework.

Les champs contiennent tout : saisies de formulaire, sélections, données chargées et indicateurs. À chaque image, update lit et modifie directement ces champs via &mut self.

eframe construit votre application dans une fermeture transmise à run_native. Le modèle le plus simple consiste à utiliser #[derive(Default)] et à construire l’instance avec App::default().

Pour des valeurs initiales qui ne sont pas celles par défaut, implémentez Default manuellement ou ajoutez un constructeur qui accepte le CreationContext afin d’effectuer la configuration, comme celle des polices ou de la persistance.

Comme les widgets empruntent &mut aux champs qui les alimentent, la structure constitue toujours la source unique de vérité. Il n’existe aucun état de vue distinct à synchroniser.

Une case à cocher liée à &mut self.enabled reflète et met directement à jour ce booléen : si vous le lisez ailleurs au cours de la même image, vous obtenez sa valeur actuelle.

Un problème subtil d’emprunt se pose souvent : vous parcourez un Vec tout en souhaitant en supprimer des éléments. Vous ne pouvez pas modifier le vecteur tant qu’un emprunt partagé est actif.

La solution consiste à enregistrer l’action souhaitée dans une variable locale pendant la boucle, puis à l’appliquer après la fin de celle-ci.

Pour les applications à plusieurs écrans, représentez la vue actuelle par un champ de type énumération. La méthode update l’examine pour décider de ce qu’il faut afficher.

La navigation reste ainsi explicite et exhaustive : le compilateur vous oblige à gérer chaque écran, ce qui élimine toute une catégorie de problèmes de routage.

Certains états concernent uniquement l’interface, et non votre domaine métier : sections réduites, positions de défilement ou état d’un déplacement. egui les stocke dans ctx.memory, avec une clé correspondant à l’Id du widget.

Vous y accédez rarement directement, mais ctx.data_mut vous permet de stocker de petites valeurs propres à chaque identifiant, conservées entre les images sans encombrer la structure de votre App.

Ne bloquez jamais update avec des opérations d’E/S lentes : cela fige la boucle à 60 images par seconde. Créez un thread et communiquez par l’intermédiaire d’un canal std::sync::mpsc.

Le thread de travail renvoie les résultats ; à chaque image, update vide le récepteur sans blocage avec try_recv. Appelez ctx.request_repaint() depuis le thread de travail afin que l’interface soit réveillée à l’arrivée des données.

Clonez le Context et l’émetteur dans le thread. Le clonage est peu coûteux — il repose en interne sur un Arc — et permet au thread de travail de demander un nouveau rendu.

Transférez la propriété des données d’entrée du travail dans la fermeture afin de satisfaire le vérificateur d’emprunts et d’éviter les problèmes de durée de vie.

eframe peut sérialiser votre application entre deux exécutions. Activez la fonctionnalité persistence, dérivez serde::Serialize / Deserialize et implémentez App::save.

Au démarrage, lisez l’état enregistré depuis cc.storage dans votre constructeur, en revenant aux valeurs par défaut si rien n’est stocké.

Comme update s’exécute à chaque image, évitez d’y recalculer des données dérivées coûteuses. Mettez les résultats en cache dans des champs et ne les recalculez que lorsque les entrées changent.

Un schéma courant consiste à suivre un indicateur dirty défini par Response::changed(), puis à reconstruire les caches au début de update uniquement lorsque l’indicateur est actif.

Le thème récurrent est le suivant : egui s’appuie sur la propriété de Rust plutôt que sur un framework pour gérer l’état. Votre structure possède les données, &mut self accorde un accès exclusif à chaque image et les threads communiquent par des canaux.

Il n’existe ni abonnements cachés ni graphes de rappels ; il reste donc facile de comprendre quand et comment l’état change, de manière locale et explicite.

Comment devez-vous exécuter une récupération lente sur le réseau ?

L’état de l’App est constitué de champs ordinaires dans la structure eframe::App, modifiés via &mut self à chaque image, ce qui fait de la structure la source unique de vérité.

Différez les modifications pendant les parcours, représentez les écrans avec des énumérations, déportez les tâches lentes dans des threads utilisant des canaux et persistez l’état avec le stockage d’eframe. Gardez update rapide en mettant les données dérivées en cache derrière des indicateurs dirty. Ensuite : empaqueter votre application pour la distribuer.