摘要:并不是使用安装的模块我们就可以使用同样的方式使用任何一个模块,使用某种工具将这些模块打包发布作为事实上的前端模块化标准,或可以出来解救我们。目前比较拿的出手的,也就是的模块化,比如或者等等,分别可以使用和。
Teambition是一家追求卓越技术的公司,我们工程师都很Geek,我们使用了很多新潮的,开源的技术。同时我们也贡献了很多开源的项目。我们希望能够把一些技术经验分享给大家。于是有了这个「创作随笔」。废话休说,「创作随笔」第一弹,来自我们的前端工程师寸志,谈一谈他在前端模块化开发方面的一些感想。
在模块化方面,Node.js就显得游刃有余。
作为用户,我们把代码放到一个个JavaScript文件中,然后Node.js就有一套规则帮我们把这些代码组织起来,Node.js还有包的概念,于是我们就可以使用npm将代码放到一个个包中,放到这里那里的node_modules中使用。很方便不是?感谢Node.js。
可在浏览器端,模块化这事就没那么简单了。
前端的模块前端的一个模块包含很多东西,JavaScript、CSS、图片字体等等。甚至,可能根据业务需要,还包含国际化的文件。一个模块如果包含以上这些东西,复杂度就上了几个数量级。
怎么复杂了?和高大上的iOS开发比起来,人家有SDK,代码随便往项目里扔,图片扔,国际化有成熟的解决方案,最后构建一下一个可运行的应用就出来了。
前端缺乏SDK,没有成熟统一的开发方案,集成方案,前端模块化之路很崎岖。开发时,我们需要一种方式来组织,加载代码,发布时,我们还需要另外一种方式将代码、资源合并到一起发布。
眼前的现状TJ 给出了自己解决方案——Component。可以份文件开发,然后再把JavaScript、CSS和模板文件合并到一起。我只能说,理想很丰满,现实很骨感,Component无法适应各种奇葩的应用场景。
或者我们自由一点——
依赖的第三方模块,我们有Bower,好爽,运行个命令,依赖就安装好了。
但是Bower不是银弹,Bower只解决了模块依赖,安装依赖的问题。Bower中的模块没有任何标准和规则,有的只有JavaScript,有的支持AMD,有的可能只有CSS。文件结构,入口文件完全不一样。并不是使用Bower安装的模块我们就可以使用同样的方式使用任何一个模块,使用某种工具将这些模块打包发布!
AMD作为事实上的前端JavaScript模块化标准,或可以出来解救我们。很多Bower模块都是支持AMD规范的。而且AMD还提供了打包工具,总算有点解脱了。好景不长……
每个模块中的HTML怎么办,如果我们使用的框架是Backbone,注定我们要将HTML模板转换成JavaScript模块,或者使用模块加载器的插件来实现。如果我们使用AngularJS,那倒是可以交由AngularJS。发布时Backbone中的模块使用AMD打包,AngularJS可以使用Grunt内联到页面中。
HTML模块也没有固定的模式,没有固定的SDK来解脱我们。我们只能组合现有的工具!
CSS就更不用说了,分开写,使用LESS、SASS来组织?再一次没有固定的模式没有SDK。
还有图片呢,字体呢?
拼凑的方案前端如果想做模块化开发,首先需要针对每一种资源(JavaScript、CSS、模板等)寻找一种模块与集成方案,然后需要根据情况的不同选用不同的工具框架拼凑出来。
JavaScript目前比较拿的出手的,也就是JavaScript的模块化,比如AMD或者CMD等等,分别可以使用RequireJS和SeaJS。
去年在研究基于Backbone的框架Marionette时,想与Sea.js结合使用。现在来看这种组合是完全没有必要的。Marionette提供了模块化的组织方案,反而生拉硬扯在一起,冲突得很难受。其实把JavaScript文件一列放在HTML中也没什么问题。
究竟使用什么来实现JavaScript,往往与选择的JavaScript框架有关,选Backbone可以AMD,也可以CMD。选AngularJS直接引用就行。
CSSCSS模块化应该是两方面的问题——
一是模块必须有一套基础样式。与JavaScript相比,CSS冲突简直是家常便饭,Shadow DOM还没成熟,原生的CSS样式隔离还在路上。所以必须有一套基础样式来规定这一套模块化组件的样式。我们可以选Bootstrap,如果闲它太重,也可以自己写。
其次,每个组件必须有命名空间,避免组件间样式冲突。如果选择使用LESS、SASS等,那就比较好办,它们的缩进语法避免写很多重复的CSS代码。
HTML模板如果使用AngularJS,那AngularJS已经帮您解决了模板模块化的问题,AngularJS可以根据模块代码中的引用加载对应的HTML。如果使用Backbone,可以选择各种各样的模板引擎,Mustache?不过比起AngularJS就低端些,我们必须自己处理模板文件,要么通过模块加载器通过XHR请求,然后动态编译;或者将Mustache编译成JS,在当做模块加载。
图片、字体?放在使用他们的模块中,该怎么引用就怎么引用。
国际化文件?这些就不多说了,总之,每种文件需要选定一种开发的组织方式。
模块分发模块采用统一的模式来开发之后,只需选定一种包的分发方式就行了——Bower。npm不适合这样的场景,npm的版本管理太过细致了。如果同一个项目中允许出现同一模块的不同版本,事情就做的太过复杂了。
发布上线发布上线必须一个以终为始的过程。如果你不追求网站或者应用的速度,那就把那些开发文件直接丢到生产服务器上去吧。别说,我还真见过这样的商用的网站。
如果讲究一些方案,资源合并成数个文件,代码线上组合和运行方式完全可以与本地开发不一样。只需要功能在就行。
JavaScript代码打成一个文件,或者两个?都行。如果使用RequireJS,那RequireJS提供了打包的工具,打包成几个文件,什么粒度,都行。如果是Sea.js也有对应的工具。就算文件都是一个一个列出来,我们也总是可以打出来你想要的文件。
CSS等等其他资源都是如此,就算开发时各自不同的结构模式,打包时都是可以打的。
至于上线CDN,版本号缓存什么的并不在本文的讨论范围之内。
总结前端模块没有什么特效药。唯一要遵守的原则就是,比起Node.js来讲,每种资源必须要有一种自己的开发和上线组织方式(Node.js开发和上线都是一致的),开发和上线完全可以是两种方式,大可不必人云亦云,只要适合可以随意组合;CSS在CSS Scoped Style正式使用之前,应该有一套基础样式和沙盒(模块样式命名空间)。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/78153.html
摘要:前端杂谈第一个问题什么是什么是是我们在代码中经常看到的键值对例如上面代码中的节点有三个是对应的节点的对象属性例如第二个问题从上面的例子来看似乎和是相同的那么他们有什么区别呢让我们来看另一段代码在页面加载后我们在这个中输入注意这段代码 前端杂谈: Attribute VS Property 第一个问题: 什么是 attribute & 什么是 property ? attribute 是...
摘要:而在这个微服务下,同样需要进行数据操作,我不可能还要在下再一次进行集成,这样大大的增加了代码量。其次,是将有关数据操作的都单独部署成一个模块,比如我集成的模块,集成的模块,使用作为内存缓存模块。 前言 相对于 spring 对 mybatis 以及 redis 等的整合所需要的各种配置文件,在 springboot 下,已经大大的简化了,你可能只是需要增加个依赖,加个注解,然后在配置文...
阅读 2060·2023-04-25 21:11
阅读 2962·2021-09-30 09:47
阅读 2270·2021-09-24 09:48
阅读 4426·2021-08-23 09:43
阅读 894·2019-08-30 15:54
阅读 558·2019-08-28 18:01
阅读 1396·2019-08-27 10:55
阅读 587·2019-08-27 10:55