Formation « Créer des blocs avec Gutenberg »

Approche JS standard vs approche moderne ESNext

Lecture : 3 minutes • 2

On peut utiliser 2 approches pour développer en JS : l’approche standard, avec du code natif, et l’approche ESNext, qui permet d’utiliser les nouvelles syntaxes JS. On va voir la différence entre chaque écriture et laquelle choisir.

Les 2 approches possibles

Lorsque l’on regarde les exemples officiels de la documentation Gutenberg, on aperçoit à chaque fois la version standard et la version ESNext.

Pour rappel ESNext désigne le langage le plus récent de Javascript, avec la syntaxe la plus évoluée. Elle permet en général de simplifier pas mal de choses pour le développeur, et d’avoir un code beaucoup plus lisible.

On va regarder ensemble un exemple fournit dans la documentation :

Exemples Gutenberg sur Github

Je vais plus particulièrement m’attarder sur l’exemple 3. Pour l’instant on ne va pas rentrer dans les détails du code, mais je vais simplement vous montrer les petites différences.

Voici la version standard :

JS
gutenberg-examples/03-editable/block.js

Cette version du code marche directement, sans avoir besoin d’être compilée. C’est du Javascript natif bien compris par les navigateurs.

Voici maintenant la version ESNext, qui aura besoin d’être compilée. Comme le dit le readme sur Github, il faudrait préalablement lancer npm install pour télécharger les dépendances puis npm run pour lancer le compileur.

JSX
gutenberg-examples/03-editable-esnext/block.js

La première chose en JS standard, c’est qu’il faut « protéger » son bloc en l’encapsulant dans une fonction. C’est pour cela que dès le début on commence par une parenthèse et une première fonction.

On remarque tout à la fin que des paramètres sont passés dans cette capsule : des variables globales comme window.wp.blocks.

En ESNext c’est plus simple et plus cohérent avec les autres langages de programmation :  on va importer les classes dont on a besoin et les dépendances dès les premières lignes.

On n’initialise plus les variables avec var comme on a pu le voir dans le précédent cours : on utilise à la place let ( qui a moins de portée et donc moins de souci de performances) ainsi que const pour tout ce qui ne changera pas, comme l’import d’une dépendance.

On remarque aussi que l’on a plus les appels de fonctions standards function( param ) { ... }, mais simplement la double flèche param => { ... }.

En ce qui concerne l’affichage de HTML dans le DOM, en JS standard on retourne un nouvel élément via la fonction el() qui nécessite plusieurs paramètres, alors qu’en ESNext on va simplement balancer le HTML à la ligne.

Pourquoi choisir ESnext ?

La première raison est le fait qu’en JS classique, il faudrait tout mettre dans un seul et même fichier. Alors même si ce n’est pas gênant lorsque vous n’avez qu’un seul bloc, cela peut très vite devenir très compliqué quand vous en aurez plusieurs.

Alors du coup il vaut mieux utiliser un compileur comme Webpack, et quite à l’utiliser, autant écrire en ESNext qui sera traduit automatiquement par Babel.

L’autre avantage d’ESNext est que l’écriture du code se révèle être plus propre, grâce à l’utilisation de classesd’imports qui font que l’on a moins besoin de jongler avec des parenthèses et accolades et qu’en général les notations sont beaucoup plus claires.

Et probablement le plus gros argument est que sans ESNext, on est obligé d’utiliser la fonction el() pour chaque balise de notre HTML généré ce qui est juste un casse-tête, alors qu’avec ESNext et React on écrit simplement du HTML natif !

Dans l’exemple ci-dessus, il n’y avait qu’une balise à écrire, l’exemple restait donc lisible. Mais imaginez maintenant faire un bloc contenant énormément de HTML. Ce serait tout de suite plus la galère.

Il suffit de comparer l’exemple 5 ESNext à la ligne 80 avec l’exemple 5 standard dès la ligne 67 pour s’en rendre compte !


Pour résumer ce cours : choisissez ESNext sans hésiter. Ce sera bien plus simple puis vous êtes déjà à jour sur le futur de Javascript.

La seule « difficulté » avec ESNext est de configurer le nécessaire pour compiler, mais comme on l’a vu, create-guten-block le fait automatiquement pour nous !

Et voilà ! Cette partie est terminée ! Dans le prochain chapitre nous allons étudier la structure du code du projet Gutenberg afin de mieux comprendre comment il est fait.

2

Questions, réponses et commentaires

  1. Laurent

    Le 9 janvier 2021

    Bonjour,

    Il suffit de comparer l’exemple 5 ESNext à la ligne 71 avec l’exemple 5 standard dès la ligne 45 pour s’en rendre compte !

    le premier lien est mort.

    Bàv et merci !

    1. Maxime BJ

      Le 9 janvier 2021

      Merci Laurent ! Et en plus, les numéros de lignes n’étaient plus bons non plus. Je viens de corriger.

Laisser un commentaire