Czym dokładnie jest Hot Module Replacement w Webpack?

najpierw chcę zauważyć, że Hot Module Replacement (HMR) jest nadal funkcją eksperymentalną.

Dokumentacja

Wymagania wstępne:

• używanie wtyczek: http://webpack.github.io/docs/using-plugins.html
• Podział Kodu: http://webpack.github.io/docs/code-splitting.html
• webpack-dev-server: http://webpack.github.io/docs/webpack-dev-server.html

To nie tyle dla HMR, ale tutaj są linki:

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

Dodam te odpowiedzi do dokumentacja.

Jak to działa?

Z widoku aplikacji

Kod aplikacji prosi środowisko wykonawcze HMR o sprawdzenie aktualizacji. Środowisko wykonawcze HMR pobiera aktualizacje (asynchroniczne) i informuje kod aplikacji, że aktualizacja jest dostępna. Kod aplikacji prosi środowisko wykonawcze HMR o zastosowanie aktualizacji. Środowisko wykonawcze HMR stosuje aktualizacje (synchronizacja). Kod aplikacji może, ale nie musi, wymagać interakcji użytkownika w tym procesie (Ty decydujesz).

Z widoku kompilatora (webpack)

Oprócz w normalnych zasobach kompilator musi emitować "Update", aby umożliwić aktualizację z poprzedniej wersji do tej wersji. "Aktualizacja" składa się z dwóch części:

[[28]}manifest aktualizacji (json)
1. jeden lub wiele fragmentów aktualizacji (js)

Manifest zawiera nowy hash kompilacji i listę wszystkich fragmentów aktualizacji (2).

Fragmenty aktualizacji zawierają kod dla wszystkich zaktualizowanych modułów w tym fragmencie (lub flagę, jeśli moduł został usunięty).

Kompilator dodatkowo upewnia się, że identyfikatory module i chunk id są spójne między tymi kompilacjami. Używa" zapisuje " plik json do przechowywania ich pomiędzy kompilacjami (lub przechowuje je w pamięci).

Z widoku modułu

W większości przypadków zapisywanie kodu HMR w każdym module nie jest obowiązkowe. Jeśli moduł nie ma uchwytów HMR, aktualizacja zostanie uruchomiona. Oznacza to, że pojedyncza obsługa może obsługiwać aktualizacje dla całego drzewa modułów. Jeśli jeden moduł w tym drzewie jest aktualizowany, całe drzewo modułów jest przeładowywane (tylko przeładowywane, nie przenoszone).

Dodatkowy kod jest emitowany dla systemu modułów runtime to track module parents i children.

Po stronie zarządzania runtime obsługuje dwie metody: check oraz apply.

A check wykonuje żądanie HTTP do manifestu aktualizacji. Gdy to żądanie nie powiedzie się, aktualizacja nie jest dostępna. W innym przypadku lista zaktualizowanych kawałków jest porównywana z listą aktualnie załadowanych kawałków. Dla każdego załadowanego fragmentu pobierany jest odpowiedni fragment aktualizacji. Wszystkie aktualizacje modułów są przechowywane w trybie wykonawczym jako aktualizacje. Runtime przełącza się do ready stan, co oznacza, że aktualizacja została pobrana i jest gotowa do zastosowania.

Dla każdego nowego żądania fragmentu w stanie gotowości pobierany jest również fragment aktualizacji.

Metoda apply oznacza wszystkie zaktualizowane Moduły jako nieprawidłowe. Dla każdego nieprawidłowego modułu w module musi znajdować się Obsługa aktualizacji lub Obsługa aktualizacji w każdym rodzicu. W przeciwnym razie nieprawidłowe pęcherzyki się i oznacza wszystkich rodziców jako nieprawidłowe zbyt. Proces ten trwa, dopóki nie nastąpi więcej "bubble up". Jeśli bąbelki do punkt wejścia, proces się nie powiedzie.

Teraz wszystkie nieprawidłowe moduły są usuwane (dispose handler) i rozładowywane. Następnie aktualny hash jest aktualizowany i wywoływane są wszystkie procedury obsługi "accept". Runtime przełącza się z powrotem do stanu idle i wszystko przebiega normalnie.

Można go użyć w rozwoju jako zamiennik wątroby. W rzeczywistości webpack-dev-server obsługuje tryb gorący, który próbuje zaktualizować za pomocą HMR przed próbą przeładuj całą stronę. Wystarczy dodać webpack/hot/dev-server i wywołać dev-server za pomocą --hot.

Można go również używać w produkcji jako mechanizmów aktualizacji. Tutaj musisz napisać własny kod zarządzania, który integruje HMR z Twoją aplikacją.

Niektóre Ładowarki już generują moduły, które można aktualizować podczas pracy. na przykład {[10] } może wymienić arkusz stylów. Nie musisz robić niczego specjalnego.

Załóżmy, że chcę zaktualizować mój CSS (jeden arkusz stylów) i JS moduły po zapisaniu ich na dysk, bez przeładowywania strony i bez używania wtyczek takich jak LiveReload. Czy to coś, w czym może mi pomóc Gorąca wymiana modułów?

Tak

Jaki rodzaj pracy muszę wykonać i co HMR już zapewnia?

Oto mały przykład: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html

Moduł może zostać zaktualizowany tylko wtedy, gdy go "zaakceptujesz". Więc musisz module.hot.accept moduł w rodzicach lub rodzicach rodziców... np. router jest dobrym miejscem, lub subview.

Jeśli chcesz używać go tylko z webpack-dev-server, po prostu dodaj webpack/hot/dev-server jako punkt wejścia. W przeciwnym razie potrzebujesz kodu zarządzania HMR, który wywoła check i apply.

Opinia: co sprawia, że jest tak fajny?

[[28]}to wątroba, ale dla każdego rodzaju modułu. Możesz go użyć w produkcji.
• aktualizacje respektują podział kodu i pobierają tylko aktualizacje dla używanych części aplikacji.
• można go używać dla części aplikacji i nie wpływa to na inne moduły
• jeśli HMR jest wyłączony, cały kod HMR jest usuwany przez kompilator(zawiń go w if(module.hot)).

Caveats

• to eksperymentalne i niezbyt dobrze przetestowane.
• spodziewaj się błędów.
• teoretycznie użyteczny w produkcji, ale może być za wcześnie, aby użyć go do czegoś poważnego.
• identyfikatory modułów muszą być śledzone pomiędzy kompilacji więc trzeba je przechowywać (records).
• optymalizator nie może już optymalizować identyfikatorów modułów po pierwszej kompilacji. Mały wpływ na rozmiar wiązki.
• HMR runtime code zwiększa rozmiar pakietu.
• do użycia w produkcji wymagane są dodatkowe testy w celu przetestowania urządzeń obsługujących HMR. To może być trudne.