React组件设计规则
react的目的是将前端页面组件化，用状态机的思维模式去控制组件。组件和组件之间肯定是有关系得，通过合理得组件设计，给每一个组件划定合适得边界，可以有效降低当我们对页面进行重构时对其他组件之间得影响。同时也可以使我们得代码更加美观。
1、高耦合低内聚。
高耦合：将功能联系紧密得部分放到一个容器组件内对外暴漏出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组件可以被用户的交互发生改变，比如：，。这些组件可以通过输入一些内容或者设置元素的value属性来改变组件的值。但是，因为React是单向数据流绑定的，这些组件可能会变得失控： 1.一个维护它自己state里的value值的组件无法从外部被修改 2.一个通过props来设置value值的组件只能通过外部控制来更新。
受控组件：
一个受控的应该有一个value属性。渲染一个受控的组件会展示出value属性的值。 一个受控的组件不会维护它自己内部的状态，组件的渲染单纯的依赖于props。也就是说，如果我们有一个通过props来设置value的组件，不管你如何输入，它都只会显示props.value。换句话说，你的组件是只读的。 在处理一个受控组件的时候，应该始终传一个value属性进去，并且注册一个onChange的回调函数让组件变得可变。
非受控组件：
一个没有value属性的就是一个非受控组件。通过渲染的元素，任意的用户输入都会被立即反映出来。非受控的只能通过OnChange函数来向上层通知自己被用户输入的更改。
混合组件：
同时维护props.value和state.value的值。props.value在展示上拥有更高的优先级，state.value代表着组件真正的值。
5、使用高阶组件（HOC）
简单定义：一个接收react组件作为参数返回另外一个组件的函数。 可以做什么：代码复用，代码模块化增删改props 使用案例：比方说公司突然要给前端代码不同的点击埋点，就可以使用hoc包一层，再不改动原来各处代码得同时进行了合理得改动。
6、增删改查标准流程
增:填写数据，验证数据，插入数据，重新查询数据列表。 删:确认删除，重新查询数据列表。 查:查询数据列表，分页显示 改:填写数据，验证数据，修改数据，重新查询数据列表
其实设计组件时没必要过早的组件化。我们可以先快速的写出一个版本，然后再根据实际设计拆分以应对项目初期的需求快速变更。然后一点一点的按照设计模式去改变我们的项目，只要设计模式合理拆分其实是一个很流畅和自然的事情。
Last updated
Was this helpful?