# block.json et supports.interactivity : activer l’API sans JS impératif

> Comment déclarer supports.interactivity dans block.json pour brancher un bloc sur l'Interactivity API stable, sans écrire de gestionnaires d'événements classiques.

- Auteur : Clément Hadrot
- Publié le : 2024-12-23
- Mis à jour le : 2024-12-23
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/block-json-supports-interactivity-sans-js-imperatif/

## L’essentiel

- Une seule ligne dans block.json déclenche le rendu côté serveur adapté
- L'état vit dans un store, pas dans des variables JavaScript éparses
- Les directives HTML remplacent les écouteurs d'événements manuels

`{ "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é.

> L'essentiel à retenir : Une seule ligne dans block.json déclenche le rendu côté serveur adapté ; L'état vit dans un store, pas dans des variables JavaScript éparses ; Les directives HTML remplacent les écouteurs d'événements manuels

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.