基于键的优化 (kbo) 和 shouldComponentUpdate (scu) 是如何相互关联的？
他们似乎在做同样的事情（避免重新渲染和区分）。
它们有何不同？我错过了什么吗？
我的感觉是 scu 被“包含”在基于键的优化中，即。如果一个节点与之前的渲染具有相同的键——在树的同一路径上——那么它不会被重新渲染，这也可以用 kbo 来实现，但我不确定。
如果一个节点的路径与之前渲染的任何路径都不匹配并且 scu 返回 false 会发生什么情况，那么该节点是否会被重新渲染？我的猜测是肯定的，但不确定。
【问题讨论】：
标签： reactjs
它们绝对不一样。
shouldComponentUpdate 控制render 是否应该运行，即是否需要 DOM diff 和 update。此检查通常在 props、state 或 context 更改时进行。
键是非常不同的。通过使用相同的key，您可以确保使用相同的组件实例。考虑以下几点：
<MyComponent title="Title 1" />
<MyComponent title="Title 2" />
如果由于某种原因，您的 render 删除了第一个组件并且您最终得到：
<MyComponent title="Title 2" />
然后发生的情况是第二个组件从 DOM 中移除，第一个组件获得不同的属性，导致重新渲染和 DOM 更新。
如果你正确使用按键：
<MyComponent key="key1" title="Title 1" />
<MyComponent key="key2" title="Title 2" />
删除第一个组件后，第二个组件将收到相同的道具（将根据其 shouldComponentUpdate 重新渲染），但很可能唯一的 DOM 更新是删除第一个组件。
感谢key，React 可以进行最少的 DOM 更新。
这有一些严重的影响，例如在使用非托管组件时：
const MyComponent = () => {
return <input defaultValue="some-text" />;
};
再次，当我们有
<MyComponent title="Title 1" />
<MyComponent title="Title 2" />
然后您将一些文本写入第一个组件的input，然后删除该组件，那么即使它是包含它的第二个组件，文本仍将保留在<input> 中。钥匙可以防止这种情况发生。
另请注意，将key 设置为之前未渲染的内容时，例如：
<MyComponent key="key3" />
创建MyComponent 的新实例，调用componentDidMount。
这可用于完全重置组件的状态（例如，用于非托管输入）。
大多数情况下，您只需要在列表中使用key，以便在排序、删除等时提供性能提升。它对非托管输入有一些次要用途，但仅此而已。
与shouldComponentUpdate 相比，基于键的优化有助于将当前渲染状态与前一个匹配，从而防止道具被更改。
【讨论】：