Dès que plusieurs panneaux de l’éditeur doivent réagir à la même information, par exemple savoir si un article est en cours d’enregistrement ou quel bloc est sélectionné, il faut un endroit unique où cette information vit. C’est le rôle du paquet @wordpress/data : il organise l’état de l’application en magasins (« stores ») nommés, chacun exposant des sélecteurs pour lire une donnée et des actions pour la modifier, un peu comme Redux dont il s’inspire directement.
Fonctionnement dans WordPress
L’éditeur de blocs (Gutenberg) déclare plusieurs magasins natifs : core/editor pour l’article en cours, core/block-editor pour les blocs et la sélection, core pour les données REST comme les articles ou les taxonomies. Une extension peut lire ces magasins avec le hook useSelect, déclencher une action avec useDispatch, ou créer son propre magasin avec registerStore ou l’API moderne createReduxStore pour partager un état entre plusieurs de ses composants.
Exemple
import { useSelect } from '@wordpress/data';
import { store as editorStore } from '@wordpress/editor';
const titre = useSelect(
( select ) => select( editorStore ).getEditedPostAttribute( 'title' ),
[]
);Bon à savoir
- Les sélecteurs sont mis en cache et ne se recalculent que si les données dont ils dépendent changent, ce qui évite de refaire des rendus inutiles sur des articles volumineux.
- Contrairement à l’API d’interactivité, pensée pour le rendu côté visiteur du site, l’API des données concerne exclusivement l’administration et l’éditeur.
- Un magasin personnalisé mal nettoyé (jamais désinscrit) peut subsister entre deux chargements de page dans certains contextes de test, un piège classique lors du développement d’une extension.