万变不离其宗:横向切割业务/功能,纵向切割技术层。先从功能出发把 site.js 分成多个独立的模块:如果 site.js 只用在一个页面上,就按照页面上的功能拆分成模块;又或者 site.js 用在多个页面中,可以将 site.js 拆分成一对一页面的入口小模块,这些页面之间可能有相似的模块,这些模块也单独拆出来,入口模块放置每个页面单独的逻辑,并组织共享的模块。以一个聊天工具为例,可以拆解为:
虽然是平行放置的,但组件是有层次的,小组件功能独立,大组件负责初始化和组合小组件。再从技术架构的角度将代码划分为多个层次:注意,并不是所有的项目都需要划分层次,可以按照项目的大小和复杂程度划分层次。项目越复杂就越需要注意将代码划分成不同的层次,而简单的项目就没有必要了,甚至代码都不用放在不同的文件。技术分层的方案就是 MVC,不管你或者流行的框架如何解读 MVC,MVC 是一种以不变应万变的架构。例如:components 就放着 View + Controller,View 和 Controller 相对来说联系是比较紧密的,可以放在一起:chat.js 主要用来初始化其他模块,绑定事件,处理事件,充当 Controllerstyle.css 样式,没什么可说的view.html 放着模板,业务简单的话,也可以去掉 view.html 直接在 chat.js 中拼接字符串model:如果项目简单这里放的就是和服务器端进行数据交互的部分,比如 Ajax 请求等。如果项目复杂的话,可以分成两层 Ajax 请求和 Model(View Model 或者数据集中管理的地方)。这部分很可能在很多 component 都会用到,所以可以独立。router:不多说,如果你的项目复杂到一定程度,有 router 的话,这是单独放置的。单独说说 component:一个模块基础组成:config:配置,来自源全局,或者来自于父组件state:自身的状态,比如是聊天是通畅还是短线了,其他方法运行的过程中需要这些状态来判断进一步的操作bindEvents:可以把大堆大堆的 $ 选择绑定事件的代码都放在这里eventHandler:很多事件处理器modifyView:很多对视图更改每个层都会有很多模块,这些模块又是按照业务/功能切分的。工具篇:切分原则都有了,工具的选择也没什么难的。项目不复杂,不重要,模块拆下来之后也不多,那可以用像 RequireJS,Sea.js 这样的加载器。主要就是处理下 JS 的模块化。直接撸了之后,压缩下,也不用合并,就在线上跑着也没啥问题。项目复杂,重要,模块多,那可以用用 browserify,使用 CommonJS,来组织代码(也可以继续使用 RequireJS,生态和工具还可以)。上线的时通过工具做好合并压缩。如果你采用的非常标准的模块化开发,即每个模块都有独自的模板、Controller、样式、图片,那用 webpack 吧,webpack 的优势就如它的名字一样,不是 js bundle,不是js loader,是 webpack,即其他资源也可以帮你打包处理好,这对于全模块化开发来讲就爽多了。不用想该怎么组织除了 JS 之外的资源。