Agence WordPress Be API | Actualités | WordPress | L’interactivité sur WordPress: une nouvelle API pour l’éditeur de blocs
,

L’interactivité sur WordPress: une nouvelle API pour l’éditeur de blocs

Publié le

par

Lors du dernier WordCamp Europe, nous avons plongé dans les coulisses de l’éditeur de blocs WordPress pour explorer une nouveauté en cours de développement : l’API d’interactivité. Cette nouvelle brique vise à améliorer un aspect encore trop peu considéré des blocs : leur comportement côté front, c’est-à-dire la façon dont ils se manifestent visuellement pour l’utilisateur final.

L’interactivité, dans ce contexte, désigne la capacité d’un bloc à répondre immédiatement à une action utilisateur. Pensez à un bloc accordéon qui s’ouvre, un sous-menu qui s’affiche ou encore à une modification des quantités d’un panier sur un site e-commerce.

Ces interactions étaient jusqu’alors laissées à l’appréciation de chaque développeur, entrainant plusieurs challenges techniques sur lesquelles nous reviendrons plus tard dans cet article. Mais avant cela, commençons par rappeler l’intérêt pour le CMS open source WordPress de s’orienter vers la création de nouvelles API.

Le rôle essentiel des API dans WordPress

WordPress propose une vaste gamme d’Interfaces de Programmation Applicative, plus connues sous l’acronyme anglais API.

Leur intérêt ? Standardiser de nombreux aspects du code que les développeurs d’extensions et de thèmes WordPress pourraient avoir à écrire. Au lieu de repartir de zéro à chaque fois, ils bénéficient d’une palette de ressources prédéfinies, comme des fonctions ou des classes.

Voici les avantages clés :

  • Simplicité et Clarté : Les codes requis sont non seulement standardisés, mais aussi bien documentés, les rendant accessibles à tous les développeurs utilisant WordPress.
  • Sécurité et Performance : Ces deux aspects sont gérés par défaut par les API, qui bénéficient en plus du regard expert de la communauté qui participe au développement du cœur de WordPress.
  • Flexibilité : Les API peuvent être ajustées et enrichies au fil du temps, offrant toujours plus de possibilités, de correctifs et d’améliorations, sans contraindre les développeurs à revoir constamment leur code.

Les API WordPress ne sont pas seulement des outils pour faciliter la vie des développeurs. Elles incarnent la vision de WordPress pour un développement web plus efficace, sécurisé et évolutif.

Renforcer l’interactivité

L’éditeur de blocs WordPress offre déjà une large gamme d’outils permettant une édition riche des contenus en backoffice. Mais jusqu’à récemment, les développeurs désireux de proposer des rendus complexes et/ou interactif sur la partie front devaient concevoir leur propre solution, souvent sans lignes directrices claires ni bonnes pratiques établies. Cette hétérogénéité de solutions pouvait altérer la performance, l’accessibilité et la sécurité des pages.

L’introduction de l’éditeur de site, ou « Full Site Editing » (FSE), a mis ce problème en lumière, avec sa construction à partir de blocs. En réponse à cela, un groupe de développeurs a entrepris de concevoir une solution : leur réflexion a donné lieu à un article détaillé, présentant cette nouvelle API, ainsi qu’un site de démonstration. Son déploiement comporte des défis, puisqu’elle doit être fonctionnelle côté serveur lors du rendu de la page et côté navigateur où l’utilisateur va interagir avec les blocs.

Pour cette API, les développeurs ont établi des critères essentiels, tels que :

  • Une intégration fluide avec la logique actuelle des blocs, accessible côté serveur en PHP,
  • Une compatibilité avec le cœur de WordPress et les extensions existantes, y compris tous les crochets pour manipuler le rendu HTML,
  • Une mise en œuvre optionnelle pour la maintenance ou la création de blocs, avec une adoption progressive selon les besoins,
  • Une influence minimale sur la performance des pages web.

D’autres conditions ciblent spécifiquement les développeurs d’extensions.

Cette nouvelle API présente le potentiel de transformer la dynamique des blocs face aux interactions des utilisateurs. Elle permet aux développeurs de se focaliser sur leurs objectifs métiers, tout en simplifiant la mise en place des fondements techniques nécessaires à ces ambitions.

Pour les utilisateurs finaux

Bien que conçue initialement pour optimiser le quotidien des développeurs, cette nouvelle API présente des bénéfices tangibles pour tous, avec en tête de liste une amélioration significative des performances et une consolidation de la sécurité.

Comme mentionné précédemment, les avantages offerts par les APIs sont vastes.

Concernant l’API d’interactivité, ses principaux atouts pour les utilisateurs finaux se distinguent par :

  • Une navigation plus rapide et fluide: Avec moins de ressources à charger et une optimisation maximale, les utilisateurs bénéficient d’un temps de chargement réduit et d’une meilleure réactivité, garantissant une expérience optimisée.
  • Qualité du code : Le socle programmatique est revu et approuvé par une communauté de développeurs soucieuse de sa performance, sa sécurité et sa capacité d’évolution. Un code de qualité se traduit par moins de bugs, de défaillances et d’interruptions – tout cela contribuant à une navigation plus fluide et plus sécurisée.
  • Interopérabilité : Cette nouveauté assure une harmonie entre différents éléments d’une page, permettant des d’interactions plus intelligentes et intuitives. Que ce soit un widget météo qui s’adapte en fonction de votre localisation ou une intégration e-commerce qui suggère des produits en fonction de votre navigation, cette interopérabilité enrichit considérablement l’expérience utilisateur.

