Prérequis : dois-je maîtriser Js et React pour développer pour Gutenberg ?

La plupart des développeurs WordPress historiques maîtrisent PHP. Après tout, c’est la simplicité de PHP qui a permis à WordPress de se développer et attirer autant de curieux.

Même si WordPress reste majoritairement codé en PHP, l’arrivée de Gutenberg a chamboulé les répartitions des technologies et JavaScript commence à dominer le terrain.

D’ailleurs Matt Mullenweg, le créateur de WordPress, avait demandé aux développeurs d’apprendre le JavaScript en profondeur, lors de la conférence annuelle WordPress « State of the Word » en 2015.

Du coup, est-ce que tout ce JS va être un frein à l’apprentissage de la création de blocs ? Eh bien non ! Comme on va le voir dans ce cours, la barrière d’entrée n’est pas si haute que ce qu’on peut croire, et je vais vous donner toutes les billes pour réussir !

Les prérequis techniques de la formation

Pour suivre cette formation, vous devez avoir des bases en programmation, même si ces bases sont en PHP plutôt qu’en JavaScript.

Il faut aussi avoir une bonne connaissance du fonctionnement de WordPress sous le capot, et notamment les hooks.

Après, ce n’est pas trop grave si vous ne maîtrisez pas le JavaScript. Lorsque j’ai commencé à m’intéresser aux blocs en 2018, j’avais de très mauvaises bases en JS, car j’avais uniquement codé à l’aide de jQuery, comme beaucoup d’entre-nous.

Alors oui, React c’est une logique et une syntaxe différentes du JS classique, c’est d’ailleurs pour ça que le code a besoin d’être compilé afin d’être compris par le navigateur.

Mais vous allez voir que WordPress, comme d’habitude, propose des fonctions et des surcouches pour simplifier le code et améliorer l’expérience du développeur.

Et les documentations officielles sont plutôt complètes, avec plein d’exemples pour bien comprendre chaque concept.

Ce que l’on va aborder dans cette formation

Sur ce site, j’ai écrit la formation que j’aurais aimé suivre en 2018, lorsque j’ai commencé à apprendre les blocs. Je pars donc du principe que vous n’avez pas encore forcément toutes les compétences autour de React.

Dans la formation, on va du coup en profiter pour aborder les syntaxes modernes du JavaScript mais également les bases de React. Ainsi, vous serez rapidement à l’aise avec fondamentaux de JavaScript.

Avec WordPress, on respecte les principes de React, mais ils sont en général tous surchargés par l’éditeur de blocs. Donc peu importe si vous connaissez ou non les hooks React ou non, la gestion des états et des contextes…

Dans la formation, on va voir comment créer un bloc de base, rendre son contenu administrable, ajouter des réglages, lire des données du back-end…

Et d’ici la fin de la formation on verra même des études de cas de vrais blocs que j’utilise au quotidien : le bloc plugin, le bloc relationnel (un peu comme avec ACF) et le bloc sommaire.

Et surtout, on ne va pas s’embêter à configurer un compilateur JS car WordPress nous en fournit un prêt à l’emploi, qui s’appelle create-block. On verra en début de formation comment se préparer, notamment en installant Node.js sur notre ordinateur.

Pourquoi WordPress s’oriente vers le JavaScript ?

WordPress, au même titre que les applications web moderne, tend à adopter de plus en plus le JavaScript, afin de bénéficier notamment d’une interface plus fluide et plus réactive. On va voir pourquoi un tel revirement était nécessaire.

Le problème du tout « PHP »

A l’origine d’Internet les pages web étaient « imprimées » virtuellement par un serveur et affichées sur votre machine. A chaque nouveau clic, une nouvelle page était générée côté serveur puis envoyée par Internet jusqu’à votre ordinateur.

C’est encore sur ce modèle que se base aujourd’hui grandement dans les pages d’administration de WordPress (hors Full Site Editing).

Si je schématise le fonctionnement, ça donne ceci :

Lorsque vous demandez une page web, le client (c’est-à-dire votre machine), lance une requête HTTP via le navigateur vers le serveur. Celui-ci va générer la page demandée via PHP / MySQL et retourner une page HTML.

Autant ce fonctionne est adapté pour une page web, autant ça ne l’est plus du tout pour une application web : imaginez qu’à chaque action sur Facebook, ou qu’à chaque nouveau tweet sur votre mur, il y ait un rechargement de page. 

C’est le gros problème de l’interface d’administration de WordPress : chaque menu demande un rechargement complet de l’interface. C’est long, et lourd, d’autant plus si on ajoute trop d’extensions.

Bénéfices de WordPress en mode « web app »

Maintenant, lorsqu’on jette un œil aux nouveaux menus de WordPress, dans Apparence > Éditeur, c’est complètement différent :

Lorsque vous naviguez entre les différentes rubriques, le chargement des éléments est quasiment instantané : il n’y a pas de rechargement entre chaque clic.

Tout est plus fluide, et c’est rendu possible grâce à React et à des requêtes Ajax vers l’API REST de WordPress !

