Webpack HMR 与 emacs 中的 Skewer 模式

Webpack HMR vs Skewer mode in emacs

我最近开始研究 webpack,因为很酷的功能可以编写真正的 CSS 模块、智能捆绑和其他东西,还有 HMR,这就是我来这里的原因。我看过 React Redux 项目的示例,这些项目可以在不重新加载浏览器的情况下更新 javascript 代码。哇,我认为这是不可能的。

我想了解更多,尤其是它在底层是如何工作的,以便与我当前的 Vanilla JS 项目一起使用。

与此同时,我对函数式编程语言的兴趣将我带到了 Emacs。我发现在 emacs 编辑器中有一个 skewer-mode 可以更新 javascript 和 HTML!无需重新加载浏览器即可实时查看。

我知道他们都使用本地服务器将更改推送到浏览器,并使用客户端上的一些脚本以某种方式更新代码。但是他们如何保持应用程序的状态。就 React 项目而言,这是可以想象的,因为应用程序基于组件的性质,您可以用新组件替换组件,但我不确定他们如何搜索变量并为它们重新分配新值。也许他们确实使用了一些 eval 魔法。但我不确定。

  1. 那么它们究竟是如何工作的呢?可能是我看的角度不对,拍的不是很清楚

  2. Emacs 也有 HTML 的实时更新,webpack HMR 可以做到吗?
    (我不太关心HTML,因为我是用JS做的。但我认为它可以解释这两者之间的区别。)

  3. 这样做哪个更好?
    各自的优缺点是什么,或者它们只是世界的不同部分,可以整合成为更好的东西?

  4. 也许有更好的选择,不需要像本地网络服务器这样的中间件,而只是编辑器插件与一些浏览器扩展通信?

P.S.: 我不介意学习可以优化我工作的工具,因为它总是有回报的。

So how do they exactly work?

来自Webpack HMR documentation,

In general the module developer writes handlers that are called when a dependency of this module is updated. He can also write a handler that are called when this module is updated.

每个模块类型都需要为其编写更新逻辑。

来自skewer-mode repository,

Expressions are sent on-the-fly from an editing buffer to be evaluated in the browser, just like Emacs does with an inferior Lisp process in Lisp modes.

您的代码作为字符串发送到浏览器,运行通过全局 eval

Which is better in doing so? What is the pros and cons of each?

如果您使用的库有为它们编写的 HMR 插件,可能值得使用此功能。没有 HMR 钩子的图书馆不会从中受益。 Webpack 的 HMR 看起来非常复杂,它的文档和它的插件警告 HMR 的 "experimental" 状态。因此,它可能不可靠,因此可能 适得其反 您的开发。例如,重载模块需要正确清理非重载模块。如果某些脚本将侦听器添加到 windowdocument 并且不提供删除它们的方法怎么办?

如果您希望您的文本编辑器充当浏览器的附加 REPL,那么您可以使用 skewer-mode。要影响应用程序中的任何更改,它的某些部分必须通过全局变量公开。也许你导出了一个全局对象,上面附加了一堆子模块,例如window.APP = {}APP.DialogAPP.Form... 或者,也许您只是将数百个隐式全局变量和函数释放到您的环境中。您可以通过评估这些模块/函数/变量的定义,然后评估使用它们的一些代码,例如通过调用引导您的应用程序的函数 APP.initialize(),或通过在您使用的视图库中触发重绘(通常通过执行用户操作,例如单击元素)。

如果您的应用程序不是以可以在浏览器控制台中修改的方式编写的(例如,如果您使用像 Browserify 或 Webpack 这样的模块编译器,它将您的代码包装在一个大闭包中),那么您将不会skewer-mode 可以做很多事情。另外,考虑手动评估代码片段/文件和重新运行初始化代码(并可能创建您将浪费时间调试的不可能的应用程序状态)是否会更快, 刷新页面并重新创建您之前的状态。

您从这些工具中获得的好处在很大程度上取决于您的应用程序的结构方式。我可以看到他们在完全正确的条件下(我上面描述的)创建令人愉快的开发工作流程。否则,它们似乎很可能造成伤害而不值得。