O que é exatamente a substituição de Módulo quente no Webpack?

primeiro eu quero notar que a substituição de Módulo quente (HMR) ainda é uma característica experimental.

HMR é uma forma de trocar módulos em uma aplicação em execução (e Adicionar/remover módulos). Você basicamente pode atualizar módulos alterados sem uma recarga de página completa.

Documentação

Pré-requisitos:

• Usando Plugins: http://webpack.github.io/docs/using-plugins.html
• Repartição De Códigos: http://webpack.github.io/docs/code-splitting.html
• webpack-dev-server: http://webpack.github.io/docs/webpack-dev-server.html

Não é tanto para o HMR,mas aqui estão os links:

• Exemplo: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html
• API: http://webpack.github.io/docs/hot-module-replacement.html

Vou adicionar estas respostas ao documentacao. Como funciona?

Da vista das aplicações

O código da aplicação pede ao HMR para verificar as actualizações. O HMR executa o download das atualizações (async) e diz ao código do aplicativo que uma atualização está disponível. O código app pede ao HMR para aplicar atualizações. O tempo de execução HMR aplica as atualizações (sync). O código app pode ou não exigir interação do usuário neste processo (você decide).

Da vista do compilador (webpack)

Além de the normal assets, the compiler needs to emit the "Update" to allow updating from a previous version to this version. A "actualização" contém duas partes:

1. O manifesto de actualização (json)
2. um ou vários blocos de actualização (js)

O manifesto contém o novo hash de compilação e uma lista de todos os blocos de actualização (2).

Os blocos de actualização contêm código para todos os módulos actualizados neste bloco (ou uma opção se um módulo tiver sido removido).

O compilador além disso, certifica-se que os ids do módulo e do chunk são consistentes entre estas compilações. Ele usa um arquivo json" records " para armazená-los entre compilações (ou armazena-os na memória).

Da vista do módulo

O HMR é uma funcionalidade opt-in, por isso só afecta módulos que contêm código HMR. A documentação descreve a API que está disponível em módulos. Em geral, o desenvolvedor de módulos escreve manipuladores que são chamados quando uma dependência deste módulo é atualizada. Eles também podem escrever um manipulador que é chamado quando este módulo é atualizado.

Na maioria dos casos, não é obrigatório escrever código HMR em todos os módulos. Se um módulo não tiver manipuladores HMR,a atualização sobe. Isto significa que um único manipulador pode lidar com atualizações para uma árvore de módulos completa. Se um único módulo nesta árvore for atualizado, a árvore completa do módulo é recarregada (apenas recarregada, não transferida).

Do ponto de vista técnico do HMR

É emitido um código adicional para o sistema de módulos. tempo de execução do módulo parents e children.

Do lado da gestão, o tempo de execução suporta dois métodos: check e apply.

A check faz um pedido HTTP ao manifesto de actualização. Quando este pedido falha, não há nenhuma atualização disponível. Em contrapartida, a lista de blocos actualizados é comparada com a lista de blocos carregados de momento. Para cada bloco carregado, o bloco de actualização correspondente é transferido. Todas as atualizações de módulos são armazenadas no tempo de execução como atualizações. O tempo de execução muda para o ready estado, o que significa que uma atualização foi baixada e está pronta para ser aplicada.

Para cada novo pedido de bloco no estado pronto, o bloco de atualização também é baixado.

O método apply classifica todos os módulos actualizados como inválidos. Para cada módulo inválido, tem de haver um manipulador de actualização no módulo ou manipuladores de actualização em cada pai. Caso contrário, as bolhas inválidas para cima e marca todos os pais como inválidos também. Este processo continua até que não ocorra mais "bolha para cima". Se borbulhar até um ponto de entrada, o processo falha.

Agora todos os módulos inválidos são eliminados (eliminar manipulador) e descarregados. Em seguida, o hash atual é atualizado e todos os manipuladores "aceitar" são chamados. O tempo de execução volta ao estado idle e tudo continua como normal.

O que posso fazer com ele?

Pode usá-lo em desenvolvimento como substituto do fígado. Na verdade, o servidor webpack-dev suporta um modo quente que tenta actualizar com o HMR antes de tentar recarrega a página inteira. Só é necessário adicionar o ponto de entrada webpack/hot/dev-server e ligar para o servidor dev com --hot.

Você também pode usá-lo na produção como mecanismos de atualização. Aqui você precisa escrever o seu próprio código de gestão que integra HMR com o seu aplicativo.

Alguns carregadores já geram módulos que são atualizáveis a quente. por exemplo, o style-loader pode trocar a folha de estilo. Não precisas de fazer nada de especial.

Suponha que eu quero atualizar meu CSS (uma folha de estilo) e JS módulos quando eu salvá-los para o disco, sem recarregar a página e sem usar plugins como LiveReload. Isto é alguma coisa que a substituição do módulo quente pode ajudar-me?

Sim

Que tipo de trabalho preciso fazer, e que HMR já fornece?

Aqui está um pequeno exemplo: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html

Um módulo só pode ser actualizado se o" aceitares". Então, precisas de ... o módulo nos pais ou nos pais dos pais... por exemplo, um roteador é um bom lugar, ou um subview.

Se só o quiser usar com o servidor webpack-dev, basta adicionar webpack/hot/dev-server como ponto de entrada. Caso contrário, precisa de um código de gestão HMR que chame check e apply.

O que o torna tão fixe?

É Liveload, mas para todos os tipos de módulos.
• podes usá-lo na produção.
• as actualizações respeitam a divisão do seu código e só transferem as actualizações para as partes usadas da sua aplicação.
• pode usá-lo para uma parte da sua aplicação e não afecta outros módulos
• Se o HMR estiver desactivado, todo o código HMR é removido pelo compilador (embrulhe-o em if(module.hot)).

Advertências

É experimental e não tão bem testado. Espera alguns insectos.
• teoricamente utilizável na produção, mas pode ser muito cedo para a usar para algo sério.
• Os IDs do módulo precisam de ser rastreados entre compilações para que você precise armazená-las ([16]}).
• o Optimizador já não consegue optimizar os IDs do módulo após a primeira compilação. Um pouco de impacto no tamanho do pacote.
• o código HMR aumenta o tamanho do pacote.
• para a utilização da produção, são necessários ensaios adicionais para testar os manipuladores de HMR. Isto pode ser muito difícil.