原文：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

如何使用 useRef 修復 React 性能問題

Refs 是 React 中很少會使用到的特性。如果你已經讀過了官方的 React Ref Guide，你會從中了解到 Refs 被描述為重要的 React 數(shù)據流的 “逃生艙門”，需謹慎使用。Refs 被視為訪問組件的基礎 DOM 元素的正確方法。

伴隨著 React Hooks 的到來，React 團隊引入了?[useRef](https://reactjs.org/docs/hooks-reference.html#useref)?Hook，它擴展了這個功能：

“useRef()?比 ref 屬性更有用。它通過類似在 class 中使用實例字段的方式，非常方便地?保存任何可變值。” —— React 文檔

新的 React Hooks API 發(fā)布的時候，我的確忽略了這一點，事實證明 useRef 真的非常有用。

面臨的問題

我是一名 Firetable 的軟件開發(fā)工程師。Firetable 是一個開源的 React 電子表格應用，結合了 Firestore 和 Firebase 的主要功能。其中有一個主要功能是側面抽屜，它是一種類似于窗體的 UI，用于編輯在主表上滑動的那一行。

當用戶單擊選中表格中的某一個單元格時，可以通過打開側抽屜的方式編輯該單元格所對應的行數(shù)據。換句話說，我們在側邊抽屜中渲染的內容取決于當前選擇的行 —— 我們需要將這行的數(shù)據狀態(tài)記錄下來。

將這行數(shù)據的狀態(tài)的放在側抽屜組件內部是最符合邏輯的，因為當用戶選擇其他單元格時，它應該僅影響側邊的抽屜組件。然而：

我們需要在表格組件里設置這個數(shù)據狀態(tài)。我們用的是?[react-data-grid](https://github.com/adazzle/react-data-grid)?渲染表格，并且它接收一個當用戶點擊一個單元格時會觸發(fā)的回調。就目前來看，這是我們能從表格中獲取選中行數(shù)據的唯一途徑。
但是側邊抽屜組件和表格組件是同級（兄弟）組件，所以不能直接訪問彼此的數(shù)據狀態(tài)。
React 的推薦做法是?提升狀態(tài)?到倆組件最近的父級節(jié)點 (以這個為例，父級節(jié)點為?TablePage)。但是我們決定不將狀態(tài)遷移到這個組件，理由是：

TablePage?不保存狀態(tài)，主要是放置 table 和 side drawer 組件的容器, 兩者都不接收任何的 props。我們傾向于保持這種做法。
我們已經在組件樹的頂層使用 React Context 來共享了許多的全局數(shù)據，并且我們覺得應該將這個狀態(tài)上升到全局 store。

注意：即使我們將數(shù)據狀態(tài)放在了?TablePage，無論如何我們都將面臨下面這個相同的問題。

問題就是每當用戶選擇一個單元格或打開側面抽屜時，全局 context 的更新會使得整個應用發(fā)生重新渲染。table 組件可以一次顯示數(shù)十個單元格，并且每個單元格都有自己的編輯器組件。這會導致大約 650ms 的渲染時間，這個時間太長以至于在打開側邊抽屜的時候會感受到明顯的延遲。

罪魁禍首是 context —— 這就是為什么要在 React 中使用而不是在全局 JavaScript 對象中使用：

”只要提供給 Provider 的值發(fā)生變化，所有消費到了 Provider 的后代組件都會發(fā)生重渲染。“ — React Context

到目前為止，雖然我們已經足夠了解 React 的狀態(tài)和生命周期，但現(xiàn)在看來我們依舊陷入了困境。

頓悟時刻

在決定使用?useRef?之前，我們嘗試了幾種不同的解決方案。(Dan Abramov 的文章) :

拆分 context (也就是創(chuàng)建新的?SideDrawerContext) —— table 組件仍然會消費到新的 context，在打開側邊抽屜的時候依舊會?導致 table 組件的不必要的重新渲染。
將 table 組件放在?React.memo?或?useMemo?中 —— table 組件依舊是需要通過?useContext?拿到側邊抽屜組件的狀態(tài)，兩種 API 均無法阻止其重新渲染。
將用于渲染表格的?react-data-grid?組件進行 memo —— 這將使我們的代碼更加的冗長。我們還發(fā)現(xiàn)它阻止了 “必要” 的重新渲染，要求我們花費更多的時間完全修復或者重構我們的代碼來實現(xiàn)側邊抽屜。

當再次閱讀 Hook APIs 和?useMemo?文檔的時候，我終于遇到了?useRef?相關內容。

“useRef()?比 ref 屬性更有用。它通過像在 class 中使用實例字段的方式，非常方便地?保存任何可變值。” —— React 文檔

更重要的是：

“當 ref 對象內容發(fā)生變化時，useRef?并不會通知變更。變更?.current?屬性不會引發(fā)組件重新渲染。” —— React 文檔

此時：我們不需要存儲側抽屜的狀態(tài)。我們只需要引用設置該狀態(tài)的函數(shù)即可。

解決方案

1. 將打開狀態(tài)和單元狀態(tài)保存在側面抽屜組件中。

2. 創(chuàng)建這些狀態(tài)的 ref，并將其存儲在 context 中。

3. 當用戶單擊單元格時，使用之前說的表中的回調去調用 ref 設置數(shù)據狀態(tài)的函數(shù)（在側抽屜內）。

以下代碼是在 Firetable 使用的代碼縮寫版，其中包括了 ref 和 TypeScript 的類型：

import { SideDrawerRef } from 'SideDrawer'
export function FiretableContextProvider({ children }) {  const sideDrawerRef = useRef();
  return (    <FiretableContext.Provider value={{ sideDrawerRef }}>      {children}    FiretableContext.Provider>  )}

注意：由于函數(shù)組件在重新渲染時會運行整個函數(shù)體，所以每當 “單元” 或 “打開” 狀態(tài)更新（并導致重新渲染）時，“sideDrawerRef” 總是能在 “.current” 中獲取到最新值。

事實證明，此解決方案是最佳的：

當前的單元格和打開的狀態(tài)存儲在側面抽屜組件中 —— 這是放置它的最合邏輯的地方。
當需要時，表格組件也可以訪問其兄弟組件的狀態(tài)。
當前單元格或打開狀態(tài)更新時，它只會觸發(fā)側抽屜組件的重新渲染，而不觸發(fā)整個應用程序中的其他組件重新渲染。

你可以在 Firetable GitHub 源碼中看它是如何被使用的。

什么時候使用 useRef

不過，這并不意味著您可以在應用中隨意使用。當您需要在特定時間訪問或更新另一個組件的狀態(tài)，但是您的其他組件不依賴于該狀態(tài)或基于該狀態(tài)進行呈現(xiàn)時，這是最好的辦法。React 的提升狀態(tài)和單向數(shù)據流的核心概念足以覆蓋大多數(shù)應用程序架構。

? 今天的文章分享就到這里啦，如果喜歡這篇文章的話請點贊、在看、轉發(fā)關注我吧 ?

如何使用 useRef 優(yōu)化 React 性能問題

如何使用 useRef 修復 React 性能問題

面臨的問題

頓悟時刻

解決方案

什么時候使用 useRef