AngularJS是google设计和开发的一套前端开发框架，帮助开发人员简化前端开发的负担。AngularJS将帮助标准化的开发web应用结构并且提供了针对客户端应用的未来开发使用的模板，AngularJS非常全面且简单易学习，AngularJS快速的成为了JavaScript的主流框架，帮助开发者专业的从事web开发。
一、Amazing的Angular
AnguarJS的一些特性
（1）方便的REST： RESTful逐渐成为了标准的服务器和客户端沟通的方式。使用一行javascript代码，你就可以快速的从服务器端得到数据。AugularJS将这些变成了JS对象，作为Model，遵循MVVM(model view view-model)设计模式。
（2）MVVM救星：这是一个技术，更是一个思想。Model将和ViewModel互动（通过$scope对象），将监听Model的变化。这些可以通过View来发送和渲染，由HTML来展示你的代码。View可以通过$routeProvider对象来支配，所以你可以深度的链接和组织你的View和Controller，将他们变成导航URL。AngualrJS同时提供了无状态的Controller，可以用来初始化和控制$scope对象。
（3）数据绑定和依赖注入：在MVVM设计模式中的任何东西无论发生任何事情都自动的和UI通信。这帮助我们去除了wrapper，getter/setter方法或者class定义。AngularJS将帮助我们处理所有的这些内容，所以你可以处理数据像处理基本javascript数据类型。当然你也可以通过自定义处理复杂数据。正因为所有事情的发生都是自动的，所以你不必调用一个main()来执行你的代码，而是通过依赖关系来驱动。
（4）可扩展的HTML：大多数的网站都是使用非语义的<div>标签来搭建的。你需要自己在CSS的class中定义相关的DOM层次结构。而使用AngularJS，你可以操作XML一样操作HTML，给你无穷的方式来完成标签和属性定义。AngularJS通过自己的编译器和directives来完成相关的设置。而这也是组件实现的基石。
大家接触jQuery的时候发现，要做事先绑定，取回数据要塞回去，塞的过程都是要自己关心的。但是Angular，数据取回来只要注入变量自动完成了，包括事件绑定。数据绑定，MVVM、依赖注入让你觉得，原先要关心很多东西，现在都不需要关心了，只需更加关心数据结构和业务层，把我们从繁琐DOM绑定中解脱出来。（可在附录——AnguarJS使用前后对比——中查看到早期我用jQuery做的账号模块和后来用ng模式下的区别）
二、组件化之路
组件是对数据和方法的简单封装，在此样式类，指令型等具备UI效果的组件，方法等统称组件。在大型软件中，组件化是一种共识，它一方面提高了开发效率，另一方面降低了维护成本。
组件化及组件展现形式
组件化可以有很多事情可以做，比如模板化，现在模板化重任交到前端。第二个是公共样式库，第三公共函数库，一些业务组件，模块化特殊一点。
因此可以得出组件大概展现形式包括： 统一的样式库，具有一定HTML结构的代码片段，具有一部分JS控制的功能函数，具有一定数据输入和输出的控制。
三、揭开云组件的面纱
什么是云以及云组件
云服务是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。云服务指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。它意味着计算能力也可作为一种商品通过互联网进行流通。把云和组件二者结合则构成了云组件。
所以云组件，通过线上的资源，结合这个概念把这两个概念合在了一起就产生了这个概念。说到底是希望通过一个统一的控制的东西，把N个项目全部控制在一起。
个推的组件
个推的组件类型就包括了样式类组件、指令型组件、服务型组件、公共过滤器、公共函数库等。
从组件分类里可以发现专属CSS是样式类组件，加上模板就是非常简单的组件，再把加控制器放进去，就是前面讲的具有一定JS，具有一定逻辑的组件，把link加进去，带了动画，数据层加进去就具备一定的输出输入。这个数据层可能包含多种，有可能是你跟你的页面控制器交互，也有可能这个组件非常强，自己直接与服务端通信获取数据和传递数据（当然实际实践中可能前者更合适当前我们的环境，后者对统一的接口要求会更高）。
这是个推云组件的技术方案。基于前端三大件和一些其他库，比如会有一些地理围栏的组件，需要让百度地图给我们整个项目对接起来，还有可视化的项目，比如G20那边人流怎么样，可视化项目会用到第三方库。我们用的是LESS写CSS。基于这些之上开发云组件。
根据云组件的一些情况我们得出它的最佳实践对象就是从具有一定通用交互的表格表单类的管理型系统出发，逐渐包含复杂交互的系统应用，并对响应式具有一定的支持。个推是从做推送服务开始，之后有很多产品线。推送服务就会有很多2B、2C的平台，这就是管理型的。
上图是个推云组件采用的目录结构，用的是gulp打包，CSS里面有wd文件夹，主要放了一些第三方的库。更关键主要还是下面，JS也是一样，wd是基础库。第五个是最重要的，所有组件都放在这个文件夹下，右边图就说明了每个组件包含自己专属的三大件——模板、逻辑、交互、效果和样式。
基于gulp的打包
云组件展示站点
云组件的使用人员主要分为三大类，第一类是前端使用者（包括泛前端人员），他们需要学习如何使用，快速用组件（须知道Angular的一些基本概念和用法）。第二类是UI设计师、项目和产品等，他们需要观察效果是否是适合的，根据库去设计新的此类系统。第三类是游客和其他人员。
关于云组件的新的思考
基于云的理念是正向的牵一发而动全身，但实际上这个机制运用不好（比如一个老的组件更新出了个bug），便会打开了负面的牵一发动全身了，这时该怎么办？
回到云的初始之处我们不难发现，当资源隔绝便不会产生这种影响了（云组件正是利用其反向思维达到的便捷），那么我们相对将云组件资源封闭便可以降低这个影响了。这便是版本控制。不同项目引用相应的云，以达到刚才讲的两者之间的平衡，从而成效最优化。
所以，只有合理控制住才能真正发挥云组件的优势。
多个版本下，我们的开发模式便是就某个项目的云组件升级由该项目决定。因为如果云组件一发版，所有的项目都升级云组件那这个回测的代价就很高了，况且原有的云组件版本也是够之前已经上线的项目的当前版本用了。
个推的项目体系图
实际使用中的问题
云组件的发版有一定的周期性，但实际项目中的需求要快速响应，这时需要采用云组件扩展模块（模式）开发：基于云组件开发本项目的组件级别的模块，对云组件进行扩展或者项目化定制。
四、经验之谈
第一、模块化：随时准备模块化抽象，这是一个动态的过程。
第二、多想想周边的，超过所止的部分 —— 换位思考，方便下游，倒推上游。
第三、没有实现不了的效果，只有承受不了的代价。
第四、方法有很多，时间允许的话都可以试试。
声明：本篇博客转载自：http://blog.csdn.net/androilly/article/details/52883368