共计 2034 个字符，预计需要花费 6 分钟才能阅读完成。
react 的目的是将前端页面组件化，用状态机的思维模式去控制组件。组件和组件之间肯定是有关系得，通过合理得组件设计，给每一个组件划定合适得边界，可以有效降低当我们对页面进行重构时对其他组件之间得影响。同时也可以使我们得代码更加美观。
1、高耦合低内聚。
高耦合：将功能联系紧密得部分放到一个容器组件内对外暴漏出 index.js，目录结构如下:
├── components
│ └── App
└── index.js
低内聚：当这个组件在调用页面直接删除时，不会触发任何影响；减少无必要的重复渲染；减小重复渲染时影响得范围。
2、展示组件和容器组件
展示组件
容器组件
关注事物的展示
关注事物如何工作
可能包含展示和容器组件，并且一般会有 DOM 标签和 css 样式
可能包含展示和容器组件，并且不会有 DOM 标签和 css 样式
常常允许通过 this.props.children 传递
提供数据和行为给容器组件或者展示组件
对第三方没有任何依赖，比如 store 或者 flux action
调用 flux action 并且提供他们的回调给展示组件
不要指定数据如何加载和变化
作为数据源，通常采用较高阶的组件，而不是自己写，比如 React Redux 的 connect(), Relay 的 createContainer(), Flux Utils 的 Container.create()
很少有自己的状态，即使有，也是自己的 UI 状态
这里重点说下 this.props.children。通过 this.props.children 我们很容易让我们得组件变的低内聚。在实际开发中往往会遇到用纯组件写得展示组件下还有要继续跟跟数据打交道得容器组件。这里就用 this.props.children 套上这些容器组件就可以了。然后被套得容器组件可以继续按照上面得规则新建个文件夹暴漏出 index.js 这种写法。这种写法得最大好处是你很快就能找到你写得这个组件是在哪，是干嘛得，影响了哪。
3、从顶部向下得单向数据流
当我们得设计满足上面这些条件时，使用从顶部向下的单向数据流会让我们在使用一些类似于 redux 这种得状态管理工具时，影响的范围更加可控，再通过 shouldComponentUpdate 来减少不必要的渲染。（不过这么写确实挺麻烦的，但是 react 从 v16.3 开始使用新的生命周期函数 getDerivedStateFromProps 来强制开发者对这一步进行优化）
4、受控组件和非受控组件
有许多的 web 组件可以被用户的交互发生改变，比如：<input>，<select>。这些组件可以通过输入一些内容或者设置元素的 value 属性来改变组件的值。但是，因为 React 是单向数据流绑定的，这些组件可能会变得失控：1. 一个维护它自己 state 里的 value 值的 <Input> 组件无法从外部被修改 2. 一个通过 props 来设置 value 值的 <Input> 组件只能通过外部控制来更新。
受控组件：
一个受控的 <input> 应该有一个 value 属性。渲染一个受控的组件会展示出 value 属性的值。一个受控的组件不会维护它自己内部的状态，组件的渲染单纯的依赖于 props。也就是说，如果我们有一个通过 props 来设置 value 的 <input> 组件，不管你如何输入，它都只会显示 props.value。换句话说，你的组件是只读的。在处理一个受控组件的时候，应该始终传一个 value 属性进去，并且注册一个 onChange 的回调函数让组件变得可变。
非受控组件：
一个没有 value 属性的 <input> 就是一个非受控组件。通过渲染的元素，任意的用户输入都会被立即反映出来。非受控的 <input> 只能通过 OnChange 函数来向上层通知自己被用户输入的更改。#### 混合组件：同时维护 props.value 和 state.value 的值。props.value 在展示上拥有更高的优先级，state.value 代表着组件真正的值。
5、使用高阶组件（HOC）
简单定义：一个接收 react 组件作为参数返回另外一个组件的函数。可以做什么：代码复用，代码模块化增删改 props 使用案例：比方说公司突然要给前端代码不同的点击埋点，就可以使用 hoc 包一层，再不改动原来各处代码得同时进行了合理得改动。
6、增删改查标准流程
增: 填写数据，验证数据，插入数据，重新查询数据列表。删: 确认删除，重新查询数据列表。查: 查询数据列表，分页显示改: 填写数据，验证数据，修改数据，重新查询数据列表
其实设计组件时没必要过早的组件化。我们可以先快速的写出一个版本，然后再根据实际设计拆分以应对项目初期的需求快速变更。然后一点一点的按照设计模式去改变我们的项目，只要设计模式合理拆分其实是一个很流畅和自然的事情。
推荐文章：1、React 技术栈进阶之路之设计模式篇 2、React 组件设计 3、react 如何通过 shouldComponentUpdate 来减少重复渲染 4、reactJS 干货（reactjs 史上最详细的解析干货）
