背景
前端经历了初期的野蛮生长(切图,写简单的特效)——为了兼容浏览器兼容性而出现的各种类库(JQUERY,YUI等——mv*(饱暖思淫欲,代码多了,也就想到怎样组织代码结构,backbone,angularjs等)——工程化(利用grunt,gulp,yeoman做项目脚手架以及打包部署),然而这些东西配置起来需要一定的门槛,并且需要跟业务耦合。全端化、全栈化以及工程化的大环境下,我们希望有这样一套工具可以尽量多的支持业务场景,尽量少的配置,尽量简单的使用命令。而DBL就是这样一个前端自动化工具,主要功能:项目脚手架,本地server(实时监控,修改立即生效),本地可视化mock数据并会自动化生成接口文档,deploy项目。下面会详细介绍该工具的使用。
安装dbl工具
sudo npm install dbl -g
dbl -V
项目脚手架
mkdir demo && cd demo
dbl init
运行命令后,dbl会为我们初始化项目结构:
|-demo
|-- src
|-- index.html
|-- css
|-- js
|-- make-webpack.config.js
|-- package.json
|-- aliasMap.json
...
如何使用及工具优势
我们的项目脚手架依赖webpack(如果对此不熟悉的可以自行谷歌),优势在于:
- 比起grunt,gulp,在配置上要简单很多。另外,grunt,gulp只是作为打包工具,如果要做模块化开发,还必须引入requirejs或者seajs。而用了dbl,你完全不用考虑那些麻烦的配置问题,一切都帮你配置好了,你可以像写node一样写js了。
- 模块化开发,一个完整模块应该包含html,css,js。在传统工具中,我们很难维护模块css和js保持同步。而dbl,可以用做到在开发过程中直接这样使用:
/**这是文件 component/list.js**/
require('component/list.less')
工具会自动把less编译成css,并且在html页面上生成style标签,并把css插入进去。细心的你可能会说,html应该对于style标签有个数限制,太多无法支持。而且如果上线时采用这种方式不能很好的利用cdn缓存——不过,不用担心,deploy的时候,我们会把这些style提取出来,根据页面级别合并成一个css文件。
- 资源尽量利用浏览器缓存。利用angularjs + requirejs,如果有多个vm页面,公用的资源我们习惯用grunt-requirejs根据页面打包在一起。这样做,就忽视了浏览器缓存对于性能的影响。而dbl,如果有两个页面共同引用了一个模块,这个模块将会被打包到common.js。
- 支持less,sass(这个考虑到很多用户安装时会出问题,如果需要自己在 make-webpack.config.js配置里加上即可)。这种可配置的方式极大的考虑了扩展。
- 本地server。修改自动生效,而且几乎是瞬时的。
- 本地mock数据。mock数据是通过启用另外一个node服务作为数据提供方。
dbl server -p 3001
此命令运行后,mock服务自动启动。默认端口是8001——注意server和mock是两个独立服务。mock服务可以可视化编辑接口,会自动生成接口文档,方便前后端合作。而且只要项目在,理论上这个文档一定是最新的。比记录在doc文档系统方便多了。你可以通过:http://localhost:8001 访问,界面长这样:
- dbl deploy 命令会把资源进行打包压缩,并且在当前目录下生成build文件夹。到这里,你就可以愉快的把此目录上传到cdn上了。