大家接触jQuery的时候发现，要做事先绑定，取回数据要塞回去，塞的过程都是要自己关心的。但是利用Angular，数据取回来只要注入变量自动完成了，包括事件绑定。数据绑定，MVVM、依赖注入让你觉得，原先要关心很多东西，现在都不需要关心了，只需更加关心数据结构和业务层，它把我们从繁琐DOM绑定中解脱出来。

二、组件化之路

组件是对数据和方法的简单封装，在此样式类，指令型等具备UI效果的组件，方法等统称组件。在大型软件中，组件化是一种共识，它一方面提高了开发效率，另一方面降低了维护成本。

组件化及组件展现形式

组件化可以有很多事情可以做，比如模板化，现在模板化重任交到前端。第二个是公共样式库，第三公共函数库，一些业务组件，模块化特殊一点。

组件大概展现形式包括： 统一的样式库，具有一定HTML结构的代码片段，具有一部分JS控制的功能函数，具有一定数据输入和输出的控制。

三、揭开云组件的面纱

云以及云组件概念

云是网络和互联网的一种比喻说法。过去往往用云来表示电信网，后来也用来抽象地表示互联网和底层基础设施。

云服务指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。它意味着计算能力也可作为一种商品通过互联网进行流通。把云和组件二者结合则构成了云组件。说到底是希望通过一个统一的控制的东西，把N个项目全部控制在一起。

个推的组件类型

个推的组件类型包括样式类组件、指令型组件、服务型组件、公共过滤器、公共函数库等。

从组件分类里可以发现专属CSS是样式类组件，加上模板就是非常简单的组件，再把加控制器放进去，就是前面讲的具有一定JS和一定逻辑的组件，把link加进去，带了动画，数据层加进去就具备一定的输入输出能力。这个数据层可能包含多种，有可能是跟你的页面控制器交互，也有可能这个组件非常强，自己直接与服务端通信获取数据和传递数据（当然实际实践中可能前者更合适当前我们的环境，后者对统一的接口要求会更高）。

上图是个推云组件的技术方案。基于前端三大件和一些其他库比如地理围栏的组件（需要让百度地图给我们整个项目对接起来），还有可视化的项目，比如G20期间杭州某景区人流情况，可视化项目会用到第三方库。个推利用LESS写CSS，基于这些开发云组件。

根据云组件的一些情况个推得出它的最佳实践对象就是从具有一定通用交互的表格表单类的管理型系统出发，逐渐包含复杂交互的系统应用，并对响应式具有一定的支持。个推是从做推送服务开始，之后有很多产品线。推送服务就会有很多2B、2C的平台，这就是管理型的。

上图是个推云组件采用的目录结构，用的是gulp打包，CSS里面有wd文件夹，主要放了一些第三方的库。更关键主要还是下面，JS也是一样，wd是基础库。第五个是最重要的，所有组件都放在这个文件夹下，每个组件包含自己专属的三大件——模板、逻辑、交互、效果和样式。

基于gulp的打包

云组件展示站点

云组件的使用人员主要分为三大类，第一类是前端使用者（包括泛前端人员），他们需要学习如何使用，快速用组件（须知道Angular的一些基本概念和用法）。第二类是UI设计师、项目和产品等，他们需要观察效果是否是适合的，根据库去设计新的此类系统。第三类是游客和其他人员。

关于云组件的新的思考

云组件牵一发会动全身，如果云组件机制运用不好比如一个老的组件更新出了个bug，会产生很多负面影响，这时该怎么办？

回到云的初始之处我们不难发现，当资源隔绝便不会产生这种影响了（云组件正是利用其反向思维达到的便捷），那么我们相对将云组件资源封闭便可以降低这个影响了。这便是版本控制，不同项目引用相应的云，以达到刚才讲的两者之间的平衡，从而成效最优化。

所以，只有合理控制住才能真正发挥云组件的优势。

多个版本下，我们的开发模式便是就某个项目的云组件升级由该项目决定。因为如果云组件一发版，所有的项目都升级云组件那这个回测的代价就很高了，况且原有的云组件版本也是够之前已经上线的项目的当前版本用了。

个推的项目体系图

实际使用中的问题

云组件的发版有一定的周期性，但实际项目中的需求要快速响应，这时需要采用云组件扩展模块（模式）开发：基于云组件开发本项目的组件级别的模块，对云组件进行扩展或者项目化定制。

四、关于AngularJS的经验与总结

第一、模块化：随时准备模块化抽象，这是一个动态的过程。

第二、多想想周边的，超过所止的部分 —— 换位思考，方便下游，倒推上游。

第三、没有实现不了的效果，只有承受不了的代价。

第四、方法有很多，时间允许的话都可以试试。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持编程之家。