React v16.8 之后，Function Component 成为主流，React 状态管理的方案也发生巨大的转变。Redux 一直作为主流的 React 状态管理方案，虽然提供了一套规范的状态管理流程，但却有着让人饱受诟病的问题：概念太多、上手成本高、重复的样板代码、需要结合中间件使用等。
一个真正易用的状态管理工具往往不需要过多复杂的概念。Hooks 诞生之后，代码优雅简洁变成一种趋势。开发者也倾向于用一种小而美、学习成本低的方案来实现状态管理。因此，除了 React local state hooks 之外，社区还孵化了很多状态管理库，如 unstated-next、hox、zustand、jotai 等。
关于状态管理，有个非常经典的场景：实现一个计数器，点击 + 号的时候将数字加一，点击 - 号的时候将数值减一。这几乎是所有状态管理库标配的入门案例。
本文将从实现「计数器」这个经典场景出发，逐步分析 Hooks 时代下，React 状态管理方案的演进过程和背后的实现原理。
React local state hooks
React 提供了一些管理状态的原生 hooks API，简洁易懂，非常好上手。用原生的 hooks 方法就可以很轻松地实现计数器功能，只要通过 useState 方法在根组件定义计数器的状态和改变状态的方法，并层层传递给子组件就可以了。
// timer.js
const Timer = (props) => {
const { increment, count, decrement } = props;
return (
<>
<button onClick={decrement}>-</button>
<span>{count}</span>
<button onClick={increment}>+</button>
</>
);
};
// app.js
const App = () => {
const [count, setCount] = React.useState(0);
const increment = () => setCount(count + 1);
const decrement = () => setCount(count - 1);
return <Timer count={count} increment={increment} decrement={decrement} />
}
但是这种方法存在很严重的缺陷。
首先，计数器的业务逻辑和组件耦合严重，需要将逻辑进行抽象分离，保持逻辑与组件的纯粹性。
其次，多组件内共享状态是通过层层传递的方式实现的，带来冗余代码的同时，根组件的状态将会逐渐变成 “庞然大物”。
unstated-next
React 开发者在设计之初，也考虑到上面提到的两个问题，本身也提供了对应的解决方案。
React Hooks 就是打着「逻辑复用」的口号而诞生的，自定义 hook 可以解决以前在 Class Component 组件内无法灵活共享逻辑的问题。
因此，针对业务逻辑耦合的问题，可以提取一个自定义计数器 hook useCount 。
function useCount() {
const [count, setCount] = React.useState(0);
const increment = () => setCount(count + 1);
const decrement = () => setCount(count - 1);
return { count, increment, decrement };
}
为了避免组件间层层传递状态，可以使用 Context 解决方案。Context 提供了在组件之间共享状态的方法，而不必在树的每个层级显式传递一个 prop 。
因此，只需要将状态存储在 StoreContext 中，Provider 下的任意子组件都可以通过useContext获取到上下文中的状态。
// timer.js
import StoreContext from './StoreContext';
const Timer = () => {
const store = React.useContext(StoreContext);
// 组件内 render 部分先省略
}
// app.js
const App = () => {
const StoreContext = React.createContext();
const store = useCount();
return <StoreContext.Provider value={store}><Timer /></StoreContext.Provider>
}
这样代码看起来清爽了一些。
但是在使用的时候还是免不了要先定义很多 Context，并且在子组件中进行引用，略微有点繁琐。
因此，可以对代码进行进一步的封装，将 Context 定义和引用的步骤抽象成公共的方法 createContainer。
function createContainer(useHook) {
// 定义 context
const StoreContext = React.createContext();
function useContainer() {
// 子组件引用 context
const store = React.useContext(StoreContext);
return store;
}
function Provider(props) {
const store = useHook();
return <StoreContext.Provider value={store}>{props.children}</StoreContext.Provider>
}
return { Provider, useContainer }
}
createContainer 封装后会返回两个对象 Provider 和 useContainer。 Provider 组件可以传递状态给子组件，子组件可以通过 useContainer 方法获取全局的状态。经过改造，组件内的代码就会变得非常精简。
const Store = createContainer(useCount);
// timer.js
const Timer = () => {
const store = Store.useContainer();
// 组件内 render 部分先省略
}
// app.js
const App = () => {
return <Store.Provider><Timer /></Store.Provider>
}
这样，一个基本的状态管理方案成型了！体积小，API 简单，可以说是 React 状态管理库的最小集。源码可以见这里。
这种方案也是状态管理库 unstated-next 的实现原理。
hox
先不要高兴得太早。unstated-next 的方案虽好，但也有缺陷的，这也是 React context 广为人诟病的两个问题：
- Context 需要嵌套 Provider 组件，一旦代码中使用多个 context，将会造成嵌套地狱，组件的可读性和纯粹性会直线降低，从而导致组件重用更加困难。
- Context 可能会造成不必要的渲染。一旦 context 里的 value 发生改变，任何引用 context 的子组件都会被更新。
那有没有什么方法可以解决上面两个问题呢？答案是肯定的，目前已经有一些自定义状态管理库解决这两个问题了。
从 context 的解决方案里，其实可以得到一些启发。状态管理的流程可以简化成三个模型： Store（存储所有状态）、Hook （抽象公共逻辑，更改状态）、Component（使用状态的组件）。
如果要自定义状态管理库，在脑海中可以先构思下， 这三者之前的关系应该是怎么样的？
- 订阅更新： 初始化执行 Hook 的时候，需要收集哪些 Component 使用了 Store
- 感知变更： Hook 中的行为能够改变 Store 的状态，也要能被 Store 所感知到
- 发布更新： Store 一旦变更，需要驱动所有订阅更新的 Component 更新
只要完成这三步，状态管理基本上就完成了。大致思路有了，下面就可以具体实现了。
状态初始化
首先需要初始化 Store 的状态，也就是 Hook 方法执行返回的结果。同时定义一个 API 方法，供子组件获取 Store 的状态。这样状态管理库的模型就搭出来了。
从业务代码使用方法上可以看出，API 简洁的同时，也避免了 Provider 组件嵌套。
// 状态管理库的框架
function createContainer(hook) {
const store = hook();
// 提供给子组件的 API 方法
function useContainer() {
const storeRef = useRef(store);
return storeRef.current;
}
return useContainer;
}
// 业务代码使用：API简洁
const useContainer = createContainer(useCount);
const Timer = () => {
const store = useContainer();
// 组件内 render 部分先省略
}
订阅更新
为了实现 Store 状态更新的时候，能够驱动组件更新。需要定义一个 listeners 集合，在组件初始化的时候往数组添加 listener 回调，订阅状态的更新。
function createContainer(hook){
const store = hook();
const listeners = new Set(); // 定义回调集合
function useContainer() {
const storeRef = useRef(store);
useEffect(() => {
listeners.add(listener); // 初始化的时候添加回调，订阅更新
return () => listeners.delete(listener) // 组件销毁的时候移除回调
},[])
return storeRef.current;
}
return useContainer;
}
那么当状态更新后，如何驱动组件更新呢？ 这里可以利用 useReducer hook 定义一个自增函数，使用 forceUpdate 方法即可让组件重刷。
const [, forceUpdate] = useReducer((c) => c + 1, 0);
function listener(newStore) {
forceUpdate();
storeRef.current = newStore;
}
感知状态变更
状态变更驱动组件更新的部分已经完成。现在比较重要的问题是，如何感知到状态发生变更了呢？
状态变更是在 useCount Hook 函数内实现的，用的是 React 原生的 setState 方法，也只能在 React 组件内执行。因此，很容易想到，如果使用一个函数组件 Executor 引用这个 Hook，那么在这个组件内就可以初始化状态，并感知状态变更了。
考虑到状态管理库的通用性，可以通过 react-reconciler 构造一个 react 渲染器来挂载 Executor 组件，这样就可以分别支持 React、ReactNative 等不同框架。
// 构造 react 渲染器
function render(reactElement: ReactElement) {
const container = reconciler.createContainer(null, 0, false, null);
return reconciler.updateContainer(reactElement, container);
}
// react 组件，感知 hook 内状态的变更
const Executor = (props) => {
const store = props.hook();
const mountRef = useRef(false);
// 状态初始化
if (!mountRef.current) {
props.onMount(store);
mountRef.current = true;
}
// store 一旦变更，就会执行 useEffect 回调
useEffect(() => {
props.onUpdate(store); // 一旦状态变更，通知依赖的组件更新
});
return null;
};
function createContainer(hook) {
let store;
const onUpdate = () => {};
// 传递hook和更新的回调函数
render(<Executor hook={hook} onMount={val => store = val} onUpdate={onUpdate} />);
function useContainer() {}
return useContainer;
}
精确更新
一旦感知到状态变更后，在 onUpdate 回调里可以通知之前订阅过更新的组件重新渲染，也就是遍历 listeners 集合，执行之前添加的更新回调。
const onUpdate = (store) => {
for (const listener of listeners) {
listener(store);
}
}
但是，组件往往可能只依赖了 Store 里的某一个状态，所有组件都更新的操作太粗暴，会带来不必要的更新，需要进行精确的更新渲染。因此，可以在组件的更新回调里判断当前依赖的状态是否变化，从而决定是否触发更新。
// useContainer API 扩展增加依赖属性
const store = useContainer('count'); // 组件仅依赖store.count值
// 更新回调里判断
function listener(newStore) {
const newValue = newStore[dep];
const oldValue = storeRef.current[dep];
// 仅仅在依赖发生变更，才会组件进行更新
if (compare(newValue, oldValue)) {
forceUpdate();
}
storeRef.current = newStore;
}
完成以上的步骤，一个简单又好用的状态管理库就实现啦！源码可以看这里。
状态更新的流程如下图所示。
API 简洁，逻辑和 UI 分离，能跨组件传输状态，没有冗余的嵌套组件，并且能实现精确更新。
这也是状态管理库 hox 背后的实现原理。
zustand
关于如何感知状态变更这一节中，因为 useCount 函数中是通过操作 react 原生 hook 方法实现状态变更的，所以我们需要用 Executor 作为中间桥梁来感知状态变更。
但是，这其实是一种委屈求全的方案，不得已将方案复杂化了。试想下，如果变更状态的方法 setState 是由状态管理库自身提供的，那么一旦执行该方法，就可以感知状态变更，并触发后续的比较更新操作，整体流程会简单很多！
// 将改变状态的 setState 方法传递给 hook
// hook内一旦执行该方法，即可感知状态变更，拿到最新的状态
function useCount(setState) {
const increment = () => setState((state) => ({ ...state, count: state.count + 1 }));
const decrement = () => setState((state) => ({ ...state, count: state.count - 1 }));
return { count: 0, increment, decrement };
}
function createContainer(hook) {
let store;
const setState = (partial) => {
const nexStore = partial(store);
// hook中一旦执行 setState 的操作，且状态变更后，将触发 onUpdate 更新
if(nexStore !== store){
store = Object.assign({}, store, nexStore);
onUpdate(store);
}
};
// 将改变状态的方法 setState 传递给hook函数
store = hook(setState);
}
const useContainer = createContainer(useCount);
这种方案更加高明，让状态管理库的实现更加简洁明了，库的体积也会小不少。源码可见这里。
这种方案是 zustand 背后的大致原理。虽然需要开发者先熟悉下对应的写法，但是 API 与 Hooks 类似，学习成本很低，上手容易。
总结
本文从实现一个计数器场景出发，阐述了多种状态管理的方案和具体实现。不同状态管理方案产生都有着各自的背景，也有着各自的优劣。
但是自定义状态管理库的设计思想都是差不多的。目前开源社区比较活跃的状态管理库大多是如此，不同点主要是在如何感知状态变更这块做些文章。
看完本文，想必你已经知道如何进行 React Hooks 下的状态管理了，那就赶紧行动吧！
