Salut et bienvenue dans ce nouvel épisode de Code Garage, je m'appelle Nicolas Bondan-Vernard
et aujourd'hui on va parler de réactes natifs et on va essayer de comprendre ensemble son
fonctionnement.
Au craque natif, c'est sorti en 2005, ça a été développé par Facebook et depuis que
c'est sorti, on n'arrête pas de nous dire qu'il faut développer des applications
natives avec ce framework là.
On entend souvent parler des bénéfices de réactes natifs mais on nous explique assez
rarement comment fonctionne réellement le framework et surtout quelles sont ces différences
avec d'autres outils comme Cordova, Ionic ou un native script par exemple.
Moi quand j'ai commencé à découvrir ce framework, en fait d'après ce que je lisais,
je pensais que réactes natifs, ça permettait de compiler une application React, donc une
application web, en pure code natif sans aucun morceau de JavaScript restant à la fin.
Sauf qu'en fait j'avais complètement tort et on va décorer ensemble ce qui se passe
réellement sous le capot de réactes natifs.
Donc au final, si jamais, enfin et c'est le cas, mais si compilent pas le JavaScript
en langage mobile natif, qu'est-ce qui fait réellement au final ?
Donc on va prendre l'exemple d'une application native mais sans réactes natifs, d'une application
développée à partir, on va dire de langage web mais qui vont être disponibles nativement
sur un téléphone, c'est ce qu'on appelle des applications hybrides.
Des frameworks hybrides, il y a Cordova par exemple qui fait ça et qui est utilisé par
Ionic qui est aussi très connu.
Et bien tout simplement, ce genre d'outils génère une application native qui contient
simplement une webview.
Une webview, c'est un composant natif pour afficher une page web dans une application.
Et le code de votre application web, il va tourner dans cette webview.
C'est un petit peu comme si on avait une coquille vide.
Alors qu'est-ce qui se passe exactement ?
Eh bien on lance une application native dans lequel il y a ce composant natif qui affiche
du web et derrière, on va le mettre en plein écran, on va venir charger vos fichiers HTML,
CSS, JavaScript et ça va devenir une application presque comme si elle était native, sauf que
techniquement, il y a encore tout votre HTML, CSS et JavaScript.
Alors comment est-ce qu'on fait pour utiliser les API natives de l'appareil ?
De simplement, Cordova par exemple fournit un espèce de bridge, un pont qui permet d'écrire
des plugins en langage natif mais qui seront interfacés avec JavaScript pour accéder à ces
APIs de manière la plus simple possible.
Donc si on résume ça, quand l'application est lancée, la webview est chargée, le bridge
est rattaché à la webview et le bun de l' web, il est injecté dans la webview.
Donc là, on n'a pas une application native mais on a une application hybride majoritairement
web.
Comment ça se passe maintenant avec React Native ?
Donc avec React Native, la logique métier de l'application, elle tourne toujours dans
une machine virtuelle JavaScript.
Sauf que les composants graphiques, eux, ils sont plus gérés par une webview mais ils
sont transformés en code natif.
Donc concrètement, quand vous créez un élément texte en React Native, il sera transformé
en un élément UI label sous iOS et TextView sous Android.
Ensuite, le style du composant qui ressemble au CSS, il va être transformé pour correspondre
aux différents systèmes de layouts et de styling des différents OS.
React Native, lui, fournit une API uniformisée pour créer et gérer l'interface graphique
de vos applications à partir du code JSX qu'on connaît sous React.
Donc si on compare à Cordova qui lui fournit une webview et un bridge, React Native, il
fournit un bridge qui va permettre de gérer les appels aux appels natifs et aussi les
éléments graphiques natifs.
Donc une application React Native va l'exparer en trois différents threads, l'interface
graphique, le UI, le JavaScript et le bridge.
Et du coup, de cette manière-là, l'exécution du JavaScript qui est à synchrone n'est
jamais bloqué par l'exécution des appels au code natif qui sont pour la plupart synchrone.
Alors, est-ce que React Native porte bien son nom ? Peut-être pas vraiment parce que
c'est pas réellement une application purement native qui est déployée à la fin, mais
c'est une application hybride majoritairement native.
On avait du majoritairement web tout à l'heure, là c'est majoritairement native.
Mais c'est sûr que si la simple définition d'une application native c'est « tourne »
et peut être installée depuis un store sur un smartphone, effectivement, on peut parler
d'applications natives.
Pour conclure, j'ai vous dire deux petites choses.
C'est que d'abord, je vais vous mettre dans les notes de cet épisode un article qui a été
publié sur le blog Dubber qui explique pourquoi est-ce qu'après deux ans d'utilisation,
la société se sépare de React Native.
Alors, c'est pas justement pour dire que c'est bien, pas bien, etc.
Mais eux, en gros, ils donnent leur raison et donc c'est toujours intéressant de voir
les bons côtés, mais aussi potentiellement des côtés plus négatifs.
Et si jamais vous cherchez une alternative à React Native, il y a quelque chose qui s'appelle
Native Script qui a la même philosophie que React Native mais avec une implementation
technique différente.
J'espère que cet épisode vous aura plu, que vous aurez appris des choses et moi je
vous dis à très vite pour un prochain épisode.
Salut !