Pour les développeurs

Cette nouvelle API n’est pas encore stabilisée, les exemples de codes sont donnés à titre d’exemple et vont très probablement être modifiés dans le futur.

L’un des points forts de cette nouvelle API en termes de développement est d’être réactive. On y retrouve les éléments qui font la force de la philosophie de React: des “interfaces“ dérivées d’un état précis. Le développeur décrit la façon dont l’interface doit s’afficher et comment son état doit être modifié et la librairie sous-jacente s’occupe de détecter les événements, mettre à jour l’état et muter l’interface en conséquence. C’est là toute la philosophie de l’éditeur de blocs.

À l’inverse, pour ajouter de l’interactivité sur des éléments d’un site, il était souvent question de passer par jQuery (ou du JavaScript natif). Avec cette approche, le développeur est chargé de la gestion du rendu de l’interface, de la détection des événements, de la mise à jour de l’état et de la modification de l’interface. Plus les éléments à mettre à jour sont nombreux, plus cette méthode révèle ses faiblesses.

Un autre impératif crucial pour cette API était sa compatibilité avec le rendu côté serveur. Le HTML produit par le serveur doit constituer le fondement du côté client, sur lequel une dimension interactive est superposée. Ce HTML ne doit pas être intégralement remplacé. D’un point de vue performance et SEO, cela garantit l’affichage instantané d’un contenu tangible, évitant un effet « page vierge » pendant le téléchargement et l’exécution du JavaScript nécessaire au rendu. Cela assure également que toute modification apportée au HTML côté serveur est conservée, comme l’ajout éventuel de classes CSS.

Pour la composante « réactive », l’équipe a opté pour la bibliothèque Preact, qui, tout en étant plus compacte, emprunte largement aux concepts de React. C’est cette couche qui orchestre la mise à jour des interfaces en fonction des interactions des utilisateurs.

La véritable innovation réside dans la méthode d’intégration des éléments interactifs, réalisée par le biais de directives HTML. Ce principe s’inspire de ce qui est fait par la librairie AlpineJs.

Via ce système, on peut facilement enrichir un code HTML pour lui permettre de déclencher des actions ou de réagir à des changements (des « effets »).

<div
data-wp-context='{ "isOpen": false }'
data-wp-effect="effects.logIsOpen"
>
<button
data-wp-on--click="actions.toggle"
data-wp-bind--aria-expanded="context.isOpen"
aria-controls="p-1"
>
Toggle
</button>

<p id="p-1" data-wp-show="context.isOpen">
This element is now visible!
</p>
</div>

Ces directives vont permettre de lier les éléments HTML avec la partie réactive en JavaScript

import { store } from "@wordpress/interactivity";

store({
actions: {
toggle: ({ context }) => {
context.isOpen = !context.isOpen;
},
},
effects: {
logIsOpen: ({ context }) => {
// Log the value of `isOpen` each time it changes.
console.log(`Is open: ${context.isOpen}`);
},
},
});

Dans l’exemple ci-dessus (issu de l’article de présentation de l’API interactivé publié sur le bloc Make Core), on a un « bloc » fictif qui fonctionne comme un accordéon.

Pour résumer le fonctionnement, lorsque l’utilisateur clique sur l’élément bouton, celui-ci vient changer la valeur de l’état isOpen. Au moment où cette valeur change, cela va avoir pour effet (d’où le nom « effect » utilisé en anglais) d’afficher ou de masquer l’élément paragraphe.

Tout ce fonctionnement est porté par les directives visibles dans le HTML comme data-wp-on--click, data-wp-show et qui font le pont avec le code JavaScript.

L’article sur le Core est très bien fait et présente plus complète du mécanisme et des directives en faisant le parallèle avec React.

Conclusion

Ainsi, l’éditeur Gutenberg continue d’évoluer et de s’améliorer. Cette nouvelle API est une proposition très intéressante pour faciliter le développement d’expériences interactives via les blocs. Les développeurs qui ont contribué à sa création ont poussé la réflexion pour proposer une solution s’intégrant parfaitement dans l’écosystème WordPress existant, en restant le plus léger possible.

Des développeurs travaillant sur le projet Gutenberg ou WooCommerce ont déjà commencé à faire évoluer leurs blocs pour profiter des nouvelles possibilités qu’offre cette API. Il a y fort à parier qu’elle va continuer d’évoluer – mais il est intéressant de voir qu’elle est déjà exploitée.

Si vous souhaitez suivre les développements, un changelog est disponible pour suivre les évolutions de l’API et elle a sa propre catégorie dans la partie Discussions du projet Gutenberg.