AngularJS是google设计和开发的一套前端开发框架，帮助开发人员简化前端开发的负担。AngularJS将帮助标准化的开发web应用结构而且提供了针对client应用的未来开发使用的模板。AngularJS很全面且简单易学习，AngularJS高速的成为了javascript的主流框架，帮助开发人员专业的从事web开发。
一、Amazing的Angular
AnguarJS的一些特性
（1）方便的REST： RESTful逐渐成为了标准的server和client沟通的方式。使用一行javascript代码，你就能够高速的从server端得到数据。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是样式类组件，加上模板就是很easy的组件。再把加控制器放进去，就是前面讲的具有一定JS。具有一定逻辑的组件。把link加进去。带了动画。数据层加进去就具备一定的输出输入。这个数据层可能包括多种。有可能是你跟你的页面控制器交互，也有可能这个组件很强，自己直接与服务端通信获取数据和传递数据（当然实际实践中可能前者更合适当前我们的环境，后者对统一的接口要求会更高）。
这是个推云组件的技术方案。基于前端三大件和一些其它库。比方会有一些地理围栏的组件。须要让百度地图给我们整个项目对接起来，还有可视化的项目。比方G20那边人流怎么样。可视化项目会用到第三方库。我们用的是LESS写CSS。基于这些之上开发云组件。
依据云组件的一些情况我们得出它的最佳实践对象就是从具有一定通用交互的表格表单类的管理型系统出发。逐渐包括复杂交互的系统应用，并对响应式具有一定的支持。个推是从做推送服务開始，之后有非常多产品线。
推送服务就会有非常多2B、2C的平台，这就是管理型的。
上图是个推云组件採用的目录结构。用的是gulp打包，CSS里面有wd目录。主要放了一些第三方的库。更关键主要还是以下。JS也是一样，wd是基础库。
第五个是最重要的，全部组件都放在这个目录下，右边图就说明了每一个组件包括自己专属的三大件——模板、逻辑、交互、效果和样式。
基于gulp的打包
云组件展示网站
云组件的使用人员主要分为三大类，第一类是前端使用者（包含泛前端人员），他们须要学习怎样使用，高速用组件（须知道Angular的一些基本概念和使用方法）。第二类是UI设计师、项目和产品等。他们须要观察效果是否是适合的，依据库去设计新的此类系统。第三类是游客和其它人员。
关于云组件的新的思考
基于云的理念是正向的牵一发而动全身，但实际上这个机制运用不好（比方一个老的组件更新出了个bug），便会打开了负面的牵一发动全身了。这时该怎么办？
回到云的初始之处我们不难发现。当资源隔绝便不会产生这样的影响了（云组件正是利用其反向思维达到的便捷）。那么我们相对将云组件资源封闭便能够减少这个影响了。这便是版本号控制。
不同项目引用对应的云，以达到刚才讲的两者之间的平衡，从而成效最优化。
所以，仅仅有合理控制住才干真正发挥云组件的优势。
多个版本号下，我们的开发模式便是就某个项目的云组件升级由该项目决定。由于假设云组件一发版，全部的项目都升级云组件那这个回測的代价就非常高了，况且原有的云组件版本号也是够之前已经上线的项目的当前版本号用了。
个推的项目体系图
实际使用中的问题
云组件的发版有一定的周期性，但实际项目中的需求要高速响应，这时须要採用云组件扩展模块（模式）开发：基于云组件开发本项目的组件级别的模块。对云组件进行扩展或者项目化定制。
四、经验之谈
第一、模块化：随时准备模块化抽象，这是一个动态的过程。 第二、多想想周边的，超过所止的部分 —— 换位思考。方便下游，倒推上游。 第三、没有实现不了的效果，仅仅有承受不了的代价。
第四、方法有非常多。时间同意的话都能够试试。