wp_interactivity_state() : c’est cette seule fonction, ajoutée au cœur de WordPress avec la version 6.5 sortie en avril 2024, qui permet de déclarer un état partagé entre le serveur et le navigateur, sans écrire le moindre script personnalisé. Pour un développeur habitué à empiler des scripts jQuery ou des appels REST manuels, la bascule est déroutante au premier abord.
Le cas d’usage le plus parlant reste un compteur simple : afficher combien de fois un visiteur a cliqué sur un bouton « j’ai lu cet article », avec une mise à jour immédiate à l’écran, sans rechargement de page ni requête AJAX explicite à écrire.
Les trois briques de l’Interactivity API
L’API repose sur trois éléments qui se combinent : un état PHP déclaré via wp_interactivity_state(), des directives HTML préfixées par data-wp- posées directement dans le balisage du bloc, et un fichier view.js qui définit les actions appelées par ces directives. Le tout s’appuie sur le module @wordpress/interactivity chargé automatiquement par WordPress.
Contrairement à un bloc dynamique classique qui ne fait que produire du HTML, un bloc interactif reste réactif après son affichage : cliquer sur un élément peut modifier l’état et rafraîchir instantanément une portion de la page.
Déclarer l’état côté serveur
Dans le fichier render.php du bloc, on initialise l’état avec la valeur actuelle du compteur, lue depuis un champ personnalisé de l’article affiché.
$compteur = (int) get_post_meta( get_the_ID(), 'vues_compteur', true );
wp_interactivity_state( 'monagence/compteur-vues', array(
'valeur' => $compteur,
) );Ce nom d’espace de noms, monagence/compteur-vues, sert ensuite de référence unique dans le balisage HTML pour retrouver cet état précis, y compris si plusieurs blocs interactifs cohabitent sur la même page.
Poser les directives dans le balisage
Le fichier render.php produit ensuite un balisage enrichi de directives qui relient le bouton à l’action, et le texte affiché à la valeur de l’état.
<div data-wp-interactive="monagence/compteur-vues">
<span data-wp-text="state.valeur"></span>
<button data-wp-on--click="actions.incrementer">
J'ai lu cet article
</button>
</div>La directive data-wp-text lie le contenu textuel de l’élément à la propriété valeur de l’état, tandis que data-wp-on--click déclenche l’action incrementer au clic, sans qu’aucun gestionnaire d’événement ne soit ajouté manuellement.
Définir l’action côté client
L’action elle-même s’écrit dans un fichier view.js séparé, chargé automatiquement par WordPress grâce à la déclaration dans block.json.
import { store } from '@wordpress/interactivity';
store( 'monagence/compteur-vues', {
actions: {
incrementer() {
const context = this.state;
context.valeur = context.valeur + 1;
},
},
} );Cette écriture reste bien plus courte qu’un script jQuery équivalent, et surtout elle fonctionne indépendamment du thème actif, ce qui simplifie grandement la maintenance sur un projet multi-thèmes.
Ce que ce compteur ne fait pas
- Il ne persiste aucune donnée côté serveur au clic : la valeur repart à son état initial au rechargement complet de la page
- Il ne protège pas contre les clics multiples d’un même visiteur
- Il ne remplace pas un système de statistiques de fréquentation
Pour conserver la valeur entre deux visites, il faudrait ajouter un appel à l’API REST déclenché depuis l’action, un sujet distinct qui mérite son propre traitement.
L’Interactivity API n’est pas un remplaçant universel de React : elle brille sur des interactions ponctuelles et légères, pas sur des interfaces complexes à états multiples.
Gérer plusieurs blocs sur une même page
Un article qui affiche le compteur à la fois en tête de page et en pied de contenu pose une question naturelle : les deux instances partagent-elles le même état ? Oui, tant qu’elles déclarent le même espace de noms monagence/compteur-vues, l’Interactivity API synchronise automatiquement l’affichage des deux zones dès qu’une action modifie l’état partagé, sans code supplémentaire à écrire pour cette synchronisation.
Ce comportement diffère radicalement d’un script jQuery classique, où chaque zone d’affichage nécessiterait sa propre logique de mise à jour manuelle, avec le risque que l’une des deux zones se désynchronise après une modification ultérieure du code.
En résumé
Trois fichiers, une fonction PHP et quelques directives HTML suffisent à obtenir un bloc réactif là où un script maison aurait demandé bien davantage de code à maintenir. C’est un bon premier projet pour se familiariser avec l’Interactivity API avant de s’attaquer à des cas plus ambitieux.
