xufei
xufei
在dva的官方仓库里，提供了上手教程，讲述了dva的一些基本概念。到了真实的业务开发过程中，会遇到许许多多不能用那些基本操作覆盖的场景，本文尝试列举一些常见的需求在dva中的实现方式。 ## 动态加载model 有不少业务场景下，我们可能会定义出很多个model，但并不需要在应用启动的时候就全部加载，比较典型的是各类管理控制台。如果每个功能页面是通过路由切换，互相之间没有关系的话，通常会使用webpack的require.ensure来做代码模块的懒加载。 我们也可以利用这个特性来做model的动态加载。 ```JavaScript function RouterConfig({ history, app }) { const routes = [ { path: '/', name: 'IndexPage', getComponent(nextState, cb) { require.ensure([], (require) => { registerModel(app, require('./models/dashboard'));...
老码农的技术理想
## 老码农的技术理想 小时候，老师问我，你的理想是什么？我不假思索说是工程师，于是长大之后果然成了工程师。 工作这么多年，一直在思考工程师这三个字的意义，终于有一天恍然大悟，原来就是：用技术手段改进世界。 那么，在软件方面，目前的世界有哪些问题需要解决呢？有这么一些问题可以思考： - 现在整个世界的信息化程度是偏高还是偏低？ - 程序员的人数够用吗？ - 软件行业的生产力是偏高还是偏低？ - 大部分软件系统都可靠吗？ 我想说说自己对这几个问题的理解。 虽然现在我们的生活与十年前相比，已经发生了巨大变化，比如智能手持设备已经非常普及，可穿戴设备也在蓬勃发展。十年前我们用手机收发短信或者邮件，浏览非常简单而老土的wap页面，但现在，绝大部分人的手机已经取代了电脑，成为日常生活中不可缺少的工具。 我们用手机交流，购物，欣赏影视，阅读书籍，玩各类游戏，尤其是飞速发展的移动购物和支付体系，使得我们能在任意场合购买心仪的物品，订购旅游服务和宾馆，叫快餐，打车等等，生活非常美好，那么，整个世界的信息化程度处于什么级别呢？ 我觉得，才刚刚相当于小学二年级，整个世界的信息化程度仍然严重偏低。从现在算起，往前10年，往后10年，这20年时间中，面向个人的信息化服务处于高速发展期，这个领域非常吸引眼球，因为它与每个人的生活息息相关。可是，另外有一些领域，却非常需要发展，那就是传统行业的信息化。 之前有不少传统行业，进行了一定程度的信息化，但这个信息化仅仅能满足自身运作的基本要求，当它与整个社会的潮流相对接的时候，就显得非常落后，迟缓。比如说在网购这个大体系中，普通用户所能看到的是商品展示，比价，下单的过程，但背后的核心环节却是配货与物流。 我还在上学的时候，有老师这么说过，现在计算机行业非常火热，很可能要饱和了，你们不一定非要从事这方面的工作。现在回头看这句话，觉得很有趣，人真的很难有眼光看到未来。去年我入职苏宁培训的时候，孙为民副总讲了当年一个决策失误的例子。90年代末，公司统计发现全国空调的年销售量达到数百万台，觉得很可怕，这个行业可能要饱和，估计要再想办法拓展别的商品经营了，但现在，全国空调的保有量为七亿台，即使完全没有新增，十年换一轮，每年也卖得出去七千万台，当年凭什么说这就饱和了？ 所以我现在看程序员的状况，仍然是供不应求，尤其是高端程序员，十分抢手。这个问题的背景就是全社会的信息化进程在加速，之前的程序员人数远远跟不上需求量。 那么，如何解决这个问题呢？一方面是继续培训，促使更多新人来到这个行业，并且认真做下去，另外还有一些别的手段需要考虑。 我想追问一个问题：世界上懂业务的人多，还是懂技术的人多？很明显，懂业务的人要多很多，什么叫业务？其实就是行业常识，生活经验。 比如说，一个有经验的仓库保管员，可能文化程度不高，理解不了软件的运行原理之类，但一定对产品出库入库的流程非常熟悉，包括各种审批过程和异常状况，但这些，程序员是不懂的。那如果要促进这个领域的信息化，必然要在两者之间寻找一个结合点，程序员可以学业务，业务人员也可以尝试参与软件研发过程，目前来说，都是前者比较多，因为程序员相对来说还是比较年轻，学东西快些。但从整体社会效益来说，这其实是不利的，因为程序员是更稀缺资源，而传统业务人员非常多。 之前见过一个问题：如何让业务人员更好地参与软件研发过程。这个问题的根本解决方法是DSL（Domain Specific Language），核心解决方案是二次开发平台。 什么是DSL和二次开发平台呢，这两个词听上去很高端，但其实大家有很常用的东西就属于这个范畴，比如Excel，它提供了各种各样的公式，还有VBA，使用这些东西的人绝大部分不是软件行业的，Excel就是一种很成功的二次开发平台，公式和VBA就可以算DSL了。 很多时候这些东西还不够直观，我们可以看到一些图形化的编程语言，比如Scratch，现在很多小学生的兴趣班就会学，这些东西相对学起来就比较容易了，我们也可以做一些类似的抽象，以图形化的方式让业务人员能够参与，比如流程配置等等。图形化的东西，是最适合非技术人员理解的。 所以，要促进社会的信息化程度，最好是能够想办法把各行业的业务人员都拖进来一起搞。具体的分工大致是：技术人员和业务人员一起定义DSL，技术人员负责DSL的底层平台实现，业务人员负责使用它来构建业务模型和业务流程，甚至业务界面。 那么，软件行业的生产力是偏高还是偏低呢？我认为严重偏低。什么叫严重偏低？如果以机械力量的变革来对比，软件行业目前的生产力水平处于蒸汽机发明之前。也就是说，生产力远远没有被解放，大家做的大部分东西将来是会被机械化的，不再需要这么多人来做这么重复的劳动。可能很多人会对这段话不满，怎么就重复劳动了，你说说我做的什么是可以被机器替代的？...
给一位打算从事前端，但是又有疑惑的在校大学生的回信 抱歉这么晚才回复这个邮件，主要是觉得你的问题有典型性，想要详细一点给出答复。 所谓的前端，在不同的公司，定义是不同的，工作内容也会有差异，有的还很大。比如有很多公司，没有专门的前端分类，所有的都属于开发人员，一些比较传统的公司，还有一些人数较少的小公司会是这样。又比如有些公司，前端人员的职责仅限于静态页面和交互效果，然后把这些东西交给业务开发人员去编写业务的JS代码。还有一些公司，前端除了PC和移动端的Web，还包括各种移动终端的开发。 这些种种不同，都是各公司自身的业务特点决定的，大体上比较适合各自的业务场景，越大的公司，内部的分工可能越明确，所以也就有了你看到的，有比较偏向JS的，有比较偏向CSS的。 个人选择什么方向，我觉得需要问自己两个问题： 1. 你是一个怎样的人 这个的意思是，你觉得自己学js和css的时候，哪种觉得更轻松愉快，容易领悟。一个人选择自己最容易领悟的方面去学习，会事半功倍。 1. 你希望成为一个怎样的人 人的一生，实际上很大程度是职业细分的过程，每个人在他工作的前10年，都可能会逐步深入到某些领域，他的知识广度可能会逐步增加，但能够深入的，往往在一两个分支上。 从大的方面看，最初的软件体系基本都是以服务端为主，客户端通过字符界面去进行操作，后来桌面程序迅速发展，再后来Web兴起，最近各种终端的流行，更加促使广义的“前端”这个领域有更多的发挥空间。整体来说，后端的发展趋势是服务化，前端的发展趋势是多样化。因为消费者的促进，前端的需求和发展会是非常乐观的，无论在其中选择哪个细分方向，只要努力下去，成为这个领域的专家，肯定都会有所成就。 目前，在很多公司，搞CSS一般还没有独立职位，或者即使有，暂时比搞JS的还是稍微弱势一些，正如前端部门一般比后端部门弱势，但这种状况会好转的，每个领域都会得到适合自己的发挥。 关于原生JS和某些库的学习，我的观点是这样，除了一些很特别很怪异的点，对于语言本身的常规用法是需要都掌握的，其实也不多，常用到的就那么些。一般说的原生JS，是包括JS语言本身，还有它对DOM和BOM的操作，比如元素的创建移除，事件的添加等等，这些应该都需要懂。至于说对于某个库的学习，更重要的是学习它的思维方式，每看一个例子，就先想一想如果自己写，会把代码写成怎样，再与真实的例子进行对照，举一反三，这样的学习会是很快的过程。 现在这个时代，各种浏览器还在混战，但低版本IE的淘汰已经成为了必然，如果是现在开始学习，一定要着眼于将来，多看看CSS3各子集的规范，了解ES新版本的特性，因为世界迟早是它们的。对于低版本浏览器的兼容，一般都会有成熟的解决方案，当遇到具体问题的时候再去看也可以。 很多人看待前端，是把它当作一个很浅的层面来看的，其实前端的人多了解一些别的领域也是有好处的，从中能得到很多领悟，比如软件工程，设计模式，它们对不管什么方面的开发人员而言，都是很好的指导。 一个成熟的前端开发人员，他应当有比较宽的知识面，同时至少在某一两个细分领域有专注的研究和见解。平时在日常生活中，也可以多注意观察一些产品，对自己正在做的整个产品有深刻认识，对生活常识有充分了解，有时候也会有助于减少开发过程中走的弯路。 能够对自己的未来有所预期，并且主动寻找学习的途径，这说明你有很好的开始，在前端这条道路上认真走下去，相信会有美好的未来。
## Angular 1.x和ES6的结合 在Web前端技术飞速发展的今天，Angular 1.x可以说是一个比较旧的东西，而ES6是新生事物。我们想要把这两个东西结合起来，感觉就好像“十八新娘八十郎，苍苍白发对红妆。”但这件事的难度也并不大，因为我们最终是要把ES6构建成ES5代码，而ES5代码是可以很容易和Angular 1.x协作的。 不过，为什么我们要干这件事呢？ 在[这篇文章](https://www.zhihu.com/question/38571416/answer/77067217)中，我提到过： > 尽管在整个前端开发圈中，大家并不是很欢迎Angular，而且很多人认为它的1.x版本已经衰落，但我跟 @小猪有个观点是一致的，那就是：“在企业开发领域，ng1的应用才方兴未艾”，也就是说，它在这个领域其实还是上升阶段。 所以，在不少场合下，它还是要承载一些开发工作，部分老系统的逐步平滑迁移也是比较重要的。 做这件事的另外一个意图是：虽然未来的框架选型会有不少争议，但有一点毋庸置疑，那就是业务JS代码的全面ES6或者TS化，这一点我们现在就可以着手去做，并且可以尽量把数据和业务逻辑层实现成框架无关的形式。 在[这篇](https://github.com/xufei/blog/issues/24)里大致讲了点对这方面的考虑。 ### 模块机制 Angular 1.x的module机制是比较别扭的，也是一种框架私有的模块机制，所以，我们需要淡化这层东西，具体的措施是： - 把各功能模块的具体实现代码独立出来 - module机制作为一个壳子，对功能模块进行包装 - 每个功能分组，使用一个总的壳子来包装，减少上级模块的引用成本 - 每个壳子文件把module的name属性export出去 举例来说，我们有一个moduleA，里面有serviceA，serviceB，那么，就有这样一些文件： _serviceA的实现，service/a.js_ ``` JavaScript...
# 从HTML Components的衰落看Web Components的危机 搞前端时间比较长的同学都会知道一个东西，那就是HTC（HTML Components），这个东西名字很现在流行的Web Components很像，但却是不同的两个东西，它们的思路有很多相似点，但是前者已是昨日黄花，后者方兴未艾，是什么造成了它们的这种差距呢？ ## HTML Components的一些特性 因为主流浏览器里面只有IE支持过HTC，所以很多人潜意识都认为它不标准，但其实它也是有标准文档的，而且到现在还有链接，注意它的时间！ [http://www.w3.org/TR/NOTE-HTMLComponents](http://www.w3.org/TR/NOTE-HTMLComponents) 我们来看看它主要能做什么呢？ 它可以以两种方式被引入到HTML页面中，一种是作为“行为”被附加到元素，使用CSS引入，一种是作为“组件”，扩展HTML的标签体系。 ### 行为 行为（Behavior）是在IE5中引入的一个概念，主要是为了做文档结构和行为的分离，把行为通过类似样式的方式隔离出去，详细介绍在这里可以看： [http://msdn.microsoft.com/en-us/library/ms531079(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/ms531079%28v=vs.85%29.aspx) 行为里可以引入HTC文件，刚才的HTC规范里就有，我们把它摘录出来，能看得清楚一些： _engine.htc_ ``` HTML function doCalc() { : oEvent = createEventObject(); oEvent.result...
上半年，我写过一篇[《2015前端组件化框架之路》](https://github.com/xufei/blog/issues/19)，现在大半年过去了，这段时间一直在思考，未来的东西是怎样的。 目前我主导着苏宁的云计算相关的所有前端项目，这些项目以控制台为主，几乎都广泛使用了Angular 1.x，一方面因为个人技能之前有积累，一方面因为产品的开发人员基本都是Java方向转岗，对Angular的接受度较高，上手非常快，开发效率也非常高。 但2015年，前端的世界发生了很多变化，这些变化快得超出我想象。在这个巨变的时代，产品的技术选型是个麻烦的事情，具体来说，有几个方面： - 如果2-3年后新开始一个业务项目，可能会有什么样的技术方案？ - 如果现在立刻开始一个新业务项目，可能会有什么样的技术方案？ - 如果持续维护老的项目，后面可能会对它们有怎样的迁移方案？是逐步迁移，还是推倒重做？ - 在PC端项目为主体的业务体系里，如果将来某个时机出现了移动端项目，该如何去选型，并且利用之前的业务代码？ 我之前没有预料到的，是ES6的普及之快。在此之前，对于新的语言特性，人们一般会等到支持的浏览器普及之后，才会大量使用，比如ES5，但由于Babel这样转译的工具出现，我们可以渐进使用，所以，开发过程中可以完全使用ES6甚至ES7的特性编写代码，然后通过构建去达到兼容的结果。 有鉴于此，在未来的项目中，使用ES语言新特性进行开发，是一个必然要做的事情。但，这并不能算是整体方案。整体的方案应当包括但不限于： - 使用什么基础框架 - 业务代码如何规划 - UI组件如何规划 - 样式和主题如何规划 - 构建方案怎样 - 人员如何协作 - …… 所以，我们面临的，还是基础框架选型这么一个重大问题。照理说，使用Angular 1.x，后续应当选择往2.0版本过渡，但现在这个阶段，乱花迷人眼，谁也不知道未来的事情怎样，在这一层上，我个人觉得还是要再看看。...
十年来感受的前端技术变化
07年底，我所在的团队需要重构一个产品，在此之前，我们的前端框架是这样的： - 使用HTML Components（htc）作为基础控件的实现方式，包括选项卡，树形表格，日期选择等控件。 - 在原生js的基础上作了一些简单封装，形成了包括表单校验，弹出菜单（基于popup），简单图表（基于XML），动态表单等功能的业务公共库。 - 使用XMLHTTP作为前后端通信方式，将请求参数序列化为XML发送给服务端，反序列化之后，反射调用后端服务（Java和.net），再把返回结果序列化为XML传输回来，用JS解析为JavaScript对象。这个传输方式从03年版本就开始使用，还在AJAX概念出现之前，只是一直使用的是同步传输方式，调用的时候界面会卡死。 - 开发方式也是前后端分离的，前端只写HTML和JS，后端提供接口（但并不是HTTP接口，而是服务端的类接口，然后通过一个统一的facade类去反射调用）。 这个时期的版本不用说，肯定都是只支持IE的，我们当时需要兼容的浏览器包括IE 5.0，5.5，6，后来7出来之后还需要支持7。 这个产品重构的目的是，对近几年积累的业务需求进行整合，并且把服务端完全迁移到Java。对于前端来说，其实不做迁移也可以，但当时我们发现一个问题，FireFox这个东西突然崛起了，所以，我们从原先面临的只支持IE，变成了可能要支持跨浏览器。 所以我们觉得需要把这个事情做一下，因为当时判断，IE的份额可能会下降到70%左右，FireFox可能会占有25-30%的份额，这个兼容是有可能需要的，虽然以我们的场景，几乎全部面向行业用户，可以把浏览器限制得很死，但也有部分用户自服务的产品，将来还有扩大的趋势。 这时候我们问题就很大了，因为前端的基础功能面临大改，一些校验之类的库好办，通信封装也好办，基于htc的控件就是个大问题了，必须全部重写。 当时几个成员产生了热烈的讨论，jQuery那时候还没有一家独大，也没有产生这种趋势，可选项包含： - ExtJS这样的全整合框架 - jQuery，prototype，mootools，Ext Core这样的核心js库加外围 在这两个选择里，我们排除了第一个，因为虽然看上去它很符合我们的业务场景，但我们的定制化需求比较多，不确定有能力在这个基础上做定制，可控性不好。 所以我们就决定选一个核心js库，然后自己开发外围控件。那么，选谁呢？最终选的是prototype，因为大家判断，我们不需要类似class的机制，这样就把后面两个排除了，而我们不需要太多DOM方面的封装，因为最后业务上需要直接操作DOM的东西不会很多，都会被我们封装掉，所以又把jQuery排除了。 所以我们的需求其实也很明确，就是有一定基础功能的js核心库。然后就是在这个基础上开发控件了，时间也很仓促，大约只有2-3个人，2-3个月，最后几个东西： - 数据表格 - 树形表格 - 日期选择（我们的日历需求比较变态，因为有伊朗和尼泊尔客户，所以会有波斯日历和尼泊尔日历之类。。。）...
这几年来，各类前端组件化框架层出不穷，江山代有框架出，各领风骚几个月。 回头看两三年前（2014年初）的情况，大致是这样的： - Backbone / Knockout，有较大用户量，但已经逐步衰落了 - Angular1，很火，快速增长 - React，起步略晚，快速增长 - Ember，不少人用 - Polymer，新东西 - Vue / Avalon，新东西，没有angular那么强的约束 - RactiveJS，新东西 现在来看，他们的状况分别是这样： - Backbone / Knockout，衰落，很少人提起 - Angular1，停止增长，存量大，大家都觉得过时了 - React，持续增长 -...
# Web应用的组件化（一） ## 基本思路 #1. 为什么要做组件化？ 无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。 减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux + Mono来部署.net应用，避开Windows Server的费用。 提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。 我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门，座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。 席德梅尔出过一款很不错的游戏，叫做《文明》（Civilization），在第三代里面，有一项科技研究成功之后，会让工人工作效率加倍，这项科技的名字就叫做：可替换部件（Replacement Parts）。所以，软件行业也应当引入可替换的部件，一般称为组件。 #2. 早期的前端怎么做组件化的？ 在服务端，我们有很多组件化的途径，像J2EE的Beans就是一种。组件建造完成之后，需要引入一些机制来让它们可配置，比如说，工作流引擎，规则引擎，这些引擎用配置的方式组织最基础的组件，把它们串联为业务流程。不管使用什么技术、什么语言，服务端的组件化思路基本没有本质差别，大家是有共识的，具体会有服务、流程、规则、模型等几个层次。 早期展示层基本以静态为主，服务端把界面生成好，浏览器去拿来展示，所以这个时期，有代码控制的东西几乎全在服务端，有分层的，也有不分的。如果做了分层，大致结构就是下图这样：  这个图里，JSP（或者其他什么P，为了举例方便，本文中相关的服务端技术都用Java系的来表示）响应浏览器端的请求，把HTML生成出来，跟相关的JavaScript和CSS一起拿出去展示。注意这里的关键，浏览器端对界面的形态和相关业务逻辑基本都没有控制权，属于别人给什么就展示什么，想要什么要先提申请的尴尬局面。 这个时期的Web开发，前端的逻辑是基本可忽略的，所以前端组件化方式大同小异，无论是ASP还是JSP还是其他什么P，都可以自定义标签，把HTML代码和行间逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。 在这一时代，所谓的组件化，基本都是taglib这样的思路，把某一块界面包括它的业务逻辑一起打成一个端到端的组件，整个非常独立，直接一大块从界面到逻辑都有，而且逻辑基本上都是在服务端控制，大致结构如下图所示。  #3. SPA时代，出现了新问题 自从Web2.0逐渐流行，Web前端已经不再是纯展示了，它逐渐把以前在C/S里面做的一些东西做到B/S里面来，比如说Google和微软的在线Office，这种复杂度的Web应用如果还用传统那种方式做组件化，很显然是行不通的。 我们看看之前这种组件化的方式，本质是什么？是展现层跟业务逻辑层的隔离，后端在处理业务逻辑，前端纯展现。如果现在还这么划分，就变成了前端有界面和逻辑，后端也有逻辑，这就比较乱了。我们知道，纯逻辑的分层组件化还是比较容易的，任何逻辑如果跟展现混起来，就比较麻烦了，所以我们要把分层的点往前推，推到也能把单独的展现层剥离出来。...
构建单页Web应用
# 构建单页Web应用 ## 单页应用是什么？ 让我们先来看几个网站： [coding](https://coding.net/) [teambition](https://www.teambition.com/) [cloud9](https://c9.io/) 注意这几个网站的相同点，那就是在浏览器中，做了原先“应当”在客户端做的事情。它们的界面切换非常流畅，响应很迅速，跟传统的网页明显不一样，它们是什么呢？这就是单页Web应用。 所谓单页应用，指的是在一个页面上集成多种功能，甚至整个系统就只有一个页面，所有的业务功能都是它的子模块，通过特定的方式挂接到主界面上。它是AJAX技术的进一步升华，把AJAX的无刷新机制发挥到极致，因此能造就与桌面程序媲美的流畅用户体验。 其实单页应用我们并不陌生，很多人写过ExtJS的项目，用它实现的系统，很天然的就已经是单页的了，也有人用jQuery或者其他框架实现过类似的东西。用各种JS框架，甚至不用框架，都是可以实现单页应用的，它只是一种理念。有些框架适用于开发这种系统，如果使用它们，可以得到很多便利。 ## 开发框架 ExtJS可以称为第一代单页应用框架的典型，它封装了各种UI组件，用户主要使用JavaScript来完成整个前端部分，甚至包括布局。随着功能逐渐增加，ExtJS的体积也逐渐增大，即使用于内部系统的开发，有时候也显得笨重了，更不用说开发以上这类运行在互联网上的系统。 jQuery由于偏重DOM操作，它的插件体系又比较松散，所以比ExtJS这个体系更适合开发在公网运行的单页系统，整个解决方案会相对比较轻量、灵活。 但由于jQuery主要面向上层操作，它对代码的组织是缺乏约束的。如何在代码急剧膨胀的情况下控制每个模块的内聚性，并且适当在模块之间产生数据传递与共享，就成为了一种有挑战的事情。 为了解决单页应用规模增大时候的代码逻辑问题，出现了不少MV*框架，他们的基本思路都是在JS层创建模块分层和通信机制。有的是MVC，有的是MVP，有的是MVVM，而且，它们几乎都在这些模式上产生了变异，以适应前端开发的特点。 这类框架包括Backbone，Knockout，AngularJS，Avalon等。 ## 组件化 这些在前端做分层的框架推动了代码的组件化，所谓组件化，在传统的Web产品中，更多的指UI组件，但其实组件是一个广泛概念，传统Web产品中UI组件占比高的原因是它的厚度不足，随着客户端代码比例的增加，相当一部分的业务逻辑也前端化，由此催生了很多非界面型组件的出现。 分层带来的一个优势是，每层的职责更专一了，由此，可以对其作单元测试的覆盖，以保证其质量。传统UI层测试最头疼的问题是UI层和逻辑混杂在一起，比如往往会在远程请求的回调中更改DOM，当引入分层之后，这些东西都可以分别被测试，然后再通过场景测试来保证整体流程。 ## 代码隔离 与开发传统页面型网站相比，实现单页应用的过程中，有一些比较值得特别关注的点。 从单页应用的特点来看，它比页面型网站更加依赖于JavaScript，而由于页面的单页化，各种子功能的JavaScript代码聚集到了同一个作用域，所以代码的隔离、模块化变得很重要。 在单页应用中，页面模板的使用是很普遍的。很多框架内置了特定的模板，也有的框架需要引入第三方的模板。这种模板是界面片段，我们可以把它们类比成JavaScript模块，它们是另一种类型的组件。 模板也一样有隔离的需要。不隔离模板，会造成什么问题呢？模板间的冲突主要存在于id属性上，如果一个模板中包含固定的id，当它被批量渲染的时候，会造成同一个页面的作用域中出现多个相同id的元素，产生不可预测的后果。因此，我们需要在模板中避免使用id，如果有对DOM的访问需求，应当通过其他选择器来完成。如果一个单页应用的组件化程度非常高，很可能整个应用中都没有元素id的使用。 ## 代码合并与加载策略...