javascript - tutorial - ¿Qué es exactamente el reemplazo de módulo caliente en Webpack?
webpack version (2)
He leído few pages sobre el reemplazo de módulos calientes en Webpack.
Incluso hay una aplicación de muestra que lo usa .
He leído todo esto y todavía no entiendo la idea.
¿Qué puedo hacer con eso?
¿Se supone que solo debe usarse en desarrollo y no en producción?
¿Es como LiveReload, pero tienes que hacerlo tú mismo?
¿Está WebpackDevServer integrado de algún modo?
Supongamos que quiero actualizar mi CSS (una hoja de estilo) y los módulos JS cuando los guardo en el disco, sin volver a cargar la página y sin usar complementos como LiveReload. ¿Es esto algo por lo que el Reemplazo de módulos calientes puede ayudarme? ¿Qué tipo de trabajo necesito hacer y qué me proporciona HMR?
La respuesta aceptada expande todo lo correcto de todos modos la siguiente descripción ayuda a comprender qué es HMR rápidamente.
El reemplazo de módulos calientes es una de las técnicas más novedosas en el desarrollo de javascript que atrae la atención de los desarrolladores. Ayuda al desarrollo al reducir el número de actualizaciones de página al reemplazar los módulos con cambios en el tiempo de ejecución.
Mientras buscaba HMR, encontré un article que explica el concepto en Internet, puedes obtenerlo aquí y agregar una imagen GIF que explica el concepto sin mucha explicación.
Aquí está en funcionamiento: tenga en cuenta que el temporizador no se restablece a 0 como lo haría después de una recarga de página, y css cambia la actualización automática también.
Webpack ayuda a lograr HMR. Puedes encontrar documentos here
Ayuda a lograr lo siguiente
Retenga el estado de la aplicación que se pierde durante una recarga completa.
Ahorre tiempo de desarrollo valioso al actualizar solo lo que ha cambiado.
Modifique el estilo más rápido, casi comparable a los estilos cambiantes en el depurador del navegador.
Here está la guía de webpack para lograr HMR
Primero quiero señalar que Hot Module Replacement (HMR) sigue siendo una función experimental.
HMR es una forma de intercambiar módulos en una aplicación en ejecución (y agregar / eliminar módulos). Básicamente puede actualizar los módulos modificados sin una recarga de página completa.
Documentación
Pre requisitos:
- Uso de complementos: http://webpack.github.io/docs/using-plugins.html
- División de código: http://webpack.github.io/docs/code-splitting.html
- webpack-dev-server: http://webpack.github.io/docs/webpack-dev-server.html
No es tanto para HMR, pero aquí están los enlaces:
Agregaré estas respuestas a la documentación.
¿Como funciona?
Desde la vista de la aplicación
El código de la aplicación le pide al tiempo de ejecución de HMR que busque actualizaciones. El tiempo de ejecución de HMR descarga las actualizaciones (asincrónicas) y le dice al código de la aplicación que hay una actualización disponible. El código de la aplicación le pide al tiempo de ejecución de HMR que aplique actualizaciones. El tiempo de ejecución HMR aplica las actualizaciones (sincronización). El código de la aplicación puede requerir o no interacción del usuario en este proceso (usted decide).
Desde la vista del compilador (paquete web)
Además de los activos normales, el compilador debe emitir la "Actualización" para permitir la actualización de una versión anterior a esta versión. La "Actualización" contiene dos partes:
- el manifiesto de actualización (json)
- uno o varios fragmentos de actualización (js)
El manifiesto contiene el nuevo hash de compilación y una lista de todos los trozos de actualización (2).
Los fragmentos de actualización contienen código para todos los módulos actualizados en este fragmento (o un indicador si se eliminó un módulo).
El compilador además se asegura de que el módulo y los identificadores de fragmentos sean consistentes entre estas compilaciones. Utiliza un archivo json de "registros" para almacenarlos entre compilaciones (o los almacena en la memoria).
Desde la vista del módulo
HMR es una función opcional, por lo que solo afecta a los módulos que contienen código HMR. La documentación describe la API que está disponible en los módulos. En general, el desarrollador del módulo escribe los controladores que se llaman cuando se actualiza una dependencia de este módulo. También pueden escribir un controlador al que se llama cuando se actualiza este módulo.
En la mayoría de los casos, no es obligatorio escribir código HMR en cada módulo. Si un módulo no tiene manejadores de HMR, la actualización surge. Esto significa que un solo manejador puede manejar actualizaciones para un árbol completo de módulos. Si se actualiza un único módulo en este árbol, se vuelve a cargar el árbol de módulos completo (solo se recarga, no se transfiere).
Desde la vista de tiempo de ejecución de HMR (técnica)
Se emite un código adicional para el tiempo de ejecución del sistema del módulo para rastrear el módulo parents e children .
En el lado de la administración, el tiempo de ejecución admite dos métodos: check y apply .
Un check realiza una solicitud HTTP al manifiesto de actualización. Cuando esta solicitud falla, no hay actualizaciones disponibles. De lo contrario, la lista de fragmentos actualizados se compara con la lista de fragmentos actualmente cargados. Para cada fragmento cargado, se descarga el fragmento de actualización correspondiente. Todas las actualizaciones de módulos se almacenan en el tiempo de ejecución como actualizaciones. El tiempo de ejecución cambia al estado ready , lo que significa que se ha descargado una actualización y está lista para su aplicación.
Para cada nueva solicitud de fragmento en el estado listo, también se descarga el fragmento de actualización.
El método apply indica que todos los módulos actualizados no son válidos. Para cada módulo no válido, es necesario que haya un controlador de actualización en el módulo o controladores de actualización en cada uno de los padres. De lo contrario, el inválido burbujea y marca a todos los padres como inválidos también. Este proceso continúa hasta que no se produce más "burbujeo". Si burbujea hasta un punto de entrada, el proceso falla.
Ahora todos los módulos inválidos se eliminan (eliminan el controlador) y se descargan. Luego se actualiza el hash actual y se llaman a todos los manejadores de "aceptar". El tiempo de ejecución vuelve al estado idle y todo continúa normalmente.
¿Qué puedo hacer con eso?
Puede usarlo en desarrollo como reemplazo de LiveReload. En realidad, el servidor webpack-dev-server es compatible con un modo caliente que intenta actualizar con HMR antes de tratar de volver a cargar toda la página. Solo necesita agregar el punto de entrada del webpack/hot/dev-server y llamar al servidor dev con --hot .
También puede usarlo en producción como mecanismos de actualización. Aquí debe escribir su propio código de administración que integra HMR con su aplicación.
Algunos cargadores ya generan módulos que se pueden actualizar en caliente. por ejemplo style-loader puede intercambiar la hoja de estilo. No necesitas hacer nada especial.
Supongamos que quiero actualizar mi CSS (una hoja de estilo) y los módulos JS cuando los guardo en el disco, sin volver a cargar la página y sin usar complementos como LiveReload. ¿Es esto algo por lo que el Reemplazo de módulos calientes puede ayudarme?
Sí
¿Qué tipo de trabajo necesito hacer y qué me proporciona HMR?
Aquí hay un pequeño ejemplo: few
Un módulo solo se puede actualizar si lo "acepta". Por lo tanto, es necesario que module.hot.accept el módulo en los padres o los padres de los padres ... por ejemplo, un enrutador es un buen lugar, o una subvista.
Si solo desea usarlo con el servidor webpack-dev-server, simplemente agregue webpack/hot/dev-server como punto de entrada. De lo contrario, necesita un código de gestión HMR que llame y apply .
Opinión: ¿Qué lo hace tan genial?
- Es LiveReload pero para cada tipo de módulo.
- Puedes usarlo en producción.
- Las actualizaciones respetan su división de código y solo descargan actualizaciones para las partes usadas de su aplicación.
- Puede usarlo para una parte de su aplicación y no afecta a otros módulos
- Si HMR está desactivado, el compilador elimina todo el código HMR (envuélvalo en
if(module.hot)).
Advertencias
- Es experimental y no tan bien probado.
- Esperar algunos errores.
- Teóricamente utilizable en producción, pero puede ser demasiado pronto para usarlo para algo serio.
- Los identificadores de módulos deben rastrearse entre compilaciones, por lo que debe almacenarlos (
records). - El optimizador ya no puede optimizar los ID de los módulos después de la primera compilación. Un poco de impacto en el tamaño del paquete.
- El código de tiempo de ejecución de HMR aumenta el tamaño del paquete.
- Para el uso de producción, se requieren pruebas adicionales para probar los manipuladores de HMR. Esto podría ser bastante difícil.