# L’Interactivity API : bâtir des blocs interactifs sans jQuery ni framework lourd > WordPress 6.5 stabilise l'Interactivity API. Directives déclaratives, hydratation légère et store partagé : de quoi repenser le JavaScript front de vos blocs. - Auteur : Clément Hadrot - Publié le : 2024-05-14 - Mis à jour le : 2024-05-14 - Catégorie : Blocs Gutenberg - URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/interactivity-api-blocs-interactifs-wordpress/ ## L’essentiel - Des directives HTML déclaratives remplacent le JavaScript impératif classique - Un store centralisé partage l'état entre plusieurs blocs de la page - L'hydratation reste légère, sans dépendance à un framework front externe Ajouter de l'interactivité à un bloc côté front a longtemps signifié une chose : écrire du JavaScript impératif, souvent avec jQuery, ciblant des sélecteurs CSS fragiles, sans lien clair entre le rendu PHP et le comportement client. WordPress 6.5, sorti ce mois-ci, change la donne avec la stabilisation de l'Interactivity API, un nouveau paradigme pensé spécifiquement pour les blocs. Cet article présente les concepts fondamentaux de cette API : les directives déclaratives posées directement dans le markup, le store qui centralise l'état, et la façon dont tout cela s'articule avec un bloc dynamique classique. ## Le principe : des directives plutôt que du JavaScript impératif Plutôt que de sélectionner des éléments du DOM après coup pour leur attacher des écouteurs d'événements, l'Interactivity API repose sur des attributs HTML déclaratifs, préfixés `data-wp-`, directement dans le markup généré par `render.php`. Le comportement du bloc devient lisible au premier coup d'œil, sans deviner ce qu'un script externe va lui appliquer plus tard. ```

Contenu détaillé de l'accordéon.

``` Chaque directive a un rôle précis : `data-wp-interactive` déclare le namespace du bloc, `data-wp-context` initialise un état local, `data-wp-on--click` attache un gestionnaire d'événement, et `data-wp-bind--*` synchronise un attribut HTML avec une valeur de l'état. ## Le store : la logique JavaScript associée > L'essentiel à retenir : Des directives HTML déclaratives remplacent le JavaScript impératif classique ; Un store centralisé partage l'état entre plusieurs blocs de la page ; L'hydratation reste légère, sans dépendance à un framework front externe Le comportement référencé par les directives (comme `actions.basculer`) est défini dans un store, créé avec la fonction `store()` du paquet `@wordpress/interactivity` : ``` import { store, getContext } from '@wordpress/interactivity'; store( 'wpmoderne/accordeon', { actions: { basculer() { const context = getContext(); context.ouvert = !context.ouvert; }, }, } ); ``` Ce fichier JavaScript, déclaré via `viewScriptModule` dans `block.json`, est chargé côté front uniquement, jamais dans l'éditeur. La fonction `getContext()` récupère l'état local associé à l'élément qui a déclenché l'action, ce qui permet à plusieurs instances du même bloc de coexister sur une page sans interférer les unes avec les autres. ## Une hydratation légère, sans dépendance lourde Contrairement à une hydratation complète à la React côté client, l'Interactivity API ne réhydrate que ce qui est nécessaire : le runtime observe les directives présentes dans le HTML déjà généré par le serveur, et ne recrée aucun arbre de rendu depuis zéro. Le poids du runtime reste volontairement contenu, sans dépendance à un framework front complet. Ce choix a une conséquence directe et recherchée : plusieurs blocs interactifs sur la même page, même de plugins différents, partagent le même runtime chargé une seule fois, plutôt que d'embarquer chacun leur propre copie d'une bibliothèque JavaScript. ## Déclarer le script dans block.json Pour qu'un bloc bénéficie de l'Interactivity API, sa déclaration doit préciser un module de vue et activer le support correspondant : ``` { "apiVersion": 3, "name": "wpmoderne/accordeon", "title": "Accordéon", "category": "widgets", "supports": { "interactivity": true }, "viewScriptModule": "file:./view.js", "render": "file:./render.php" } ``` La propriété `supports.interactivity` indique explicitement que le bloc s'appuie sur cette API, ce qui permet à WordPress d'optimiser le chargement du runtime uniquement sur les pages où un bloc interactif est réellement présent. ## Quand privilégier l'Interactivity API Cette approche convient particulièrement bien aux interactions front simples et courantes : accordéons, onglets, filtres de contenu, compteurs, formulaires de recherche instantanée. Pour des cas plus complexes, avec une logique métier front très riche, un framework JavaScript dédié reste parfois plus adapté, mais pour l'immense majorité des blocs de thème ou de plugin, l'Interactivity API couvre largement le besoin. - Accordéons, onglets, carrousels : la directive `data-wp-bind` suffit généralement à tout gérer. - Filtres et recherche instantanée : le store centralise l'état des filtres actifs, partagé entre plusieurs blocs. - Compteurs et formulaires courts : la logique reste lisible directement dans le fichier de store. > Le vrai changement n'est pas seulement technique : c'est de pouvoir relire le markup d'un bloc interactif et comprendre son comportement sans ouvrir un seul fichier JavaScript. C'est un vrai gain pour la maintenance à long terme. ## En résumé L'Interactivity API introduite avec WordPress 6.5 propose une façon nouvelle et cohérente d'ajouter de l'interactivité aux blocs, en s'appuyant sur des directives déclaratives directement dans le markup plutôt que sur du JavaScript impératif dispersé. Le store centralise la logique, l'hydratation reste légère, et plusieurs blocs peuvent coexister sur une même page sans conflit. Pour tout nouveau bloc nécessitant un comportement front, c'est désormais la première option à envisager avant de se tourner vers une solution plus lourde.