Avril 2024 a marqué le passage en version stable de l’Interactivity API dans WordPress 6.5, après une proposition discutée l’année précédente. Un an après cette stabilisation, la fonction PHP wp_interactivity_state reste sous-utilisée pour un cas d’usage pourtant fréquent : partager un état entre plusieurs blocs indépendants, sans faire remonter des props d’un composant enfant vers un composant parent commun.
Le cas concret ici est un configurateur de produit en trois blocs distincts, insérés côte à côte dans une page : un bloc de sélection de couleur, un bloc de sélection de taille, et un bloc de récapitulatif qui doit refléter les deux choix précédents sans être leur parent direct dans l’arborescence de blocs.
Étape 1 : déclarer l’état partagé côté serveur
Chaque bloc, au moment de son rendu PHP, contribue à un même espace de noms d’état, en utilisant wp_interactivity_state :
<?php
wp_interactivity_state( 'monsite/configurateur', array(
'couleurSelectionnee' => 'bleu',
'tailleSelectionnee' => 'M',
) );
?>
<div data-wp-interactive="monsite/configurateur">
<!-- contenu du bloc couleur -->
</div>
Le premier bloc rendu sur la page initialise l’état ; les blocs suivants, qui déclarent le même espace de noms, viennent lire et modifier cet état déjà existant, sans le réinitialiser.
Étape 2 : lire et modifier l’état depuis chaque bloc
Côté JavaScript, le fichier de vue de chaque bloc importe la fonction store avec le même espace de noms, ce qui donne accès au même état partagé :
import { store, getContext } from '@wordpress/interactivity';
store( 'monsite/configurateur', {
actions: {
choisirCouleur( evenement ) {
const { state } = getContext();
const contexteGlobal = state;
contexteGlobal.couleurSelectionnee = evenement.target.dataset.couleur;
},
},
} );
Étape 3 : refléter l’état dans le bloc récapitulatif
Le troisième bloc, celui du récapitulatif, n’a besoin d’aucune référence directe aux deux premiers blocs. Il lit simplement l’état partagé via une directive data-wp-text, sans jamais recevoir de props depuis un composant parent commun :
<div data-wp-interactive="monsite/configurateur">
<p>Couleur choisie :
<span data-wp-text="state.couleurSelectionnee"></span>
</p>
<p>Taille choisie :
<span data-wp-text="state.tailleSelectionnee"></span>
</p>
</div>
Étape 4 : vérifier l’ordre de rendu des blocs
Un point d’attention concret : la fonction wp_interactivity_state fusionne les valeurs fournies avec l’état déjà présent pour cet espace de noms, ce qui signifie que l’ordre dans lequel les blocs se rendent sur la page influence la valeur initiale visible. Dans ce configurateur, le bloc de sélection de couleur est toujours placé en premier dans le contenu, pour garantir que l’état initial reflète bien ses valeurs par défaut avant celles des blocs suivants.
Étape 5 : éviter la confusion avec wp_interactivity_config
Une fonction voisine, wp_interactivity_config, sert à transmettre une configuration statique (des paramètres qui ne changent pas au fil de l’interaction), et non un état partagé destiné à évoluer. Confondre les deux mène à des données qui ne se synchronisent jamais entre blocs, un piège fréquent chez qui découvre l’API sans avoir lu la distinction dans la documentation officielle du projet.
Ce que cette approche évite concrètement
- Aucun composant parent artificiel n’a dû être créé uniquement pour faire transiter des props entre les trois blocs ;
- Chaque bloc reste insérable et déplaçable indépendamment dans l’éditeur, sans dépendance structurelle rigide ;
- La lecture de l’état reste déclarative, directement dans le balisage, sans code JavaScript supplémentaire côté récapitulatif.
Un état partagé par espace de noms remplace élégamment la remontée de props quand plusieurs blocs indépendants doivent malgré tout se parler.
En résumé
Depuis la stabilisation de l’Interactivity API en avril 2024, wp_interactivity_state permet à plusieurs blocs distincts, sans relation parent-enfant directe, de partager un même état sans prop drilling. Pour un configurateur de produit en plusieurs blocs, ce mécanisme évite la complexité artificielle qu’aurait imposée une architecture à base de composant conteneur unique.
