关于前端:React的并发悖论

大家好，我卡颂。

当一个 React 应用逻辑变得复杂后，组件 render破费的工夫会显著增长。如果从 组件 render到 视图渲染 期间耗费的工夫过长，用户就会感知到页面卡顿。

为了解决这个问题，有两个办法：

1. 让 组件 render的过程从同步变为异步，这样 render 过程页面不会卡死。这就是并发更新的原理
2. 缩小须要 render 的组件数量，这就是常说的 React 性能优化

通常，对于不同类型组件，咱们会采取以上不同的办法。比方，对于上面这样的有耗时逻辑的输入框，办法 1 更适合（因为并发更新能缩小输出时的卡顿）：

function ExpensiveInput({onChange, value}) {
  // 耗时的操作
  const cur = performance.now();
  while (performance.now() - cur < 20) {}

  return <input onChange={onChange} value={value}/>;
}

那么，能不能在整个利用层面同时兼顾这 2 种形式呢？答案是 —— 不太行。

这是因为，对于简单利用，并发更新与性能优化通常是相悖的。就是本文要聊的 —— 并发悖论。

欢送退出人类高质量前端交换群，带飞

从性能优化聊起

对于一个组件，如果心愿他非必要时不 render，须要达到的根本条件是：props 的援用不变。

比方，上面代码中 Child 组件依赖 fn props，因为fn 是内联模式，所以每次 App 组件 render 时援用都会变，不利于 Child 性能优化：

function App() {return <Child fn={() => {/* xxx */}}/>
}

为了 Child 性能优化，能够将 fn 抽离进去：

const fn = () => {/* xxx */}

function App() {return <Child fn={fn}/>
}

当 fn 依赖某些 props 或者 state 时，咱们须要应用useCallback：

function App({a}) {const fn = useCallback(() => a + 1, [a]);
  return <Child fn={fn}/>
}

相似的，其余类型变量须要用到useMemo。

也就是说，当波及到性能优化时，React的代码逻辑会变得复杂（须要思考援用变动问题）。

当利用进一步简单，会面临更多问题，比方：

• 简单的 useEffect 逻辑
• 状态如何共享

这些问题会与性能优化问题相互叠加，最终导致利用不仅逻辑简单，性能也欠佳。

性能优化的解决之道

好在，这些问题有个独特的解决办法 —— 状态治理。

上文咱们聊到，对于性能优化，要害的问题是 —— 放弃 props 援用不变。

在原生 React 中，如果 a 依赖 b，b 依赖 c。那么，当a 变动后，咱们须要通过各种办法（比方 useCallback、useMemo）放弃b、c 援用的稳固。

做这件事件自身（放弃援用不变）对开发者来说就是额定的心智累赘。那么，状态治理是如何解决这个问题的呢？

答案是：状态治理库本人治理所有原始状态以及派生状态。

比方：

• 在 Recoil 中，根底状态类型被称为 Atom，其余派生状态都是基于Atom 组合而来
• 在 Zustand 中，根底状态都是 create 办法创立的实例
• 在 Redux 中，保护了一个全局状态，对于须要用到的状态通过 selector 从中摘出来

这些状态治理计划都会本人保护所有的根底状态与派生状态。当开发者从状态治理库中引入状态时，就能最大限度放弃 props 援用不变。

比方，下例用 Zustand 革新下面的代码。因为状态 a 和依赖 a 的fn都是由 Zustand 治理，所以 fn 的援用始终不变：

const useStore = create(set => ({
  a: 0,
  fn: () => set(state => ({ a: state.a + 1})),
}))


function App() {const fn = useStore(state => state.fn)
  return <Child fn={fn}/>
}

并发更新的问题

当初咱们晓得，性能优化的通用解决路径是 —— 通过状态治理库，保护一套逻辑自洽的内部状态（这里的 内部 是区别于 React 本身的状态），放弃援用不变。

然而，这套内部状态最终肯定会转化为 React 的外部状态（再通过外部状态的变动驱动视图更新），所以就存在状态同步机会的问题。即：什么时候将内部状态与外部状态同步？

在并发更新之前的 React 中，这并不是个问题。因为更新是同步、不会被打断的。所以对于同一个内部状态，在整个更新过程中都能放弃不变。

比方，在如下代码中，因为 List 组件的 render 过程不会打断，所以 list 在遍历过程中是稳固的：

function List() {const list = useStore(state => state.list)
  return (
    <ul>
      {list.map(item => <Item key={item.id} data={item}/>}
    </ul>
  )
}

然而，对于开启并发更新的 React，更新流程可能中断，不同的Item 组件可能是在中断前后不同的宏工作中 render，传递给他们的data props 可能并不相同。这就导致同一次更新，同一个状态（例子中的list）前后不统一的状况。

这种状况被称为tearing（视图撕裂）。

能够发现，造成 tearing 的起因是 —— 内部状态（状态治理库保护的状态）与 React 外部状态的同步机会出问题。

这个问题在以后 React 中是很难解决的。退而求其次，为了让这些状态库可能失常应用，React专门出了个hook —— useSyncExternalStore。用于将状态治理库触发的更新都以同步的形式执行，这样就不会有同步机会的问题。

既然是以同步的形式执行，那必定没法并发更新啦～～～

总结

实际上，但凡波及到 本人保护了一个内部状态 的库（比方动画库），都波及到状态同步的问题，很有可能无奈兼容并发更新。

所以，你会更偏向上面哪种抉择呢：

1. 不 care 并发更新，以前 React 怎么用，当初就怎么用
2. 依据我的项目状况，均衡并发更新与性能优化的诉求