Что такое замена горячего модуля в Webpack?

сначала я хочу отметить, что замена горячего модуля (HMR) по-прежнему является экспериментальной функцией.

HMR-это способ обмена модулями в запущенном приложении (и добавления/удаления модулей). Вы в основном можете обновлять измененные модули без полной перезагрузки страницы.

документация

Prerequirements:

• С Помощью Плагинов: http://webpack.github.io/docs/using-plugins.html
• Разделение Кода:http://webpack.github.io/docs/code-splitting.html
• webpack-dev-сервер:http://webpack.github.io/docs/webpack-dev-server.html

это не так много для HMR, но вот ссылки:

• пример: http://webpack.github.io/docs/hot-module-replacement-with-webpack.html
• API:http://webpack.github.io/docs/hot-module-replacement.html

я добавлю эти ответы в документации.

как это работает?

из вида приложения

код приложения просит среду выполнения HMR проверить наличие обновлений. Среда выполнения HMR загружает обновления (async) и сообщает коду приложения, что обновление доступный. Код приложения просит среду выполнения HMR применить обновления. Среда выполнения HMR применяет обновления (синхронизацию). Код приложения может или не может требовать взаимодействия с пользователем в этом процессе (вы решаете).

из представления компилятора (webpack)

в дополнение к обычным активам компилятор должен выдать "обновление", чтобы разрешить обновление с предыдущей версии до этой версии. "Обновление" содержит две части:

1. обновление манифеста (json)
2. один или несколько блоков обновления (js)

манифест содержит новый хэш компиляции и список всех блоков обновления (2).

блоки обновления содержат код для всех обновленных модулей в этом блоке (или флаг, если модуль был удален).

компилятор дополнительно гарантирует, что идентификаторы модулей и блоков согласованы между этими сборками. Он использует файл json" records " для хранения их между сборками (или сохраняет их в память.)

вид модуля

HMR-это функция выбора, поэтому она влияет только на модули, содержащие код HMR. В документации описывается API, доступный в модулях. В общем случае разработчик модуля пишет обработчики, которые вызываются при обновлении зависимости этого модуля. Они также могут написать обработчик, который вызывается при обновлении этого модуля.

в большинстве случаев не обязательно писать код HMR в каждом модуле. Если модуль имеет нет обработчиков HMR, обновление пузырится. Это означает, что один обработчик может обрабатывать обновления для полного дерева модулей. При обновлении одного модуля в этом дереве выполняется перезагрузка всего дерева модулей (только перезагрузка, не передача).

из представления времени выполнения HMR (технический)

дополнительный код выдается для выполнения системы модуля для отслеживания модуля parents и children.

на стороне управления, среда выполнения поддерживает два метода: check и apply.

A check выполняет HTTP-запрос к манифесту обновления. При сбое этого запроса обновление недоступно. В противном случае список обновленных фрагментов сравнивается со списком загруженных в данный момент фрагментов. Для каждого загруженного фрагмента загружается соответствующий фрагмент обновления. Все обновления модулей хранятся в среде выполнения как обновления. Среда выполнения переключается в ready состояние, то есть обновление было загружено и готово к применению.

для каждого нового chunk запрос в состоянии готовности, обновление chunk также загружается.

на apply метод помечает все обновленные модули недействительным. Для каждого недопустимого модуля в модуле должен быть обработчик обновлений или обработчики обновлений в каждом родителе. В противном случае инвалид всплывает и помечает всех родителей как недействительных. Этот процесс продолжается до тех пор, пока больше не произойдет "пузырька". Если он пузырится до точки входа, процесс завершается неудачей.

теперь все недопустимые модули удалены (dispose handler) и выгружен. Затем текущий хэш обновляется, и вызываются все обработчики "accept". Среда выполнения переключается обратно на idle состояние и все продолжается как обычно.

что я могу с ним сделать?

вы можете использовать его в развитии как замена LiveReload. На самом деле webpack-dev-server поддерживает горячий режим, который пытается обновить с помощью HMR, прежде чем пытаться перезагрузить всю страницу. Вам нужно только добавить webpack/hot/dev-server запись укажите и вызовите dev-сервер с помощью --hot.

вы можете также использовать его в производстве в качестве механизмов обновления. Здесь вам нужно написать свой собственный код управления, который интегрирует HMR с вашим приложением.

некоторые загрузчики уже генерируют модули с возможностью горячего обновления. например,style-loader может обменять стилей. Вам не нужно делать ничего особенного.

предположим, я хочу обновить CSS (одну таблицу стилей) и JS-модули, когда я сохраняю их на диск, без перезагрузки страницы и без использования плагинов, таких как LiveReload. Это что-то горячая замена модуля может мне помочь?

да

какую работу мне нужно сделать, и что уже предоставляет HMR?

вот небольшой пример:http://webpack.github.io/docs/hot-module-replacement-with-webpack.html

модуль может быть обновлена только если вы "принимаете" его. Так что тебе нужно module.hot.accept модуль в родителей или родителей родителей... например, маршрутизатор-это хорошее место или subview.

если вы хотите использовать его только с webpack-dev-server, просто добавьте webpack/hot/dev-server в качестве точки входа. Еще вам нужен код управления HMR, который вызывает check и apply.

мнение: что делает его таким крутым?

• это LiveReload, но для каждого вида модуля.
• вы можете использовать его в производстве.
• обновления соблюдайте разделение кода и загружайте обновления только для используемых частей приложения.
• вы можете использовать его на часть вашего приложения, и это не влияет на другие модули
• если HMR отключен, весь код HMR удаляется компилятором (оберните его в if(module.hot)).

предостережения

• это экспериментально и не проверено так хорошо.
• ожидайте некоторые ошибки.
• теоретически можно использовать в производстве, но это может быть слишком рано использовать его для чего-то серьезного.
• идентификаторы модулей должны отслеживаться между компиляциями, поэтому их необходимо хранить (records).
• оптимизатор больше не может оптимизировать идентификаторы модулей после первой компиляции. Немного влияет на размер пакета.
• HMR runtime code увеличивает размер пакета.
• для использования продукции, дополнительное испытание необходимо испытать обработчики HMR. Это может быть довольно сложно.