node.js中watch机制详解
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了node.js中watch机制详解,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1919字,纯文字阅读大概需要3分钟。
内容图文
![node.js中watch机制详解](/upload/InfoBanner/zyjiaocheng/361/fd9608345fba4cd0a96f405ed05569f4.jpg)
几乎所有构建系统都选择使用watch机制来解决开发过程中需要反复生成构建后文件的问题,但在watch机制下,长期以来我们必须忍受修改完代码,保存完代码必须喝口茶才能刷新看看效果的问题。在这里我们尝试探讨为什么watch不是银弹,并尝试寻找一种更好的方案来解决这个问题。
watch基于的事实
当一个文件修改,我们能知道其修改可能导致的文件修改,那么重新构建这些文件即可。
通常对于文件A,构建成文件B这种场景,这种对应关系是极好确定的。但现实场景下,构建过程往往不是那么简单。例如:
文件A + 文件B(被文件A引用) -> 文件C
在这种场景下,文件B的修改,可能难以定位哪些文件需要重新跑构建任务,因为可能有很多文件引用了文件B。
除非我们建立一个依赖树,并在每次文件更新的情况下更新依赖树,并根据新的依赖树触发文件构建。但这对每一个插件都需要自行实现这个机制,并且极易出错。故实际上watch机制仅仅是重跑了整个task。所以当项目越来越大的时候,watch机制将越来越慢(因为越来越多文件需要重新跑整个过程,即使通过缓存减少了整个过程所需的耗时)。
解决方案
src直接可用
AlloyTeam & @ldjking,简单来说直接让src直接可跑,把构建任务放置在浏览器端,甚至根本不构建,既可做到及时修改及时刷新,在开发过程中减少了时间消耗。线下构建仅仅负责性能优化上的问题,不负责开发效率。
典型代表有LESS、React等。但也有一些问题:
难以在浏览器端实现优雅的构建方式,难以提供强大的功能进一步减少开发成本,大部分只能采用类似<style type="text/less"></style>的方式引入脚本。
开发模式下的执行顺序不一定和实际场景相同,可能导致隐形bug出现,例如实现一个HTML inline由于开发模式下inline是异步的,而发布模式下inline时同步的,产生莫名其妙的bug。
浏览器编译性能堪忧,例如js版的sass,编译速度几乎无法忍受。
需要维护线上、线下两套构建系统,增加了工具开发成本。
本地服务器动态构建
一个事实是:在合理的规范支持下,我们可以从浏览器请求的文件,回溯到该文件构建过程中的入口文件。这样我们就可以动态触发一次构建过程。
通过在本地建立一个服务器,让服务器捕获请求后,在服务器中动态构建。只要回溯到入口文件,我们便能将入口文件丢进gulp插件组成的管道中,则输出便是浏览器需要的文件。
这样我们就能解决上面的所有问题。
内容总结
以上是互联网集市为您收集整理的node.js中watch机制详解全部内容,希望文章能够帮你解决node.js中watch机制详解所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。