Innanzitutto voglio notare che la sostituzione del modulo a caldo (HMR) è ancora una funzione sperimentale.
HMR è un modo di scambiare moduli in un'applicazione in esecuzione (e aggiungere / rimuovere moduli). Fondamentalmente puoi aggiornare i moduli modificati senza ricaricare l'intera pagina.
Documentazione
Prerequisiti:
Non è tanto per HMR, ma ecco i link:
Aggiungerò queste risposte alla documentazione.
Come funziona?
Dalla vista dell'app
Il codice dell'app chiede al runtime HMR di verificare la presenza di aggiornamenti. Il runtime HMR scarica gli aggiornamenti (asincroni) e comunica al codice dell'app che è disponibile un aggiornamento. Il codice dell'app chiede al runtime HMR di applicare gli aggiornamenti. Il runtime HMR applica gli aggiornamenti (sincronizzazione). Il codice dell'app potrebbe richiedere o meno l'interazione dell'utente in questo processo (decidi tu).
Dalla vista del compilatore (webpack)
Oltre alle risorse normali, il compilatore deve emettere "Aggiorna" per consentire l'aggiornamento da una versione precedente a questa versione. L '"Aggiornamento" contiene due parti:
- manifest manifest (json)
- uno o più blocchi di aggiornamento (js)
Il manifest contiene il nuovo hash di compilazione e un elenco di tutti i blocchi di aggiornamento (2).
I blocchi di aggiornamento contengono codice per tutti i moduli aggiornati in questo blocco (o un flag se un modulo è stato rimosso).
Il compilatore si assicura inoltre che gli ID di modulo e chunk siano coerenti tra queste build. Utilizza un file json "record" per memorizzarli tra build (o li memorizza in memoria).
Dalla vista del modulo
HMR è una funzione opt-in, quindi influisce solo sui moduli che contengono codice HMR. La documentazione descrive l'API disponibile nei moduli. In generale, lo sviluppatore del modulo scrive i gestori che vengono chiamati quando viene aggiornata una dipendenza di questo modulo. Possono anche scrivere un gestore chiamato quando questo modulo viene aggiornato.
Nella maggior parte dei casi, non è obbligatorio scrivere il codice HMR in ogni modulo. Se un modulo non ha gestori HMR, l'aggiornamento compare. Ciò significa che un singolo gestore può gestire gli aggiornamenti per un albero modulo completo. Se un singolo modulo in questo albero viene aggiornato, viene ricaricato l'albero dei moduli completo (solo ricaricato, non trasferito).
Dalla vista di runtime HMR (tecnica)
Il codice aggiuntivo viene emesso per il runtime del sistema del modulo per tenere traccia del modulo parentse children.
Dal lato della gestione, il runtime supporta due metodi: checke apply.
A checkesegue una richiesta HTTP al manifest di aggiornamento. Quando questa richiesta fallisce, non è disponibile alcun aggiornamento. Altrimenti l'elenco dei blocchi aggiornati viene confrontato con l'elenco dei blocchi attualmente caricati. Per ogni blocco caricato, viene scaricato il blocco di aggiornamento corrispondente. Tutti gli aggiornamenti dei moduli sono memorizzati nel runtime come aggiornamenti. Il runtime passa allo readystato, il che significa che un aggiornamento è stato scaricato ed è pronto per essere applicato.
Per ogni nuova richiesta di blocco nello stato Pronto, viene scaricato anche il blocco di aggiornamento.
Il applymetodo contrassegna tutti i moduli aggiornati come non validi. Per ogni modulo non valido, deve esserci un gestore di aggiornamento nel modulo o gestori di aggiornamento in ogni genitore. Altrimenti, le bolle non valide aumentano e anche tutti i genitori vengono considerati non validi. Questo processo continua fino a quando non si verificano più "bolle". Se bolle fino a un punto di ingresso, il processo ha esito negativo.
Ora tutti i moduli non validi vengono eliminati (elimina gestore) e scaricati. Quindi viene aggiornato l'hash corrente e vengono chiamati tutti i gestori "accetta". Il runtime torna allo idlestato e tutto continua normalmente.
Cosa posso farci?
Puoi usarlo nello sviluppo come sostituto di LiveReload. In realtà il webpack-dev-server supporta una modalità hot che tenta di aggiornare con HMR prima di provare a ricaricare l'intera pagina. Devi solo aggiungere il webpack/hot/dev-serverpunto di ingresso e chiamare il dev-server con --hot.
Puoi anche usarlo in produzione come meccanismo di aggiornamento. Qui devi scrivere il tuo codice di gestione che integra HMR con la tua app.
Alcuni caricatori generano già moduli aggiornabili a caldo. ad esempio, è style-loaderpossibile scambiare il foglio di stile. Non devi fare nulla di speciale.
Supponiamo di voler aggiornare i miei moduli CSS (un foglio di stile) e JS quando li salvo su disco, senza ricaricare la pagina e senza utilizzare plugin come LiveReload. È qualcosa che mi può aiutare con la sostituzione del modulo a caldo?
sì
Che tipo di lavoro devo fare e cosa offre già HMR?
Ecco un piccolo esempio: https://webpack.js.org/guides/hot-module-replacement/
Un modulo può essere aggiornato solo se lo "accetti". Quindi è necessario module.hot.acceptil modulo nei genitori o i genitori dei genitori ... ad es. Un router è un buon posto o una visione d'insieme.
Se vuoi usarlo solo con webpack-dev-server, aggiungi semplicemente webpack/hot/dev-servercome punto di ingresso. Altrimenti hai bisogno di un codice di gestione HMR che chiama checke apply.
Opinione: Cosa lo rende così bello?
- È LiveReload ma per ogni tipo di modulo.
- Puoi usarlo in produzione.
- Gli aggiornamenti rispettano la suddivisione del codice e scaricano solo gli aggiornamenti per le parti utilizzate dell'app.
- Puoi usarlo per una parte della tua applicazione e non influisce su altri moduli
- Se HMR è disabilitato, tutto il codice HMR viene rimosso dal compilatore (includendolo
if(module.hot)).
Avvertenze
- È sperimentale e non testato così bene.
- Aspettati alcuni bug.
- Teoricamente utilizzabile in produzione, ma potrebbe essere troppo presto per usarlo per qualcosa di serio.
- Gli ID del modulo devono essere tracciati tra le compilation, quindi è necessario memorizzarle (
records).
- L'ottimizzatore non può più ottimizzare gli ID del modulo dopo la prima compilazione. Un po 'di impatto sulla dimensione del pacchetto.
- Il codice di runtime HMR aumenta la dimensione del pacchetto.
- Per l'utilizzo in produzione, sono necessari ulteriori test per testare i gestori HMR. Questo potrebbe essere piuttosto difficile.
