关于我在React设计模式上做的一些思考：
一，项目里实战的经历
最开始我根据组件不同的职能定义，拆分了展示组件和容器组件两大类，后来随着业务逻辑越来越复杂，容器组件代码越来越冗长，我又加入了HOC高阶组件的设计模式，将部分共享的通用功能逻辑抽出，来加强容器组件的可维护性和可扩展性；但是后来发现在多个HOC的一起使用时会经常出现props冲突的问题，而且数据来源比较混乱，于是我们又将这部分组件改用了render props，只取小部分定制化的state，来减小复杂度。
但其实无论是HOC还是render props，都是通过组件去解决组件的问题，将公共逻辑抽取到上层组件，然后利用props下传。不过也能理解，因为毕竟如果有生命周期逻辑复用这种的话，只能用组件。
不过后来有了hooks就不一样了，我们解决了HOC和render props的痛点，可以不再借助组件去抽离逻辑代码，真正的函数式思维，副作用更少，将状态管理和逻辑完全抽离React component，更好地实现复用，包括生命周期的逻辑复用。
二，总结：
HOC和render props都是为了共享代码逻辑以及部分生命周期而提出的设计模式，但是也各有利弊：
1，HOC的优点就是可扩展性更强，因为支持多参数传入，而缺点就是props要求必须统一，适合做一些复杂的功能型插件；
2，render props的优点就是只取需要的state，props自由命名，但是缺点就是可扩展性不强，而且很容易形成嵌套地域，因此适合做一些简单的UI层的组件；
3，Hooks可以用来优化render的前置处理，将相关的逻辑放在一起，而非散落在各个生命周期实例方法中
三，React Hooks原理
React Hooks的设计初衷就是为了解决复用逻辑状态等问题。
以useState为例：
1，通过闭包来实现状态的持久化；
2，状态的修改本质上还是借助setState；
3，利用一个 memoizedState 数组和 cursor 下标来解决多个状态存储问题：
(1) 初次渲染的时候，按照useState和useEffect的顺序，将state和deps等按顺序依次塞到 memoizedState 数组中去；
(2) 更新的时候，按照顺序从 memoizedState 中把上次记录的值取出；
memoizedState 和 cursor 是存在哪里的，它是怎么和每个函数组件一一对应的？
react会生成一棵组件树，树中每个节点都对应了一个组件，hooks的数据就作为组件的一个信息，存储在这些节点上。