Cette fois, c’est JavaScript qui est responsable de générer l’affichage de l’interface, et de gérer son côté interactif.

Le serveur n’a donc plus besoin de générer une page HTML pour chaque action, et s’occupe simplement de distribuer des données brutes au format JSON.

Javascript peut alors créer dynamiquement l’affichage en fonction des données, et mettre à jour le rendu si d’autres données arrivent, sans rechargement de page.

Si je schématise, en me basant sur le précédent schéma, on obtient maintenant ceci :

Le bénéfice ici est le gain de temps de chargement ainsi que l’économie de ressources serveur. Javascript peut alors adapter le rendu de la page en temps réel en fonction des informations reçues.

Pourquoi jQuery ne suffit plus ?

Librairie phare des années 2010, jQuery est utilisé encore aujourd’hui dans une grande majorité des projets web, dont WordPress.

Mais la librairie qui rendait ludique le Javascript ne suffit plus aujourd’hui à combler les besoins d’un web qui a grandement évolué.

Le principe de jQuery

Le principe de jQuery est de manipuler le DOM (Document Object Model), c’est-à-dire les éléments d’une page web, ou la transcription du HTML en objets avec lesquels on peut interagir.

Prenons cet exemple tout simple :

Sur le principe on commence toujours par cibler un élément, grâce à un sélecteur CSS et à l’objet $ (qui fait référence à l’objet jQuery).

Et ensuite on assigne une action ou un événement derrière. Pour la première ligne : on assigne un écouteur d’événement sur le clic de la souris.

Lorsque cet élément sera cliqué, on lancera la fonction qui suit, qui va aller cibler cette fois le message pour lui injecter un texte et le faire apparaître.

Cette approche semble à priori plutôt sexy mais atteint ses limites au niveau d’une application web complète.

Les limites de jQuery

On va maintenant prendre l’exemple d’une application de gestion de tâches simple, où l’on peut créer des tâches et des listes de tâches. On pourra valider une tâche, la supprimer, en ajouter une nouvelle ainsi que créer et supprimer des listes.

Voici un schéma :

Dans le coin supérieur droit, on voit qu’il y a le total des tâches accomplies, et des tâches à accomplir. Une fonction permet de compter ces tâches.

En jQuery, lorsqu’une tâche est ajoutée / validée / supprimée, ou lorsque une liste entière est supprimée (qui a pour effet de supprimer plusieurs tâches) alors il faut relancer manuellement la fonction de comptage des tâches.

On commence à se rendre compte qu’il devient très facile à ce point d’oublier d’appeler cette fonction.

C’est là tout le problème : jQuery manipule le DOM, là où React est conçu pour manipuler des données.

C’est pour ça que React connait un succès sans cesse grandissant depuis 2013, et qu’il est désormais utilisé dans la majorité des applications web modernes.

React et l’approche par composants

Jetons maintenant un œil à React : l’approche est complètement différente. Cette fois-ci le but est de créer des composants, qui fonctionnent en autarcie les uns vis-à-vis des autres.

Une application est donc découpée en plusieurs composants qui peuvent partager des données mais possèdent leurs propres fonctions et valeurs.

Voici un exemple type de composant React :

Un composant React, c’est au final ni plus ni moins qu’une fonction JS qui retournera du HTML.

Comme vous pouvez le voir, on assigne la fonction toggleTask directement sur le onClickde chaque tâche, comme on le faisait dans les premières années de Javascript !

La première grosse différence est le fait que contrairement à jQuery, on arrête de cibler à tout va des éléments via le sélecteur $('.quelquechose').

Ensuite, le composant gère à la fois ses données, sa logique métier (le code JS) mais en plus le rendu du composant en HTML, dans le return() de la fonction.

Chaque composant jouit d’une totale indépendance vis-à-vis du reste de l’application.

L’avantage, c’est que c’est React qui gère ensuite la mise à jour de ces composants dans le DOM, pas vous. Ainsi, si la liste des tâches envoyée à ce composant venait à changer, React relancera automatiquement le rendu de ce composant.

Enfin, pour communiquer avec le serveur, on peut envoyer des requêtes Ajax via l’API REST de WordPress pour lire et écrire les données. Et le tour est joué !

Jusqu’ou ira la part de JS dans WordPress ?

Si on jette un œil au répertoire Gutenberg sur Github, on observe que le JS (+ Typescript) occupe plus de 80% des parts des technologies utilisées par l’éditeur de blocs :

TypeScript est une version de JavaScript avec une prise en charte des types de données, et créé par Microsoft. C’est un métalangage qui a besoin d’être compilé.

On n’en utilisera pas dans la formation car avec les surcouches de WordPress, on n’en aura pas besoin. Mais c’est une bonne pratique lorsque vous créez une application web de toutes pièces.

---

Dans ce cours, on a vu qu’il n’y avait pas besoin d’être un expert JS pour se lancer dans cette formation, mais on a vu également que le JS était en train de s’imposer

Cette introduction à Gutenberg est maintenant terminée. Dans le prochain chapitre, on passe au concret ! On va notamment préparer notre environnement pour créer nos blocs.