Callbacks et persistance
Vue d'ensemble
WebGridCanvas expose 4 callbacks pour réagir aux mutations déclenchées
par l'utilisateur. Ce sont les primitives nécessaires pour persister
l'état de la grille dans localStorage, vers un backend, ou tout autre
puits externe. La grille elle-même ne persiste jamais rien — ce choix
est laissé à l'appelant.
Callbacks disponibles
Persister la layout des colonnes
set_on_columns_changed se déclenche après chaque commande qui modifie
la layout. Combinée aux 3 readers, elle permet de capturer l'état.
Readers
Exemple : localStorage
Au montage, lire le JSON et l'appliquer :
- Largeurs — assigner
ColumnDef.widthavant de construire leGridModel - Ordre — trier
model.columnspour correspondre à l'ordre persisté - Pinned count — affecter
model.pinned_countdirectement (ou viaset_pinned_countaprès mount)
Après mutation des largeurs ou de l'ordre dans model.columns, recalculer
les offsets précalculés utilisés par le hit-testing :
L'exemple examples/basic-leptos/src/lib.rs contient un flow
load/save/apply complet à recopier.
Portée de set_on_columns_changed
Le callback couvre uniquement la layout physique : largeurs, ordre,
nombre d'épinglées. Il ne se déclenche pas sur ToggleSort,
SetSort, ClearSort, SetColumnFilter ou ClearAllFilters — il n'y
a pas encore de callback dédié pour ces commandes. Persistez le tri et
les filtres séparément si nécessaire.
Il se déclenche aussi sur CommitColumnResize (une seule fois au
mouseup), et non sur chaque ResizeColumn intermédiaire du drag —
donc les écritures dans localStorage restent rares sans aucun throttle
de votre côté.
Ré-entrance
⚠️ Ne pas dispatcher une GridCommand de manière synchrone depuis un
callback. Le callback s'exécute pendant que l'état interne de la grille
est encore emprunté en lecture — un nouveau dispatch ferait paniquer le
RefCell. Différer via queueMicrotask, setTimeout(0), ou un canal
si vous avez besoin de réagir avec une autre commande.