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?
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.
Pré-requis:
Ce n'est pas tellement pour HMR, mais voici les liens:
Je vais ajouter ces réponses à la documentation.
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).
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:
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).
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).
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.
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
.
if(module.hot)
).records
).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.
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
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: