React学习笔记0：在你写memo之前

原文链接

https://overreacted.io/zh-hans/before-you-memo/

案例

《在你写 memo() 之前》是讲如何在避免使用 useMemo 或者 Memo 的情况下进行前端页面渲染的性能优化

文章中给出了一个例子：

import { useState } from 'react';

export default function App() {
  let [color, setColor] = useState('red');
  return (
    <div>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
      <ExpensiveTree />
    </div>
  );
}

function ExpensiveTree() {
  let now = performance.now();
  while (performance.now() - now < 100) {
    // Artificial delay -- do nothing for 100ms
  }
  return <p>I am a very slow component tree.</p>;
}

其中 ExpensiveTree 是一个渲染非常慢的组件（人为控制）。

因为React的渲染触发机制是：

1. state发生改变
2. props发生改变

所以 App 渲染的触发机制如图：

一旦color频繁变化，会导致 input 、 p 和 ExpensiveTree 的频繁重新渲染，而 ExpensiveTree 重新渲染的速度非常慢，频繁重新渲染会导致页面卡死。

而文中给出了在这种情况下避免使用 useMemo 或者 Memo 的情况下两种前端性能优化解决方案。

方案1 下沉State

export default function App() {
  return (
    <>
      <Form />
      <ExpensiveTree />
    </>
  );
}

function Form() {
  let [color, setColor] = useState('red');
  return (
    <>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
    </>
  );
}

此时 App 渲染的触发机制如图：

此时 color 频繁变化，仅会导致 input 、 p 重新渲染，而渲染速度极慢的 ExpensiveTree 则由于没有 state 或 props 变化保持不变。 state 下沉将与 color 相关的会变化的部分独立出来，与不变的部分进行分割，优化了组件渲染的速度。

方案2 内容提升

export default function App() {
  return (
    <ColorPicker>
      <ExpensiveTree />
    </ColorPicker>
  );
}

function ColorPicker({ children }) {
  let [color, setColor] = useState("red");
  return (
    <div style={{ color }}>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
      {children}
    </div>
  );
}

此时 App 渲染的触发机制如图：

App 通过 children 属性将不变的 ExpensiveTree 插入 ColorPicker 内，虽然 ExpensiveTree 是 ColorPicker 的子结点，但实际上控制 ExpensiveTree 渲染的是根节点 App 组件，受 color 控制的 input 、 p 节点与 ExpensiveTree 进行了分割， color 的变化不会影响到 ExpensiveTree 的渲染。

你用memo或者useMemo做优化时，如果你可以从不变的部分里分割出变化的部分，那么这看起来可能是有意义的。 关于这些方式有趣的部分是他们本身并不真的和性能有关. 使用children属性来拆分组件通常会使应用程序的数据流更容易追踪，并且可以减少贯穿树的props数量。在这种情况下提高性能是锦上添花，而不是最终目标。 奇怪的是，这种模式在将来还会带来更多的性能好处。 举个例子，当服务器组件稳定且可被采用时，我们的ColorPicker组件就可以从服务器上获取到它的children。 整个组件或其部分都可以在服务器上运行，即使是顶级的React状态更新也会在客户机上“跳过”这些部分。 这是memo做不到的事情!但是，这两种方法是互补的。不要忽视state下沉(和内容提升!) 然后，如果这还不够，那就使用Profiler然后用memo来写吧。