Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Brondin-Bernard et aujourd'hui on va parler d'une confusion que je vois beaucoup de développeurs et développeurs se faire quand on touche à React
et cette confusion c'est le lien qu'il y a entre React et le JSX.
Alors quand on débute évidemment on a l'impression que tout fonctionne un peu par magie,
d'autant plus que React est arrivé avec le JSX.
L'un et l'autre sont arrivés ensemble donc pour beaucoup de gens le React et le JSX sont indissociables
et pour beaucoup de gens le JSX est interprété par React et pourtant ce n'est pas du tout le cas et on va voir pourquoi.
Donc je ne vais pas revenir dans le détail sur ce qu'est JSX mais globalement ça veut dire JavaScript XML
et c'est une syntaxe donc qui a été introduite comme je l'ai dit par React pour écrire des interfaces utilisateurs
de manière un petit peu plus expressive qui soit à la fois très proche du HTML,
même si ce n'est pas exactement du HTML, mais qui va pouvoir aussi inclure du JavaScript directement dans du template.
Mais c'est à la fois ni du HTML valide ni du JavaScript valide.
Il n'y a aucune version du moteur JavaScript dans le navigateur qui permet de comprendre
ce qui est même juste un H1 Hello World qui serait dans un template JSX.
Eh bien oui là celui-là est valide en HTML mais en réalité ce n'est pas du tout comme ça qui va être utilisé.
Je ne vais pas rentrer dans le détail mais on va voir comment est-ce que JSX et React fonctionnent ensemble.
En fait React, il fonctionne avec des fonctions toutes simples et notamment une qui est la base de tout qui s'appelle Create Elements.
Create Elements, il prend plusieurs paramètres. Il va notamment prendre le type d'éléments à créer qui va être par exemple H1 dans le cas de ce que j'ai dit.
Ensuite ça va être un objet qui va contenir toutes les props que l'on va passer à cet élément ou à ce composant.
Et ensuite on va avoir tout simplement la liste des enfants que va contenir cet élément.
Alors on ne va pas envoyer une liste, on ne va pas envoyer un tableau mais simplement on va continuer d'envoyer des paramètres à cette fonction.
Tant qu'on a des enfants, on fait une nouvelle virgule et on a un nouveau enfant.
Voilà sur quoi est basée l'entierté de la création de l'arbre, du virtualdom.
On en a parlé dans un épisode précédent, si jamais le concept de virtualdom vous ne le comprenez pas complètement, allez écouter cet épisode juste après celui-ci.
Grosse au modo, grâce à quoi est créé le virtualdom, puis est généré le DOM.
Mais évidemment quand on écrit du React, on n'écrit jamais React.createElement et on écrit simplement du JSX.
Et ce JSX va avoir besoin d'un compilateur ou plus précisément d'un transpilateur pour passer de cette version JSX de cet espèce de template
à l'appel de React.createElement qui va parfois évidemment quand vous avez un arbre avec plusieurs éléments par enfant,
React.createElement va appeler un autre createElement qui va lui-même appeler un createElement etc.
Mais alors qui est chargé de passer par exemple de ce template avec notre H1EloWorld qui est du JSX vers les React.createElement ?
Ça dépend de quand est-ce que vous avez commencé React puisque à l'origine React fonctionnait avec Webpack et plus particulièrement Babel
et Babel était justement chargé de faire cette transpilation mais depuis quelques années Babel étant beaucoup trop lent et beaucoup trop lourd,
on l'utilise de moins en moins et aujourd'hui quand vous créez un nouveau projet React, vous utilisez sûrement le Commonline de VIT
et donc aujourd'hui alors c'est pas réellement VIT puisque VIT il ne fait pas de transpilation, VIT c'est un serveur de dev local
avec plein de fonctionnalités très très cool mais il va utiliser ESBuild et c'est ESBuild qui va prendre du JSX
pour le transformer en vrai JavaScript qui lui va être utilisable avec React.
Alors ESBuild de base il fait plein de choses, c'est un bundler aussi, ça permet de minifier du code, de le bundler, de le transpiler évidemment aussi
d'une version de JavaScript vers une autre ou plein de choses comme ça mais il permet également de transpiler du JSX nativement vers du JSX
ça permet donc plein de choses, ça veut dire que vous pouvez très bien utiliser du JSX avec éventuellement d'autres frameworks
mais vous pouvez utiliser du JSX tout seul ou dans votre back-end ou plein de choses, il y a plein de choses possibles
je vous prends un petit exemple que moi j'ai réalisé dans une application pour un client il y a quelques temps
et on utilisait simplement des templates JSX qui étaient stockés sur notre serveur et que l'on compilait directement avec ESBuild
sur le serveur pour le renvoyer à notre application VJS et donc on pouvait charger des composants VJS de manière asynchrone
qui nous étaient directement renvoyés par le serveur mais compilés également par le serveur.
Alors là vous dites potentiellement ça peut ressembler aussi à ce que fait un petit peu Next.
Alors Next c'est un tout petit peu plus particulier puisqu'il n'utilise pas ESBuild mais il utilise S-Doulev C.
C c'est aussi un transpiler alors il s'appelle SWC puisque c'est Simple Web Compiler je crois ou speedy Web Compiler
bref, un des deux c'est pas très grave. Il fonctionne à peu près comme ESBuild à la différence que ESBuild est écrit en go
et que SWC est écrit en Rust mais il a des vraies différences notamment il est plus ou moins compatible avec les plugins PaBel
donc ça permet plus facilement de porter un projet qui était écrit avec Babel vers un projet avec SWC
mais il va également faire moins de choses que ESBuild puisqu'il ne va pas faire de bundling
donc il va pas minifier, il va pas rassembler vos fichiers en un seul, il va faire de la transpilation ce qu'on peut appeler 1 pour 1
donc il va prendre un fichier et il va le transformer vers un autre fichier toujours 1 pour 1
mais évidemment dans un autre langage, dans un autre format etc.
Et donc SWC il l'utilisait principalement pour Next et pourquoi ?
Tout simplement parce que ça permet de faire du chargement de composants à la volée
ça permet d'avoir plein de choses côté serveurs dont on n'aurait pas forcément besoin côté front
et donc avec React, ESBuild qui est en général plus performant, on va l'utiliser directement là-dessus
Alors si vous devez retenir qu'une seule chose de cet épisode c'est de bien se rappeler que React ne comprend pas le JSX
il a besoin que le code JSX soit transformé vers un code JavaScript qui va utiliser React pour pouvoir l'utiliser
La transformation elle était faite par Babel avant, maintenant c'est soit ESBuild au travers de VIT soit SWC
et évidemment vous pouvez utiliser React sans JSX même si c'est beaucoup plus fastidieux et je le conseille pas forcément
mais pour apprendre et comprendre comment ça fonctionne ça peut être intéressant de tester comme ça
J'espère que cet épisode vous aura appris quelque chose
moi je vous retrouve la semaine prochaine pour un prochain épisode du podcast évidemment
mais passez faire un tour sur code-y-re-h.com puisque on est en train de sortir un cours complet sur le React
alors même s'il n'est pas encore sorti vous pouvez vous inscrire à la newsletter pour avoir une info dès qu'il sort
et surtout on fait des promotions exclusives réservées aux membres de la newsletter
donc si vous voulez avoir le cours le moins cher possible vous inscrivez avant la sortie du cours, vous recevez le petit mail
en général on fait une newsletter par semaine simplement pour vous tenir au courant des ressources qu'on sort, podcast, articles etc
donc vous n'allez pas bombarder de mail
et surtout si vous pouvez prendre le temps de mettre 5 étoiles à ce podcast que soit sur 10h Spotify, Apple Podcast, peu importe
vraiment ça aide beaucoup à remonter dans les classements
et moi je vous retrouve la semaine prochaine pour un prochain épisode
prenez soin de vous, salut !