上图是个推云组件采用的目录结构，用的是gulp打包，CSS里面有wd文件夹，主要放了一些第三方的库。更关键主要还是下面，JS也是一样，wd是基础库。第五个是最重要的，所有组件都放在这个文件夹下，每个组件包含自己专属的三大件——模板、逻辑、交互、效果和样式。
基于gulp的打包
云组件展示站点
云组件的使用人员主要分为三大类，第一类是前端使用者（包括泛前端人员），他们需要学习如何使用，快速用组件（须知道Angular的一些基本概念和用法）。第二类是UI设计师、项目和产品等，他们需要观察效果是否是适合的，根据库去设计新的此类系统。第三类是游客和其他人员。
关于云组件的新的思考
云组件牵一发会动全身，如果云组件机制运用不好比如一个老的组件更新出了个bug，会产生很多负面影响，这时该怎么办？
回到云的初始之处我们不难发现，当资源隔绝便不会产生这种影响了（云组件正是利用其反向思维达到的便捷），那么我们相对将云组件资源封闭便可以降低这个影响了。这便是版本控制，不同项目引用相应的云，以达到刚才讲的两者之间的平衡，从而成效最优化。
所以，只有合理控制住才能真正发挥云组件的优势。
多个版本下，我们的开发模式便是就某个项目的云组件升级由该项目决定。因为如果云组件一发版，所有的项目都升级云组件那这个回测的代价就很高了，况且原有的云组件版本也是够之前已经上线的项目的当前版本用了。
个推的项目体系图
实际使用中的问题
云组件的发版有一定的周期性，但实际项目中的需求要快速响应，这时需要采用云组件扩展模块（模式）开发：基于云组件开发本项目的组件级别的模块，对云组件进行扩展或者项目化定制。
四、关于AngularJS的经验与总结
第一、模块化：随时准备模块化抽象，这是一个动态的过程。
第二、多想想周边的，超过所止的部分 —— 换位思考，方便下游，倒推上游。
第三、没有实现不了的效果，只有承受不了的代价。