Un panneau personnalisé développé pour une agence de communication proposait un mode « aperçu compact » activable par un simple interrupteur, pratique pour les rédacteurs habitués à travailler sur de longs articles. Le problème : ce réglage revenait systématiquement à son état par défaut à chaque rechargement de page, ce qui obligeait les utilisateurs à le réactiver plusieurs fois par jour. La première implémentation stockait cet état dans un simple useState local au composant, une solution qui ne survit jamais à un changement de page.
Le package @wordpress/preferences, disponible depuis WordPress 5.9, existe précisément pour ce type de besoin : mémoriser un réglage d’interface propre à un utilisateur, de façon persistante entre deux sessions, sans avoir à réinventer un mécanisme de sauvegarde personnalisé.
Le store preferences et ses scopes
Le store core/preferences organise les réglages par « scope », une chaîne de caractères qui regroupe logiquement les préférences liées à un même contexte, par exemple core/edit-post pour l’éditeur d’article ou un scope personnalisé comme mon-agence/aperçu-compact pour une extension tierce. À l’intérieur d’un scope, chaque préférence est identifiée par un nom de clé, et sa valeur peut être n’importe quelle valeur sérialisable.
Lire et écrire avec usePreference
import { useSelect, useDispatch } from '@wordpress/data';
import { store as preferencesStore } from '@wordpress/preferences';
function ApercuCompactToggle() {
const activé = useSelect(
( select ) =>
select( preferencesStore ).get( 'mon-agence', 'apercuCompact' ),
[]
);
const { toggle } = useDispatch( preferencesStore );
return (
<ToggleControl
label="Aperçu compact"
checked={ !! activé }
onChange={ () => toggle( 'mon-agence', 'apercuCompact' ) }
/>
);
}La méthode toggle inverse simplement une valeur booléenne existante, tandis que set permet d’écrire une valeur arbitraire, utile pour des réglages qui ne se limitent pas à un simple interrupteur, comme un nombre de colonnes ou un mode d’affichage parmi plusieurs options.
Où vit réellement la persistance
Contrairement à ce que son nom pourrait laisser penser, le store preferences ne repose pas sur un cookie ou sur le stockage local du navigateur seul : il synchronise ses valeurs vers une option utilisateur stockée en base de données WordPress, ce qui garantit que le réglage suit l’utilisateur d’un navigateur à l’autre, tant qu’il se connecte avec le même compte. C’est une différence importante par rapport à un stockage purement côté navigateur, qui aurait forcé chaque nouvel appareil à repartir de zéro.
Définir une valeur par défaut cohérente
Le hook usePreference accepte une valeur de retour undefined tant qu’aucune préférence n’a jamais été enregistrée pour cette clé, ce qui oblige à gérer explicitement ce cas au premier chargement, généralement via l’opérateur de coalescence nulle plutôt que de supposer une valeur par défaut implicite.
const colonnes = useSelect(
( select ) =>
select( preferencesStore ).get( 'mon-agence', 'nbColonnes' ) ?? 3,
[]
);- Toujours prévoir une valeur de repli explicite pour la première utilisation.
- Préfixer le scope avec le nom du projet pour éviter toute collision avec un autre plugin.
- Ne pas y stocker de données volumineuses : ce store est pensé pour des réglages d’interface légers, pas pour du contenu.
Différence avec les données d’entité d’un article
Un point de confusion fréquent consiste à mélanger ce store avec les données d’entité gérées par core/editor, comme les métadonnées d’un article. Les préférences appartiennent à l’utilisateur connecté et s’appliquent partout où il navigue dans l’administration, indépendamment de l’article ouvert ; les données d’entité, elles, appartiennent à un article précis et changent selon le contenu affiché. Confondre les deux conduit à des réglages qui semblent « fuiter » d’un article à l’autre alors qu’ils sont, en réalité, correctement rattachés à l’utilisateur et non à l’article.
Une préférence d’interface qui varierait selon l’article ouvert n’est presque jamais une vraie préférence : c’est probablement une métadonnée d’article déguisée, et le bon store n’est alors pas celui-ci.
En résumé
Le store preferences règle un problème précis et récurrent dans le développement de panneaux et d’extensions d’éditeur : la mémorisation durable d’un réglage d’interface propre à un utilisateur. Sa mise en œuvre tient en quelques lignes grâce à useSelect et useDispatch, pour un confort d’usage immédiatement perceptible par les rédacteurs, sans qu’aucune infrastructure de sauvegarde personnalisée ne soit nécessaire côté serveur.
