La gestion de l’interactivité dans WordPress

Depuis bien longtemps, pour ajouter de l’interactivité sur la partie front d’un site WordPress, il faut ajouter du JavaScript. Donc ajouter un fichier via wp_enqueue_script et écrire son code.

La plupart des développeurs WordPress utilisent jQuery pour ajouter de l’interactivité. Mais jQuery est un peu lourd (un peu moins dans la version 4). Parfois pas nécessaire car les navigateurs modernes ont bien homogénéisé la compatibilité JS.

Malgré tout, jQuery est omniprésent dans les sites WordPress. Il est d’ailleurs toujours obligatoire si vous utilisez WooCommerce.

Avec l’arrivée de Gutenberg, nous avons vu arriver React pour la partie éditeur. Mais vous le savez certainement, React n’est pas utilisé dans la partie front de WordPress. On se retrouve donc à gérer une partie éditeur en React et une partie front avec du code JavaScript classique (si nécessaire).

Bref, il est temps de changer cela. Il est temps de passer à une gestion de l’interactivité plus moderne. Le tout dans l’optique d’envoyer moins de code JavaScript au navigateur. Puisque la tendance actuelle est de réduire le poids des pages.

L’interactivité API

Le projet a été lancé début 2022 sous forme de plugin expérimental. Puis proposé en mars 2023 (voir la proposition) pour finalement être fusionné dans WordPress 6.5 en avril 2024 (voir l’annonce).

Pourquoi créer une librairie de plus pour gérer l’interactivité

Effectivement, l’équipe aurait pu choisir une librairie comme AlpineJS (très ressemblante à l’interactivité API) ou React (déjà présent dans WordPress). Mais l’équipe a préféré créer sa propre librairie pour plusieurs raisons :

• AlpineJS est facile a prendre en main mais ne gère pas la partie rendue serveur.
• React JS reste lourd et complexe. Il est également non compatible avec PHP.

De plus, il est préférable de créer une standardisation pour être utilisé dans l’écosystème WordPress et ne pas réitérer l’erreur de dépendre de jQuery. Si chaque développeur de bloc utilise sa librairie js, plusieurs dépendances sont envoyées dans le navigateur. En utilisant tous, l’interactivity API, on réduit drastiquement le code JS.

Il faut également penser à la rétrocompatibilité. Il est nécessaire de garantir que l’interactivité API fonctionne avec les sites existants qui utilisent potentiellement React, AlpineJS ou Vue.

Les avantages de l’interactivité API

• Block first et PHP first : S’adapte parfaitement à l’écosystème des blocks et permet d’avoir un rendu serveur via PHP
• Garantir la rétrocompatibilité : garantir de fonctionner avec les sites déjà existants et ne pas poser de soucis de compatibilité avec les autres librairies JS
• Déclaratif et réactif : permet de déclarer l’interactivité et de réagir aux changements de l’interface
• Envoyer moins de js : permettre d’utiliser une base de code légère (~17 ko)

Sous le capot

• Utilisation de Preact et de Preact Signals pour l’hydratation, la logique et la réactivité.
• Les directives sont comprises à la fois par PHP et JS
• La logique serveur est gérée par HTML_Tag_processor

Déclaratif contre impératif

Depuis le début du web, pour l’interactivité, nous écrivons le code sous une forme impérative. Nous ciblons des éléments, nous ajoutons des écouteurs d’événements et nous créons les interactions.

Le mode déclaratif permet de définir les éléments et de définir le comportement en une seule fois. Les éléments réagissent tout seul aux changements et se mettent à jour sans aucune action de notre part.

Comment marche l’interactivity API

Le code est donc sous forme déclaratif. On déclare des éléments en utilisant des directives.

On utilise principalement 2 éléments avec l’interactivity API : les directives et les stores.

Les directives

Les directives sont des attributs HTML qui permettent de déclarer l’interactivité.

 <button data-wp-interactive="myPlugin" data-wp-on--click="actions.logTime">
  Click Me!
 </button>

Le store est un objet qui contient les données et les actions.

store( "myPlugin", {
  actions: {
    logTime: ( event ) => {
      console.log( new Date() )
    },
  },
});

Le store se déclare avec un namespace et il est possible d’accéder à un store depuis plusieurs endroits. Un store peut être partagé entre des blocs. Et donc le state qu’il contient.

Le store n’est pas obligatoire puisque l’on peut utiliser simplement le context dans un élément.

L’important c’est de déclarer l’élément avec la directive data-wp-interactive="myPlugin". C’est ce qui rend l’élément repérable par l’API.

À noter que vous pouvez utiliser l’API d’interactivité avec n’importe quel code.
Ce n’est pas réservé aux blocs Gutenberg.
Il suffit de déclarer votre fichier JS sous forme de module et de définir la dépendance à l’API d’interactivité.

Imaginons que votre store est dans le fichier « path-to-my-script.js » :

add_action('wp_enqueue_scripts', function() {

    wp_register_script_module('my-slug', plugins_url('path-to-my-script.js',__FILE__) ,['@wordpress/interactivity'], false);

});

Rendu Serveur !

Alors oui, vous allez me dire : « Moi, je reste sur jQuery, parce que je maîtrise. » Ok, je peux le comprendre. Mais en réalité, la grande force de l’API d’interactivité, c’est la partie rendu serveur.

Oui, WordPress est capable de rendre un bloc déjà construit avec les données. À partir du moment où les données sont dans le contexte du bloc, PHP va rendre côté serveur tout le bloc. C’est juste magique.

Imaginez une API externe que vous appelez pour afficher des données. Eh bien, vous pouvez faire un appel côté serveur pour récupérer les données, les injecter dans le contexte du bloc et donc afficher le bloc avec les données directement dans la page. Avantage : vous pouvez ensuite prendre la suite côté front en JavaScript pour mettre à jour les données du contexte.

Conclusion

La première fois que j’ai entendu parler de l’interactivité API, j’ai été un peu sceptique. Malgré tout j’avais hâte de voir ce que cela pouvait donner.

Puis j’ai enfin eu un projet ou je pouvais l’utiliser. Un widget météo qui interroge une API et affiche les informations. J’avais même un minibloc météo à afficher dans le header.

Et bien, j’ai été agréablement surpris. Surtout quand j’ai compris le fonctionnement du rendu serveur. De plus j’ai pu utiliser le même store pour les 2 blocs.

J’ai donc décidé de faire une série d’articles et de vidéos sur l’interactivité API.

Pour vous montrer toute la puissance de cette librairie et comment l’utiliser dans vos projets WordPress.