wp_interactivity_state( $namespace, $state = array() ). Cette fonction, disponible depuis la stabilisation de l’Interactivity API en avril 2024 avec WordPress 6.5, permet de définir un état côté serveur, sous un espace de noms donné, qui sera automatiquement rendu disponible au module d’interactivité chargé côté client. C’est ce mécanisme précis qui a permis de résoudre un problème récurrent sur un site de covoiturage local associatif : faire dialoguer un bloc natif Gutenberg avec un composant React déjà présent dans le même thème, sans dupliquer la logique d’état entre les deux.
Le site fonctionnait en headless partiel : l’essentiel du contenu éditorial passait par des blocs classiques, mais un module de recherche de trajets, plus complexe, restait un composant React monté sur une portion précise de la page. Le problème posé était simple à formuler mais pénible à résoudre proprement : quand un visiteur filtrait les trajets via un bloc natif (sélection d’un jour de la semaine), le composant React devait réagir sans qu’un rechargement de page n’intervienne.
Ce que fait réellement la fonction
wp_interactivity_state s’appelle côté PHP, typiquement dans la fonction de rendu d’un bloc, et initialise un état associé à un espace de noms. Cet état est ensuite sérialisé automatiquement dans un attribut de données JSON injecté dans la page, que le module client de l’Interactivity API lit au chargement pour synchroniser son propre état réactif.
function rendre_bloc_filtre_jour( $attributs, $contenu ) {
$state = wp_interactivity_state( 'covoiturage/filtre', array(
'jourSelectionne' => $attributs['jourParDefaut'] ?? 'tous',
'nombreTrajets' => compter_trajets_du_jour( $attributs['jourParDefaut'] ?? 'tous' ),
) );
return sprintf(
'<div data-wp-interactive="covoiturage/filtre" data-wp-context=\'%s\'>%s</div>',
wp_json_encode( $state ),
$contenu
);
}Le pont vers le composant React
Le composant React, monté séparément via createRoot() sur un conteneur dédié, écoute les changements de l’état exposé sous l’espace de noms covoiturage/filtre plutôt que de maintenir son propre état interne du jour sélectionné. Un petit script d’interface a été écrit pour observer les mutations de cet état partagé et les répercuter sur les props du composant React.
import { store, getContext } from '@wordpress/interactivity';
store( 'covoiturage/filtre', {
actions: {
selectionnerJour( event ) {
const context = getContext();
context.jourSelectionne = event.target.dataset.jour;
},
},
} );Côté React, un observateur simple relit la valeur exposée dans l’attribut data-wp-context à chaque changement déclenché par le module d’interactivité, et met à jour l’affichage du composant en conséquence. Ce n’est pas un couplage aussi propre qu’un état partagé natif entre deux composants React classiques, mais c’était suffisant pour ce cas précis, sans réécrire tout le module de filtre en React.
Ce que ce mécanisme a évité
- Réécrire le bloc de filtre entièrement en React, alors que sa logique de rendu côté serveur restait pertinente pour le référencement
- Maintenir deux états séparés synchronisés à la main via des événements DOM personnalisés
- Ajouter une dépendance de gestion d’état supplémentaire uniquement pour ce cas d’usage limité
L’Interactivity API n’a pas été pensée pour remplacer un framework front complet, mais pour éviter d’en avoir besoin sur des interactions qui restent, au fond, assez simples. La confondre avec React revient à mal l’employer.
Ce que ce cas d’usage ne couvre pas
Le rendu côté serveur complet d’un front headless n’entre pas dans ce périmètre : ce mécanisme fonctionne dans le contexte d’un thème WordPress classique qui charge à la fois des blocs natifs et un composant React monté localement, pas dans une architecture où l’intégralité du rendu est déléguée à un serveur Next.js ou équivalent, séparé de WordPress.
Le bilan sur ce projet
Le filtre par jour fonctionne désormais sans rechargement de page, avec une synchronisation quasi instantanée entre le bloc natif et le composant React. L’équipe a gagné en simplicité de maintenance, n’ayant plus à gérer deux sources de vérité pour un même état d’interface.
Ce qu’il faut retenir
wp_interactivity_state ouvre une voie intermédiaire entre le tout-PHP et le tout-JavaScript, particulièrement utile dans les architectures headless partielles où cohabitent blocs natifs et composants front plus riches. Ce n’est pas un outil pour un headless complet, mais pour ce cas précis de cohabitation, il a évité un travail de synchronisation manuel fastidieux et fragile.
