@wordpress/data

Définition : @wordpress/data fournit un système de magasins d’état pour lire des informations et déclencher des actions dans les interfaces JavaScript WordPress. Il facilite les interactions entre plusieurs composants de l’éditeur.

Comprendre et utiliser

À quoi cela sert ?

Ce mécanisme centralise un état réactif. Les sélecteurs lisent les données du magasin ; les actions demandent des changements dont les effets peuvent être propagés aux composants abonnés.

Comment cela fonctionne ?

select() et dispatch() existent en version impérative. Les hooks useSelect() et useDispatch() sont adaptés aux composants React qui doivent se mettre à jour en fonction du magasin.

Dans quel contexte l’utiliser ?

À utiliser lorsqu’un panneau personnalisé doit connaître le bloc sélectionné ou déclencher une commande de l’éditeur sans manipuler directement son DOM.

Cas concret : ATOOLPHA

Un panneau ATOOLPHA peut afficher l’identifiant du bloc actuellement sélectionné afin de proposer une aide contextuelle sur son type.

Exemple de code commenté

Extrait documentaire : le contexte WordPress du plugin/éditeur et les dépendances décrites sont nécessaires ; ne pas coller dans le contenu d’une page.

const { select } = wp.data;
const store = 'core/block-editor';
const selectedId = select( store ).getSelectedBlockClientId();
const selected = selectedId
    ? select( store ).getBlock( selectedId )
    : null;
console.log( selected?.name || 'Aucun bloc sélectionné' );

Décryptage de l’exemple

Le sélecteur retourne un identifiant client ou null, puis getBlock() consulte l’instance correspondante. L’extrait montre une lecture ponctuelle ; un composant réactif privilégiera useSelect().

Résultat attendu

L’opération renseigne l’interface de diagnostic, sans sauvegarder ni modifier l’article.

Atelier pratique de vérification

Sélectionner successivement deux blocs dans un brouillon et lire leur identifiant avec le magasin core/block-editor. Comparer l’appel select() ponctuel à un composant utilisant useSelect(). Observer la mise à jour réactive après chaque sélection, et prévoir l’état où aucun bloc n’est sélectionné.

Précautions et limites

Ne pas lire le magasin en boucle par temporisateur pour reproduire artificiellement la réactivité. Préférer les hooks et les sélecteurs documentés ; gérer les valeurs null.

Contrôle avant intégration dans un plugin

Prévoir les cas de magasin non disponible, de sélection vide et de changement rapide de document. Les lectures réactives doivent rester ciblées afin d’éviter de déclencher des recalculs inutiles de l’interface.

À ne pas confondre

@wordpress/data décrit l’accès à l’état ; @wordpress/blocks décrit les types et la création des instances.

Diagnostic et dépannage avancés

Si une valeur semble figée, contrôler si le composant utilise un abonnement useSelect() plutôt qu’une lecture unique select() hors de son cycle de rendu.