前言
一个组件如何设计封装？什么时候用state？什么时候用props？逻辑要和视图分开？ 看完react哲学会有所启发～～～
所谓哲学
第一步：将设计好的UI划分为组件层级
- 根据设计稿（没有就原型吧）划分各个组件，确定好层级关系并命名；
- 划分原则：可以将组件当作一种函数或者是对象来考虑，根据单一功能原则来判定组件的范围，也就是一个组件原则上只负责一个功能；
- 如果它需要负责更多的功能，这时候就应该考虑将它拆分成更小的组件。
第二步：用React创建一个静态版本
- 最容易的方式，是先用已有的数据模型渲染一个不包含交互功能的UI；
- 最好将渲染 UI 和添加交互这两个过程分开。即逻辑处理跟视图分开处理，视图渲染单独封装成一个组件，通过props将数据传入。
- 这是因为，编写一个应用的静态版本时，往往要编写大量代码，而不需要考虑太多交互细节；添加交互功能时则要考虑大量细节，而不需要编写太多代码。
- 可以自上而下或者自下而上构建应用：自上而下意味着首先编写层级较高的组件，，自下而上意味着从最基本的组件开始编写。
- 当你的应用比较简单时，使用自上而下的方式更方便；对于较为大型的项目来说，自下而上地构建，并同时为低层组件编写测试是更加简单的方式。公司中项目实现组件封装（select支持点击出弹窗），选择了自下而上地构建，先实现简单的UI渲染，定义好传入的props，再实现逻辑处理（父组件），组合为一个单一功能组件（如弹窗）；最外层modalSelect组件支持modal传入······
第三步：确定UI state的最小（且完整）表示
- DRY原则：Don’t Repeat Yourself
- 只保留应用所需的可变 state 的最小集合，其他数据均由它们计算产生。
- 如何确定是否属于state，文档中举的例子不错～～
通过问自己以下三个问题，你可以逐个检查相应数据是否属于 state：
- 该数据是否是由父组件通过 props 传递而来的？如果是，那它应该不是 state。 如：搜索框的原始列表数据。
- 该数据是否随时间的推移而保持不变？如果是，那它应该也不是 state。如：输入搜索框的值。
- 你能否根据其他 state 或 props 计算出该数据的值？如果是，那它也不是 state。如：经过搜索筛选的列表。
注：这里会有点难理解为什么经过搜索筛选的列表不是state，因为它的结果可以由原始列表根据搜索词计算出来，这里确定的是UI中的state，可以理解为实现视图的子组件。
第四步：确定state放置的位置
-
需要确定哪个组件能够改变这些 state，或者说拥有这些 state。可以尝试通过以下步骤来判断： 对于应用中的每一个 state：
-
找到根据这个 state 进行渲染的所有组件。
-
找到他们的共同所有者（common owner）组件（在组件层级上高于所有需要该 state 的组件）。
-
该共同所有者组件或者比它层级更高的组件应该拥有该 state。
-
如果你找不到一个合适的位置来存放该 state，就可以直接创建一个新的组件来存放该 state，并将这一新组件置于高于共同所有者组件层级的位置。
第五步：添加反向数据流
- 处于较低层级的组件更新较高层级的组件中的 state。
- 通过props将函数（如：onChange）传入子组件，子组件通过props.onChange直接调用函数（或传入参数）更新相应的state。
结束
待续
