为什么组件化
技术建模的需要
业务的生命周期，哪怕相同的业务，不同的项目都会有不同的业务流程。这就是业务的生命周期。但是哪怕看上去不同的业务流程，比如预售和直售，哪怕很多不同，但是ui层看，展示结构和内容形式也会有共性。如果不同业务模型我们都写一份代码，就会很低效且维护成本高，所以这时候我们就需要系统抽象能力，做技术抽象建模。 尽管业务千变万化，但是其ui是可抽象的，在前端上，我们可以基于ui的抽象进行技术抽象 技术抽象的一种思路是：把具有相同布局结构和展示的业务逻辑抽象成前端组件。
利用组件化的抽象方式，有助于提高代码复用率，从而提高开发效率。
协作模式的变革
以前的协作方式可能是前后不分离的，后端提供数据，前端提供模板，后端渲染成页面，view层就放在java应用项目里，导致前后端都有对vm操作的权限，职能界限模糊，业务逻辑和展现逻辑混淆。
基于组件化的协作模式，设计师提供ui，前端提供根据ui建模的组件，后端提供数据，这样大家的沟通维度都限定在了组件层面。这种更小粒度的沟通维度，集中化管理的方式，可以让协作成本更低。
组件的封装方式
规划
组件化核心意义是提取真正有复用价值的东西，例如
- 公共样式
- 控件
- 稳定的业务逻辑
组件分层：公共样式部分-->>通用组件-->>业务组件。
组件层架构就是
样式
组件应该是自我管理，自我约束，互不影响的，但是如果用css来管理样式，会有命名空间等问题。解决方法有：
- inline style
- 缺点：无法使用伪类选择器
- Radium可以解决伪类选择器的问题，但又衍生出不兼容ie8，不支持RN，不透明等问题。
整体架构
还有几个问题需要考虑：
- 组件需要的数据从哪里来
- 在组件内部写死
- 从http获取
- 缺点1：组件在同一个界面多次出现，就会存在请求浪费的问题，一个组件会产生一个请求。
- 缺点2：如果数据显示组件存在于数据配置界面，则会存在数据配置修改了，但组件数据没有更新的问题。
- 方法：引入一层store，每个组件不直接去服务端请求数据，而是到对应的前端数据缓存中取获取数据，让这个缓存自己去跟服务端保持同步。
- 组件间如何进行通讯
- 通过dispatch-store-view-action--dispatch这样的数据流动方式来通知不同页面变更。实际就是我们使用redux的那套数据流的模式。
- 前后端如何进行通讯
- 通过给redux的数据流增加异步的数据请求，就是dva的effectives
整个应用的架构就是这样的：
应用内组件的开发思路基本就是这样了，但是如果这个组件或者组件库需要给别的项目使用，就需要考虑再做一层封装：
- 统一调用方式
参考： 已买到的宝贝前端组件化探索