# « @wordpress/preferences : mémoriser les réglages d’un utilisateur »

> Un panneau qui se referme à chaque rechargement de page agace plus vite qu'on ne le pense. Un store dédié existe justement pour éviter ça.

- Auteur : Clément Hadrot
- Publié le : 2021-10-14
- Mis à jour le : 2021-10-14
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/wordpress-preferences-memoriser-reglages-utilisateur/

## L’essentiel

- Le store preferences persiste par scope et par nom de clé
- usePreference lit et écrit en une seule fonction
- La persistance passe par les options utilisateur, pas un cookie

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.

> L'essentiel à retenir : Le store preferences persiste par scope et par nom de clé ; usePreference lit et écrit en une seule fonction ; La persistance passe par les options utilisateur, pas un cookie

## 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.