关于WebPack中的热模块替换,
它是否应该只用于开发,而不是用于生产?
它像LiveReload,但是你必须自己管理它吗?
WebPackDevServer是否以某种方式与其集成?
假设我想在将CSS(一个样式表)和JS模块保存到磁盘时更新它们,而不需要重新加载页面,也不需要使用诸如LiveReload之类的插件。这是什么热模块更换可以帮助我吗?我需要做什么样的工作,HMR已经提供了什么?
发布于 2018-03-23 11:11:46
首先,我想指出,热模块替换(HMR)仍然是一个实验性的特点。
HMR是一种在运行中的应用程序中交换模块的方法(以及添加/删除模块)。基本上可以更新已更改的模块,而不需要重新加载整个页面。
预录:
这不太适合HMR,但以下是链接:
应用程序代码要求HMR运行时检查更新。HMR运行时下载更新(异步)并告诉应用程序代码更新是可用的。应用程序代码要求HMR运行时应用更新。HMR运行时应用更新(同步)。应用程序代码可能需要也可能不需要用户在此过程中的交互。
除了正常的资产外,编译器还需要发出“更新”,以允许从以前的版本更新到此版本。“最新情况”包括两部分:
清单包含新的编译散列和所有更新块(2.)的列表。
更新块包含此块中所有更新模块的代码(如果删除了模块,则为标志)。
编译器额外地确保模块和块ID在这些构建之间保持一致。它使用一个“记录”json文件在构建之间存储它们(在上面将它们存储在内存中)。
HMR是一个可选择的功能,因此它只影响包含HMR代码的模块。文档描述了模块中可用的API。通常,模块开发人员编写在更新该模块的依赖项时调用的处理程序。他还可以编写在更新该模块时调用的处理程序。
在大多数情况下,在每个模块中编写HMR代码并不是强制性的。如果模块没有HMR处理程序,则更新会弹出。这意味着一个处理程序可以处理完整模块树的更新。如果更新此树中的单个模块,则重新加载完整的模块树(仅重新加载,而不是传输)。
对于模块,系统运行时是发送到跟踪模块的附加代码。parents
和children
.
在管理端,运行时支持两种方法:check
和apply
.
阿check
对更新清单执行HTTP请求。当此请求失败时,将没有可用的更新。否则,更新块的列表将与当前加载的块列表进行比较。对于每个加载的块,将下载相应的更新块。所有模块更新存储在运行时作为更新。运行时切换到ready
状态,意味着已下载并准备应用更新。
对于处于就绪状态的每个新块请求,还将下载更新块。
apply
方法将所有更新的模块标记为无效。对于每个无效模块,需要在模块中设置一个更新处理程序,或者在每个父模块中都有一个更新处理程序。否则,那些无效的佛像也会把所有的父母都标记为无效的。这一过程一直持续到不再出现“泡沫”。如果它从一个入口点冒出来,进程就会失败。
现在,所有无效模块都被释放(Dispose处理程序)并卸载。调用所有“接受”处理程序。运行时切换回idle
一切照常进行。
可以在开发中使用它作为LiveReload替代。实际上,webpack-dev服务器支持一种热模式,在尝试重新加载整个页面之前尝试使用hmr进行更新。只需添加webpack/hot/dev-server
入口点,并使用以下命令调用dev-server--hot
.
还可以在生产中使用它作为更新机制。在这里,需要编写自己的管理代码,将HMR与您的应用程序集成在一起。
一些加载器已经生成了可热更新的模块。I.E.style-loader
可以交换样式表。你不需要做什么特别的事。
假设我想在将CSS(一个样式表)和JS模块保存到磁盘时更新它们,而不需要重新加载页面,也不需要使用诸如LiveReload之类的插件。这是什么热模块更换可以帮助我吗?
是
我需要做什么样的工作,HMR已经提供了什么?
下面是一个小小的例子:
模块只有在“接受”时才能更新。所以你需要module.hot.accept
父母或父母的父母。也就是说,路由器是一个很好的地方或一个俯瞰。
如果只想将它与webpack-dev服务器一起使用,只需添加webpack/hot/dev-server
作为切入点。否则,需要一些hmr管理代码调用check
和apply
.
if(module.hot)
records
)https://stackoverflow.com/questions/-100004297
复制相似问题