写出易维护的代码｜React开发的设计模式及原则

介绍

设计模式是最常见的，通用问题的可复用解决方案的归纳总结，通常被认为是解决该类问题的最佳实践，使用设计模式能帮助我们写出更容易维护，更健壮的代码。设计模式有很多，通常它们都会遵循一些共同的设计原则，接下来我们一起回顾下React社区里出现过的一些设计模式，以及它们所遵循的设计原则。

一些设计原则

1.单一职责原则(Single-responsibility responsibility) : 每个实体(class, function, module)只应该有一个职责。例如当一个组件接收了太多的props，我们应该考虑组件是不是做了太多的事情，有没有必要进行拆分。

2.开闭原则(Open-closed principle)：实体(class, function, module) 应该对扩展开放，但是对修改关闭。开闭原则意味着应该存在不直接修改的方式扩展实体的功能。

3.依赖反转原则（Dependency inversion principle）：依赖于抽象，而不是具体的实现。依赖注入是一种实现依赖反转的方式。

4.不要自我重复 （Don't repeat yourself）：重复代码会造成代码维护的困难。

5.Composition over inheritance[1]: 通过组合集成的两个组件是松耦合关系，通过props来约束。但是有继承关系的两个组件是强耦合关系，对父组件的修改可能会导致子组件的未预期的结果。

React设计模式

Container & presentational component[2]

把业务组件划分成container组件和presentational组件。Presentational component中负责组件的ui渲染，Container component负责数据的获取和事件的响应。

遵循的设计原则：

1.单一职责原则：Presentational component负责ui，Container component负责数据和行为。

2.Don't repeat yourself: Presentational component是纯ui组件，不包含业务逻辑，通常可以被复用。

示例：

HOC

Higher-order component 是一个以组件为参数，返回一个新组件的函数，用于复用组件的逻辑，Redux的 connect[3] 和 Relay的createFragmentContainer[4]都有使用HOC模式。

遵循的设计原则：

1.Don't repeat yourself：把可复用的逻辑放到HOC中，实现代码复用。

2.Composition over inheritance: hoc中传入的组件和返回的组件是组合的关系, 也可以把多个HOC进行多次的嵌套组合。

示例：

Render prop

Render prop是指组件的使用者通过组件暴露的函数属性来参与定制渲染相关的逻辑。使用Render prop模式的库包括： React Router[5], Downshift[6] and Formik[7].

遵循的设计原则：

1.Don't repeat yourself：把可复用的逻辑放到组件中，实现代码复用。

2.依赖反转原则：通过render prop注入渲染相关的实现。

3.开闭原则(Open-closed principle)：通过render prop暴露扩展点，而不是直接定制组件。

示例：

Compound components

Compound components是指通过多个组件的组合来完成特定任务，这些组件通过共享的状态、逻辑进行关联。典型的例子是Select和Select.Option组件。使用Compound components模式的库包括：semantic ui[8];

遵循的设计原则：

1.单一职责原则(Single-responsibility responsibility): 拆分成多个组件，每个组件承担自己的职责。

2.开闭原则(Open-closed principle)：需要迭代增强功能时，可以通过创建新的子组件的方式进行扩展。

示例：

Custom hooks

自定义hooks可以做到把与state和生命周期关联的可复用逻辑封装到独立的函数中, 上面的提及的一些模式都是基于组件的方案，自定义hooks是更细粒度的解决方案。

遵循的设计原则：

1.Don't repeat yourself：把可复用的逻辑放到自定义hooks中，实现代码复用。

2.单一职责原则：每个自定义hooks是都是一个独立的逻辑单元。

示例：

结尾

上面提及的曾经在社区流行的设计模式，往往遵守了一些设计原则，从而能帮助开发者写出健壮，易维护的代码。但是我们需要能根据实际的场景做出判断，是否需要引入这些模式，毕竟还有一个设计原则是YAGNI (You aren't gonna need it)。

参考链接：

[1]https://reactjs.org/docs/composition-vs-inheritance.html

[2]https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

[3]https://github.com/reduxjs/react-redux/blob/master/docs/api/connect.md#connect

[4]https://relay.dev/docs/v10.1.3/fragment-container/#createfragmentcontainer

[5]https://reactjs.org/docs/composition-vs-inheritance.html

[6]https://reacttraining.com/react-router/web/api/Route/render-func

[7]https://github.com/paypal/downshift

[8]https://github.com/jaredpalmer/formik

[9]https://react.semantic-ui.com/