Utiliser des modules ES dans le navigateur aujourd'hui –
Cet article va vous montrer comment utiliser les modules ES dans le navigateur aujourd'hui.
Jusqu'à récemment, JavaScript n'avait pas de concept de modules. Il n'était pas possible de référencer ou d'inclure directement un fichier JavaScript dans un autre. Et au fur et à mesure que la taille et la complexité des applications augmentaient, cela rendait difficile l'écriture de JavaScript pour le navigateur.
Une solution courante consiste à charger des scripts arbitraires dans une page Web en utilisant des balises
// html.js
balise de fonction d'exportation (balise, texte) {
const el = document.createElement (tag)
el.textContent = texte
retourner el
}
Ou comme script externe:
// app.js
import {tag} à partir de './html.js'
const h1 = tag ('h1', '? Hello Modules!')
document.body.appendChild (h1)
Ajoutez simplement type = "module"
à vos tags de script et le navigateur les chargera en tant que modules ES. Le navigateur suivra tous les chemins d'importation, en téléchargeant et en n'exécutant chaque module qu'une seule fois.
Les anciens navigateurs n'exécuteront pas de scripts avec un "type" inconnu, mais vous pouvez définir des scripts de secours avec l'attribut nomodule
:
Exigences
Firefox a besoin du drapeau dom.moduleScripts.enabled
activé dans à propos de: config
.
Vous aurez besoin d'un serveur pour pouvoir l'importer, car cela ne fonctionne pas avec le protocole file: //
. Vous pouvez utiliser npx serve
pour démarrer un serveur dans le répertoire courant pour le tester localement.
Si vous voulez charger des modules ES sur un domaine différent, vous devrez activer CORS
.
Si vous êtes assez audacieux pour essayer ceci en production aujourd'hui, vous aurez toujours besoin de créer des paquets séparés pour les anciens navigateurs. Il y a un polyfill disponible à browser-es-module-loader qui suit la spécification. Cependant, cela n'est pas recommandé du tout pour la production
Performance
Ne jetez pas vos outils de construction comme Babel et Webpack pour le moment, car les navigateurs sont encore en train d'implémenter des méthodes pour optimiser la récupération. Pourtant, il y a des pièges de performance et gains à avoir dans le futur avec des modules ES
Pourquoi nous regroupons
Aujourd'hui nous regroupons notre JavaScript pour réduire le nombre de HTTP les demandes sont faites, car le réseau est souvent la partie la plus lente du chargement d'une page Web. Ceci est toujours une préoccupation très valable aujourd'hui, mais le futur est prometteur: ES Modules avec la capacité de HTTP2 à diffuser plusieurs assets avec server push et les navigateurs implémentant le préchargement Préchargement
] link rel = "modulepreload" arrive bientôt dans un navigateur près de chez vous. Plutôt que d'avoir le navigateur résoudre tous les modules d'importation un par un, produisant une chute d'eau réseau comme ceci ...
---> GET index.html
<---
---> GET app.js
<---
---> GET html.js
<---
---> GET lib.js
<---
... vous pourrez dire au navigateur que les pages nécessitent html.js
et lib.js
en gardant cette cascade sous contrôle:
- -> GET /index.html
<---
---> GET app.js
---> GET html.js
---> GET lib.js
<---
<---
<---
HTTP2 avec Server Push
HTTP2 est capable de pousser plusieurs ressources dans une seule réponse par rapport à HTTP1.1, qui ne peut en fournir qu'une seule. Cela permettra de réduire au minimum le nombre d'allers-retours sur le réseau.
Dans notre exemple, il serait possible de livrer index.html
app.js
et html.js
en une seule requête:
---> GET /index.html
<--- index.html
<--- app.js
<--- html.js
<--- lib.js
Mise en mémoire cache
La mise en cache de plusieurs modules ES plus petits peut être bénéfique car le navigateur n'aura besoin que de récupérer ceux qui ont été modifiés. Le problème avec la production de gros paquets est que si vous changez une ligne, vous invalidez le paquet entier.
async / defer
Les modules ES ne sont pas bloqués par défaut, comme
Et si nous faisons la bonne chose et importons juste la fonction dont nous avons besoin? Nous sommes à un simple 119 demandes :
Ceci est juste un exemple pour démontrer que lodash-es
n'est pas conçu pour être chargé directement dans le navigateur. Pour ce faire, vous devrez toujours créer votre propre paquet avec les modules ES comme cible.
Support du navigateur
Comme le montre le tableau suivant, le support du navigateur pour les modules ES est bon (et s'améliore tout le temps)
Le moment de commencer à expérimenter avec les modules ES dans le navigateur est maintenant. Assez rapidement, vous pourrez les utiliser dans tous les navigateurs modernes sans transpiler ou bundler, si vous le souhaitez.
Source link