‫Jonas : Comme dernière partie de cette section, parlons
‫de la façon dont NODE. Les modules JS fonctionnent réellement
‫dans les coulisses.
‫Tout d'abord dans le NODE. Système de module
‫JS, chaque fichier JavaScript est traité comme un module distinct.
‫Et nous avons déjà joué un peu avec
‫les modules dans l'intersection,
‫'particulièrement en utilisant la fonction require
‫et en exportant les données des modules.
‫Voilà donc les principes fondamentaux des modules Common JS, qui constituent
‫le système de modules utilisé par le nœud.
‫Parce que cela fonctionne particulièrement bien sur le serveur.
‫Maintenant, il y a aussi le script natif ECMA ou
‫le système de module
‫ES que vous connaissez peut-être déjà, «
‫surtout si vous avez suivi mon cours
‫JavaScript, ou si vous avez récemment
‫écrit du JavaScript sur le front-end.
‫Ce système de module ES dont je parlais a été
‫développé pour fonctionner dans le navigateur en utilisant la syntaxe import export.
‫Donc, je voulais juste préciser qu'il s'agit de
‫deux systèmes de modules différents que vous verrez
‫dans des situations
‫différentes, alors ne soyez pas confus.
‫Il y a également eu des tentatives pour implémenter des
‫modules ES natifs dans NODE. JS, 'en utilisant
‫spécialement des extensions de fichiers
‫comme . mjs.
‫Mais jusqu'à présent, ce n'est
‫pas vraiment devenu une chose populaire à utiliser.
‫Donc, à moins que vous
‫ne regardiez ce cours
‫dans un avenir lointain, vous utiliserez
‫probablement toujours le système Common JS avec node.
‫Maintenant, vous vous demandez peut-être pourquoi dans NODE. JS chaque
‫module a en fait accès à
‫la fonction require afin d'importer
‫des modules en premier lieu.
‫Droit?
‫Je veux dire, ce n'est pas une fonction JavaScript standard.
‫Donc, d'où cela vient-il?
‫Et comment ça marche exactement dans les coulisses ?
‫Eh bien, découvrons.
‫Donc, la question ici
‫est, ce qui se passe chaque
‫fois que nous demandons un module en appelant
‫la fonction require avec un nom de module, est l'argument.
‫En guise d'aperçu très
‫général, les étapes suivantes sont exécutées dans les coulisses.
‫Tout d'abord, le chemin d'accès au module
‫requis est résolu et le fichier est chargé.
‫Ensuite, un processus appelé wrapping se produit après
‫cela, le
‫code du module est exécuté
‫et les exportations de module sont renvoyées.
‫Et enfin, tout le module est mis en cache.
‫Examinons maintenant chaque étape plus en détail.
‫Tout d'abord, comment node sait-il quel fichier charger lorsque
‫nous avons besoin d'un module ?
‫Parce que rappelez-vous, nous pouvons en
‫fait charger trois types de modules différents.
‫Les modules de base
‫de Node, nos propres modules ou des modules tiers de npm comme
‫express qui est le framework de nœud que nous
‫allons utiliser pendant la majeure partie du cours.
‫Ce processus est donc connu sous le nom de résolution du chemin du fichier.
‫Et voici comment cela fonctionne.
‫Lorsque la fonction require reçoit le nom du
‫module en entrée,
‫elle essaiera d'abord de charger un module principal avec ce nom.
‫Comme par exemple le module http.
‫Il trouvera automatiquement un chemin vers ce
‫module, puis le chargera.
‫Maintenant, si le chemin commence par un point,
‫ou deux points,
‫cela signifie qu'il s'agit d'un module de développement.
‫Parce que nous indiquons le chemin relatif de notre fichier.
‫Le nœud essaiera donc de charger ce fichier,
‫mais s'il n'y a pas de fichier avec ce
‫nom, il cherchera un dossier à
‫la place et chargera l'index. js s'il se trouve dans ce dossier.
‫Donc, dans cet
‫exemple, il essaiera de charger lib/controller. js.
‫N'oubliez pas que nous pouvons supprimer le point
‫js lorsque vous avez besoin d'un module.
‫S'il n'y a pas de fichier à
‫ce chemin, il
‫essaiera alors d'ouvrir index. js du dossier lib/controller à la place.
‫Avoir du sens ?
‫Et enfin, si le module requis
‫n'est ni un
‫module de base, ni un module
‫de développeur, node supposera qu'il s'agit d'un module de npm.
‫Et rappelez-vous, sur un module que nous chargeons à partir de npm, nous n'avons
‫en fait pas besoin d'écrire le chemin lorsque nous en avons besoin.
‫Juste le nom du
‫module, juste la façon dont il fonctionne sur un module principal.
‫Ainsi, ces modules tiers sont stockés dans un
‫dossier de module de nœud,
‫de sorte que le nœud entrera dans ce dossier et
‫essaiera d'y trouver un module, puis de le charger.
‫Et bien sûr, si le fichier ne peut être trouvé
‫nulle part, une erreur est générée et l'exécution
‫de l'application est arrêtée.
‫Ensuite, une fois le module
‫chargé, le code du module est enveloppé dans une
‫fonction spéciale qui nous donnera accès à quelques objets spéciaux.
‫C'est donc à cette étape que la magie opère.
‫C'est ici que nous obtenons la réponse à
‫la question, d'où vient réellement la fonction require et
‫pourquoi y avons-nous accès ?
‫C'est parce que le temps d'exécution
‫de nodejs retire le
‫code de notre module et le met dans
‫l'expression de fonction immédiatement invoquée, ou IIFE que vous pouvez voir ici.
‫Ainsi, le nœud n'exécute pas
‫directement le code que je réécris dans un fichier,
‫mais à la place, la fonction wrapper qui
‫contiendra notre code dans son corps.
‫Il transmet également les objets requis par les
‫experts au module, au nom de fichier et au répertoire.
‫C'est pourquoi, dans chaque module, nous
‫avons automatiquement accès à
‫des éléments tels que la fonction require.
‫Ce sont donc essentiellement des
‫variables globales qui sont injectées dans chaque module.
‫Maintenant, en faisant cela, node réalise deux choses très importantes.
‫Tout d'abord, bien sûr, donner aux développeurs l'accès à
‫toutes ces variables dont nous venons de parler,
‫ce qui est très utile.
‫Deuxièmement, il garde les variables de niveau supérieur que
‫nous définissons dans nos modules privées.
‫Il est donc limité au module
‫actuel au lieu de tout divulguer dans l'objet global.
‫Imaginez donc une
‫seconde que nous ayons déclaré une variable x dans l'un
‫de nos modules, puis inclus un module npm qui utilisait
‫également une variable appelée x.
‫Sans ce mécanisme, notre
‫propre variable serait alors remplacée et l'ensemble
‫de l'application ne fonctionnerait tout simplement pas.
‫Ainsi, chaque module ayant sa portée privée est
‫absolument crucial et est réalisé grâce à
‫cette astuce astucieuse consistant à envelopper notre code dans
‫cette fonction spéciale.
‫Jetons maintenant un coup d'œil rapide à chaque
‫objet que notre module obtient.
‫D'abord la fonction require, que
‫nous connaissons déjà.
‫Ensuite, il y a un objet
‫module, qui n'est qu'une référence au module courant
‫et qui pour nous est
‫le plus important lorsqu'il s'agit d'exporter des données.
‫La même chose s'applique à l'objet de l'export
‫dont nous allons parler dans un instant.
‫Enfin, il y a les
‫variables de commodité file name et dir
‫name qui contiennent simplement le chemin
‫absolu vers le fichier
‫du module courant ainsi que le nom du répertoire courant.
‫Et c'est ainsi que fonctionne l'étape d'encapsulation du chargement d'un module.
‫Ensuite, le code dans le module, ou pour
‫être plus précis, dans
‫la fonction wrapper du module, est en
‫fait exécuté par le NODE. Exécution JS.
‫Donc, rien d'extraordinaire ici.
‫Jusqu'à ce point,
‫la fonction require a été appelée avec un nom de
‫module comme argument, le chemin
‫d'accès au fichier du module a été résolu en fichier chargé,
‫tout le code a été encapsulé dans la fonction
‫wrapper qui a ensuite été exécutée.
‫Maintenant, il est temps que la fonction
‫require renvoie réellement quelque chose.
‫Et ce qu'il renvoie, ce sont les exportations du module requis.
‫Ces exportations sont stockées dans le module. exporte des objets.
‫Cela pourrait ressembler un peu à ça.
‫Donc, encore une fois, dans chaque module, nous
‫pouvons exporter des variables, qui seront finalement renvoyées par la fonction require.
‫Et nous le faisons en affectant des variables au module. exportations ou simplement à des exportations où
‫il ne s'agit que
‫d'un pointeur vers le module. exportation.
‫Nous le ferons en pratique dans la
‫prochaine vidéo, car je sais que cela semble un peu
‫déroutant quand je le dis juste comme ça.
‫Quoi qu'il en soit, voici ce que
‫vous devez savoir pour savoir quand utiliser le module. exporter ou simplement exporter.
‫Donc, si tout ce que vous voulez faire est d'exporter une seule
‫variable, comme une classe ou une fonction,
‫vous utilisez généralement module. exporte et définissez-le égal
‫à la variable que vous souhaitez exporter.
‫Tout comme dans cet exemple.
‫D'un
‫autre côté, si vous cherchez à exporter plusieurs variables
‫nommées comme plusieurs fonctions, par exemple,
‫vous devez les
‫créer en tant que propriétés de l'objet d'exportation.
‫Par exemple, si nous faisions un module de calculatrice, vous pourriez
‫créer des exportations. ajouter, les
‫exportations.
‫multiplier, les exportations. diviser et ainsi de suite.
‫Logique?
‫Encore une fois, nous allons le faire dans la prochaine vidéo et
‫cela aura plus de sens pour vous d'ici là.
‫C'est ainsi que nous exportons et importons des
‫données d'un module à l'autre.
‫Bien sûr, c'est aussi pourquoi nous
‫affectons généralement le résultat d'une fonction require appelée à une nouvelle variable.
‫Afin que nous puissions enregistrer les exportations retournées.
‫Maintenant, juste pour terminer cette vidéo très rapidement,
‫la dernière étape est que les modules sont en fait mis
‫en cache après la première fois qu'ils sont chargés.
‫Cela signifie que si vous avez besoin plusieurs
‫fois du même module, vous obtiendrez toujours le même résultat.
‫Et le code dans les modules n'est en fait exécuté que lors
‫du premier appel.
‫Dans les appels
‫suivants, le résultat est simplement extrait du cache.
‫Parfait.
‫J'espère donc que toute la logique derrière la
‫façon de travailler avec les
‫modules ne ressemble plus vraiment à de la magie.
‫Il est vraiment important de savoir comment tout cela
‫fonctionne, afin de devenir un
‫grand et surtout un
‫NODE plus indépendant. Développeur JS.