web-dev-qa-db-fra.com

Qu'est-ce que le remplacement de module à chaud dans Webpack?

J'ai lu un pepages à propos du remplacement de module dynamique dans Webpack.
Il y a même un exemple d'application qui l'utilise .

J'ai lu tout cela et je ne comprends toujours pas l'idée.

Que puis-je en faire?
Est-il censé être utilisé uniquement en développement et non en production?
Est-ce que c'est comme LiveReload, mais vous devez le gérer vous-même?
WebpackDevServer est-il intégré à celui-ci d’une manière ou d’une autre?

Supposons que je veuille mettre à jour mes modules CSS (une feuille de style) et JS lorsque je les enregistre sur disque, sans recharger la page et sans utiliser de plug-in tel que LiveReload. Est-ce quelque chose que Hot Module Replacement peut m'aider? Quel type de travail dois-je effectuer et que propose déjà HMR?

186
Dan Abramov

Je tiens tout d'abord à noter que le remplacement de module à chaud (HMR) est encore une fonctionnalité expérimentale.

HMR est un moyen d'échanger des modules dans une application en cours d'exécution (et d'ajouter/de supprimer des modules). Vous pouvez fondamentalement mettre à jour les modules modifiés sans recharger toute la page.

Documentation

Pré-requis:

Ce n'est pas tellement pour HMR, mais voici les liens:

Je vais ajouter ces réponses à la documentation.

Comment ça marche?

De la vue de l'application

Le code de l'application demande au moteur d'exécution HMR de vérifier les mises à jour. Le moteur d'exécution HMR télécharge les mises à jour (asynchrone) et indique au code de l'application qu'une mise à jour est disponible. Le code de l'application demande au moteur d'exécution HMR d'appliquer les mises à jour. Le runtime HMR applique les mises à jour (sync). Le code de l'application peut nécessiter ou non l'intervention de l'utilisateur dans ce processus (à vous de décider).

Depuis la vue compilateur (webpack)

En plus des actifs normaux, le compilateur doit émettre la "Mise à jour" pour permettre la mise à jour d'une version précédente à cette version. La "mise à jour" contient deux parties:

  1. le manifeste de mise à jour (json)
  2. un ou plusieurs morceaux de mise à jour (js)

Le manifeste contient le nouveau hachage de compilation et une liste de tous les morceaux de mise à jour (2).

Les blocs de mise à jour contiennent du code pour tous les modules mis à jour de ce bloc (ou un indicateur si un module a été supprimé).

Le compilateur s'assure en outre que les identifiants de module et de bloc sont cohérents entre ces versions. Il utilise un fichier json "records" pour les stocker entre les versions (ou les stocke en mémoire).

De la vue du module

HMR est une fonctionnalité opt-in, elle n'affecte donc que les modules contenant du code HMR. La documentation décrit l'API disponible dans les modules. En général, le développeur de module écrit les gestionnaires appelés lors de la mise à jour d'une dépendance de ce module. Ils peuvent également écrire un gestionnaire appelé lorsque ce module est mis à jour.

Dans la plupart des cas, il n'est pas obligatoire d'écrire du code HMR dans chaque module. Si un module n'a pas de gestionnaire HMR, la mise à jour bouillonne. Cela signifie qu'un seul gestionnaire peut gérer les mises à jour pour une arborescence de modules complète. Si un seul module de cette arborescence est mis à jour, l'arborescence complète du module est rechargée (uniquement rechargée, non transférée).

De la vue d'exécution HMR (technique)

Un code supplémentaire est émis pour l'exécution du système du module afin de suivre le module parents et children.

Du côté de la gestion, le moteur d'exécution prend en charge deux méthodes: check et apply.

Un check envoie une requête HTTP au manifeste de mise à jour. Lorsque cette demande échoue, aucune mise à jour n'est disponible. Sinon, la liste des morceaux mis à jour est comparée à la liste des morceaux actuellement chargés. Pour chaque bloc chargé, le bloc de mise à jour correspondant est téléchargé. Toutes les mises à jour de modules sont stockées dans le runtime en tant que mises à jour. Le moteur d'exécution passe à l'état ready, ce qui signifie qu'une mise à jour a été téléchargée et est prête à être appliquée.

Pour chaque nouvelle demande de bloc à l'état prêt, le bloc de mise à jour est également téléchargé.

La méthode apply signale que tous les modules mis à jour sont invalides. Pour chaque module non valide, il doit y avoir un gestionnaire de mise à jour dans le module ou des gestionnaires de mise à jour dans chaque parent. Sinon, l'invalide bouillonne et marque tous les parents comme invalides. Ce processus se poursuit jusqu'à ce qu'il n'y ait plus de "bulle". Si cela bouillonne jusqu'à un point d'entrée, le processus échoue.

Désormais, tous les modules non valides sont mis au rebut (gestionnaire d'élimination) et déchargés. Ensuite, le hachage actuel est mis à jour et tous les gestionnaires "accept" sont appelés. Le moteur d'exécution revient à l'état idle et tout continue normalement.

generated update chunks

Que puis-je en faire?

Vous pouvez l'utiliser en développement pour remplacer LiveReload. En réalité, webpack-dev-server prend en charge un mode actif qui tente de se mettre à jour avec HMR avant de recharger toute la page. Vous devez seulement ajouter le point d'entrée webpack/hot/dev-server Et appeler le serveur de développement avec --hot.

Vous pouvez également l'utiliser en production comme mécanisme de mise à jour. Ici, vous devez écrire votre propre code de gestion qui intègre HMR à votre application.

Certains chargeurs génèrent déjà des modules pouvant être mis à jour à chaud. par exemple. Le style-loader Peut échanger la feuille de style. Vous n'avez rien de spécial à faire.

Supposons que je veuille mettre à jour mes modules CSS (une feuille de style) et JS lorsque je les enregistre sur disque, sans recharger la page et sans utiliser de plug-in tel que LiveReload. Est-ce quelque chose que Hot Module Replacement peut m'aider?

Oui

Quel type de travail dois-je effectuer et que propose déjà HMR?

Voici un petit exemple: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html

Un module ne peut être mis à jour que si vous "l'acceptez". Il faut donc module.hot.accept Le module chez les parents ou les parents des parents ... par exemple. Un routeur est un bon endroit ou une sous-vue.

Si vous voulez seulement l'utiliser avec le webpack-dev-server, ajoutez simplement webpack/hot/dev-server Comme point d'entrée. Sinon, vous avez besoin d'un code de gestion HMR qui appelle check et apply.

Opinion: Qu'est-ce qui le rend si cool?

  • C'est LiveReload mais pour chaque type de module.
  • Vous pouvez l'utiliser en production.
  • Les mises à jour respectent votre partage de code et ne téléchargent que les mises à jour des parties utilisées de votre application.
  • Vous pouvez l'utiliser pour une partie de votre application et cela n'affecte pas les autres modules
  • Si HMR est désactivé, tout le code HMR est supprimé par le compilateur (enveloppez-le dans if(module.hot)).

Mises en garde

  • C'est expérimental et pas si bien testé.
  • Attendez-vous à des bugs.
  • Théoriquement utilisable en production, mais il est peut-être trop tôt pour l'utiliser pour quelque chose de grave.
  • Les identifiants de module doivent être suivis entre les compilations, vous devez donc les stocker (records).
  • L'optimiseur ne peut plus optimiser les ID de module après la première compilation. Un peu d'impact sur la taille du paquet.
  • Le code d'exécution HMR augmente la taille de l'ensemble.
  • Pour une utilisation en production, des tests supplémentaires sont nécessaires pour tester les gestionnaires HMR. Cela pourrait être assez difficile.
325
Tobias K.

La réponse acceptée explicite tout correctement quand même. La description suivante permet de comprendre rapidement ce qu'est HMR.

Le remplacement de Hot Module est l’une des techniques les plus récentes du développement javascript qui attire l’attention des développeurs. Il facilite le développement en réduisant le nombre d'actualisations de pages en remplaçant les modules par des modifications lors de l'exécution.

En cherchant sur HMR, j'ai trouvé un article qui explique le concept sur Internet, vous pouvez l'obtenir à partir de maintenant en ajoutant une image GIF qui explique le concept sans trop d'explications.

La voici au travail - notez que le minuteur ne se réinitialise pas à 0 comme après un rechargement de page, et css modifie également l’actualisation automatique. Hot Module Replacement GIF

Webpack aide à atteindre HMR. Vous pouvez trouver des documents ici

Cela aide à atteindre les objectifs suivants

  • Conserver l'état de l'application qui est perdu lors d'un rechargement complet.

  • Gagnez un temps précieux de développement en ne mettant à jour que ce qui a changé.

  • Ajustez le style plus rapidement - presque comparable à l'évolution des styles dans le débogueur du navigateur.

Here est le guide Webpack pour atteindre HMR

7
Samuel J Mathew

Hot Module Replacement (HMR) est un outil permettant de mettre à jour automatiquement le serveur DEVELOPMENT. Il surveille les modifications apportées aux fichiers et indique au navigateur de remplacer des modules ou des éléments spécifiques sans recharger toute la page. (comme style-loader qui met à jour votre css sans faire de référencement) HMR est le plugin intégré de webpacks. dans le fichier index.js, ajoutez cette configuration:

if(module.hot){
   module.hot.accept();
}

ou via

npm install react-hot-loader

Avantages de HMR:

  • Lorsque vous déboguez votre code, les instructions restent dans la console car le navigateur ne renvoie plus la page.
  • Un rafraîchissement de page est un casse-tête. vous devez attendre le chargement de la page, ce qui peut prendre quelques secondes dans une application volumineuse. HMR augmente la productivité.
  • Vous pouvez conserver l'état de l'application avec le HMR
0
Yilmaz