{ "supports": { "interactivity": true } } : cette simple entrée dans block.json suffit à indiquer à WordPress qu’un bloc utilise l’Interactivity API, stabilisée avec la version 6.5 en avril 2024. Pour un bloc jusque-là construit avec des écouteurs d’événements posés à la main sur le DOM, ce changement de déclaration est aussi un changement de philosophie.
Cet article s’adresse aux développeurs qui migrent un bloc interactif existant vers cette API stable, et qui se demandent concrètement ce que la déclaration dans block.json change pour le rendu, le script et l’état du bloc. Les container queries, qui relèvent d’un tout autre sujet, ne sont pas abordées ici.
Ce que déclenche la déclaration dans block.json
Ajouter supports.interactivity à la valeur true a un effet précis : WordPress enveloppe automatiquement le balisage du bloc, au moment du rendu, avec les attributs nécessaires pour que le module d’hydratation de l’Interactivity API prenne le relais côté client. Sans cette ligne, les directives data-wp-* posées dans le save ou dans un rendu dynamique ne seraient tout simplement pas interprétées.
Il existe une variante plus fine, sous forme d’objet, qui permet de préciser si le bloc doit être considéré comme une racine d’interactivité indépendante :
{
"apiVersion": 3,
"name": "monplugin/compteur",
"supports": {
"interactivity": {
"interactive": true
}
}
}Remplacer les écouteurs manuels par des directives
Un bloc écrit avant l’Interactivity API attachait souvent un addEventListener sur un bouton, dans un fichier view.js chargé via viewScript. Cette approche fonctionnait, mais elle isolait la logique du balisage : il fallait retrouver, dans deux fichiers séparés, le sélecteur ciblé et le comportement associé.
Avec l’Interactivity API, le même comportement s’exprime directement dans le balisage, via des directives lues par le module @wordpress/interactivity :
<button
data-wp-on--click="actions.incrementer"
data-wp-text="state.libelle"
></button>Le script associé se limite alors à décrire l’état et les actions, sans jamais chercher un nœud du DOM par lui-même :
import { store, getContext } from '@wordpress/interactivity';
store( 'monplugin', {
state: {
get libelle() {
const context = getContext();
return `Total : ${ context.compteur }`;
},
},
actions: {
incrementer() {
const context = getContext();
context.compteur++;
},
},
} );Où vit l’état, et pourquoi cela change la maintenance
La différence la plus profonde ne se voit pas dans le HTML, mais dans la gestion de l’état. Avec des écouteurs classiques, l’état du bloc est souvent une variable fermée dans le scope du fichier JavaScript, difficile à partager entre deux blocs de la même page. Avec l’Interactivity API, l’état passe par un magasin nommé, accessible via store() côté script et via data-wp-context côté balisage, ce qui le rend consultable et modifiable depuis n’importe quel bloc portant le même espace de nom.
- Le rendu initial reste calculé côté serveur, ce qui préserve le référencement et l’affichage sans JavaScript.
- L’hydratation côté client ne réécrit pas le DOM depuis zéro : elle se contente de brancher les directives sur le balisage déjà présent.
- Un même magasin peut être partagé par plusieurs instances du bloc sur une même page, sans variable globale improvisée.
Migrer un bloc existant sans tout réécrire
La migration la plus rapide consiste à garder le rendu PHP ou le save existant, à y ajouter les directives nécessaires, puis à convertir le contenu du view.js en un appel à store(). Le fichier block.json ne change, lui, que d’une ligne, mais cette ligne conditionne tout le reste du fonctionnement.
En résumé
Déclarer supports.interactivity dans block.json n’est pas un simple interrupteur cosmétique : c’est le point d’entrée qui permet à WordPress d’associer le bon comportement d’hydratation à un bloc. Une fois cette ligne posée, la logique JavaScript du bloc gagne à être repensée autour d’un état partagé et de directives déclaratives plutôt qu’autour d’écouteurs impératifs épars, ce qui simplifie la lecture du code autant que sa maintenance dans la durée.
