关于前端:译-如何使用-useRef-修复-React-性能问题

原文地址：How to useRef to Fix React Performance Issues

原文作者：Sidney Alcantara

译文出自：掘金翻译打算

本文永恒链接：https://github.com/xitu/gold-miner/blob/master/article/2020/how-to-useref-to-fix-react-performance-issues.md

译者：NieZhuZhu「弹铁蛋同学」

校对者：regon-cao、zenblo

Refs 是 React 中很少会应用到的个性。如果你曾经读过了官网的 React Ref Guide，你会从中理解到 Refs 被形容为重要的 React 数据流的“逃生舱门”，需谨慎应用。Refs 被视为拜访组件的根底 DOM 元素的正确办法。

随同着 React Hooks 的到来，React 团队引入了 useRef Hook，它扩大了这个性能：

“useRef() 比 ref 属性更有用。它通过相似在 class 中应用实例字段的形式，十分不便地保留任何可变值。”—— React 文档

新的 React Hooks API 公布的时候，我确实疏忽了这一点，事实证明 useRef 真的十分有用。

我是一名 Firetable 的软件开发工程师。Firetable 是一个开源的 React 电子表格利用，联合了 Firestore 和 Firebase 的次要性能。其中有一个次要性能是侧面抽屉，它是一种相似于窗体的 UI，用于编辑在主表上滑动的那一行。

当用户单击选中表格中的某一个单元格时，能够通过关上侧抽屉的形式编辑该单元格所对应的行数据。换句话说，咱们在侧边抽屉中渲染的内容取决于以后抉择的行 —— 咱们须要将这行的数据状态记录下来。

将这行数据的状态的放在侧抽屉组件外部是最合乎逻辑的，因为当用户抉择其余单元格时，它应该仅影响侧边的抽屉组件。然而：

咱们须要在表格组件里设置这个数据状态。咱们用的是 react-data-grid 渲染表格，并且它接管一个当用户点击一个单元格时会触发的回调。就目前来看，这是咱们能从表格中获取选中行数据的惟一路径。
然而侧边抽屉组件和表格组件是同级（兄弟）组件，所以不能间接拜访彼此的数据状态。

React 的举荐做法是晋升状态到俩组件最近的父级节点 (以这个为例，父级节点为 TablePage)。然而咱们决定不将状态迁徙到这个组件，理由是：

TablePage 不保留状态，次要是搁置 table 和 side drawer 组件的容器, 两者都不接管任何的 props。咱们偏向于放弃这种做法。
咱们曾经在组件树的顶层应用 React Context 来共享了许多的全局数据，并且咱们感觉应该将这个状态回升到全局 store。

留神：即便咱们将数据状态放在了 TablePage，无论如何咱们都将面临上面这个雷同的问题。

问题就是每当用户抉择一个单元格或关上侧面抽屉时，全局 context 的更新会使得整个利用产生从新渲染。table 组件能够一次显示数十个单元格，并且每个单元格都有本人的编辑器组件。这会导致大概 650ms 的渲染工夫，这个工夫太长以至于在关上侧边抽屉的时候会感触到显著的提早。

罪魁祸首是 context —— 这就是为什么要在 React 中应用而不是在全局 JavaScript 对象中应用：

”只有提供给 Provider 的值发生变化，所有生产到了 Provider 的后辈组件都会产生重渲染。“— React Context

到目前为止，尽管咱们曾经足够理解 React 的状态和生命周期，但当初看来咱们仍旧陷入了窘境。

在决定应用 useRef 之前，咱们尝试了几种不同的解决方案。(Dan Abramov 的文章) :

拆分 context (也就是创立新的 SideDrawerContext) —— table 组件依然会生产到新的 context，在关上侧边抽屉的时候依旧会导致 table 组件的不必要的从新渲染。
将 table 组件放在 React.memo 或 useMemo 中 —— table 组件仍旧是须要通过 useContext 拿到侧边抽屉组件的状态，两种 API 均无奈阻止其从新渲染。
将用于渲染表格的 react-data-grid 组件进行 memo —— 这将使咱们的代码更加的简短。咱们还发现它阻止了“必要”的从新渲染，要求咱们破费更多的工夫齐全修复或者重构咱们的代码来实现侧边抽屉。

当再次浏览 Hook APIs 和 useMemo 文档的时候，我终于遇到了 useRef 相干内容。

“useRef() 比 ref 属性更有用。它通过像在 class 中应用实例字段的形式，十分不便地保留任何可变值。”—— React 文档

更重要的是：

“当 ref 对象内容发生变化时，useRef 并不会告诉变更。变更 .current 属性不会引发组件从新渲染。”—— React 文档

此时：咱们不须要存储侧抽屉的状态。咱们只须要援用设置该状态的函数即可。

将关上状态和单元状态保留在侧面抽屉组件中。
创立这些状态的 ref，并将其存储在 context 中。
当用户单击单元格时，应用之前说的表中的回调去调用 ref 设置数据状态的函数（在侧抽屉内）。

以下代码是在 Firetable 应用的代码缩写版，其中包含了 ref 和 TypeScript 的类型：

import {SideDrawerRef} from 'SideDrawer'

export function FiretableContextProvider({children}) {const sideDrawerRef = useRef<SideDrawerRef>();

  return (<FiretableContext.Provider value={{ sideDrawerRef}}>
      {children}
    </FiretableContext.Provider>
  )
}

留神：因为函数组件在从新渲染时会运行整个函数体，所以每当“单元”或“关上”状态更新（并导致从新渲染）时，“sideDrawerRef”总是能在“.current”中获取到最新值。

事实证明，此解决方案是最佳的：

以后的单元格和关上的状态存储在侧面抽屉组件中 —— 这是搁置它的最合逻辑的中央。
当须要时，表格组件也能够拜访其兄弟组件的状态。
以后单元格或关上状态更新时，它只会触发侧抽屉组件的从新渲染，而不触发整个应用程序中的其余组件从新渲染。

你能够在 Firetable 源码中看它是如何被应用的 GitHub.

不过，这并不意味着您能够在利用中随便应用。当您须要在特定工夫拜访或更新另一个组件的状态，然而您的其余组件不依赖于该状态或基于该状态进行出现时，这是最好的方法。React 的晋升状态和单向数据流的外围概念足以笼罩大多数应用程序架构。

???? 明天的文章分享就到这里啦，如果喜爱这篇文章的话请点赞、Star、关注我吧 ????

如果发现译文存在谬误或其余须要改良的中央，欢送到掘金翻译打算对译文进行批改并 PR，也可取得相应处分积分。文章结尾的 本文永恒链接 即为本文在 GitHub 上的 MarkDown 链接。

掘金翻译打算是一个翻译优质互联网技术文章的社区，文章起源为掘金上的英文分享文章。内容笼罩 Android、iOS、前端、后端、区块链、产品、设计、人工智能等畛域，想要查看更多优质译文请继续关注掘金翻译打算、官网微博、知乎专栏。

关于前端:译-如何使用-useRef-修复-React-性能问题

如何应用 useRef 修复 React 性能问题

面临的问题

顿悟时刻!

解决方案

什么时候应用 useRef