React 中解決 JS 引用變化問題的探索與展望

語言: CN / TW / HK
時間 2022-04-01 02:15:06

theme: juejin

本文首發於公眾號「小李的前端小屋」，歡迎關注～

前言

為了讓開發者更簡單的構建符合 UI = f(state) 哲學理念的 UX，React 引入了函式式元件和一套邏輯複用的解決方案 —— Hooks。

但是 Hooks 的引入也帶來一些問題：

  • useCallback，useMmeo，useRef 等使用讓程式碼不好讀。
  • 需要關心 JS 複雜型別的引用變化，有一定心智負擔，甚至會影響業務邏輯的正確與否。

引用變化造成的問題

引用型別是 JS 一種複雜資料型別，統稱為 object 型別，包括物件，陣列，函式等。在比較 object 型別時，實際上比較的是它們的引用，使用 == / === 無法判斷兩個物件的“值”否相等。

js const a = {}; const b = {}; console.log(a === b); // false

而 React 函式元件每次渲染都會呼叫自身函式，函式內定義的所有區域性變數都會被重新建立。如果其中有引用型別的物件變數，重新建立會導致引用改變，使用在下列場景中會有一定風險：

  • 這個物件被作為 useEffect、 useMemo 或 useCallback 的依賴，會導致邏輯和計算頻繁執行。

  • 這個物件作為 prop 被傳遞給下游被 React.memo 的元件或 React.PureComponent 繼承元件，引起下游元件的非預期重新渲染，如果下游元件的渲染開銷較大，會引起效能問題。

探索

為了保持引用的穩定，可以藉助 React 提供的 Hook API：

  1. 使用 useCallback 和 useMemo 包一下引用型別
  2. 將引用型別掛在 Ref 上

使用它們，我們能產出最佳實踐嗎？

memo 所有物件

我們分場景討論一下：

對於業務程式碼

業務程式碼功能複雜，DOM 樹層級很深很龐大，所以對應的 React 元件樹也會很複雜。如果在每一個元件中都有 useMemo/useCallback，會讓元件的渲染時間長，佔用更多的記憶體。幾百個元件加在一起，對效能的損害比它們本身起到的作用要大。

所以業務程式碼裡的 useMemo 和 useCallback 需要有節制的去使用，關於它們使用場景的討論一直都是 React 的熱點話題，網上文章一搜一大把，但到目前也沒有一個受到廣泛認可的最佳實踐，這裡不再多討論了。但有一點我比較贊同的是，應該保證 useEffect，useMemo 和 useCallback 的依賴項和元件的 props 都是基本型別，能有效減小引用變化帶來的影響。

對於第三方庫

作為第三方庫，穩定性是比較重要的，應該保證不出現自身原因導致的下游依賴方問題，「memo 所有物件」是沒有辦法中的辦法。比如 React Hook Form 和 ahooks，它們為了解決引用問題，所有暴露的物件都是 memoized 的。

```js // react-hook-form

return { swap: React.useCallback(swap, [updateValues, name, control, keyName]), move: React.useCallback(move, [updateValues, name, control, keyName]), prepend: React.useCallback(prepend, [updateValues, name, control, keyName]), append: React.useCallback(append, [updateValues, name, control, keyName]), remove: React.useCallback(remove, [updateValues, name, control, keyName]), insert: React.useCallback(insert, [updateValues, name, control, keyName]), update: React.useCallback(update, [updateValues, name, control, keyName]), replace: React.useCallback(replace, [updateValues, name, control, keyName]), fields: React.useMemo( () => fields.map((field, index) => ({ ...field, [keyName]: ids.current[index] || generateId(), })) as FieldArrayWithId[], [fields, keyName], ) }; ```

useMemoOne

事實上，即使值被 useMemo 和 useCallback 快取起來了，快取也有可能丟失。

這點在 React 文件裡也有說明：

你可以把 useMemo 作為效能優化的手段，但不要把它當成語義上的保證。 將來，React 可能會選擇“遺忘”以前的一些 memoized 值，並在下次渲染時重新計算它們，比如為離屏元件釋放記憶體。先編寫在沒有 useMemo 的情況下也可以執行的程式碼 —— 之後再在你的程式碼中新增 useMemo，以達到優化效能的目的。

（但是，目前我還沒有聽說過該機制引發的問題）。

為了解決”遺忘“可能會造成的引用變化，社群裡有一種永遠不會被"遺忘"的 useMemo 設計 ——useMemoOne，而且在併發模式下，它也是安全的。

```ts // before const value = useMemo(() => ({ hello: name }), [name]);

// after const value = useMemoOne(() => ({ hello: name }), [name]); ```

但是為了永久的穩定引用，保證在垃圾回收之前不會釋放快取，useMemoOne 會比 useMemo 佔用的更多的記憶體。

因此，useMemoOne 也只是個使用於個別場景的備選方案。

狀態都掛到 Ref 上

React 選擇性”遺忘“也並不是一個大問題，把這些值都掛在 Ref 上就行了。

因為複雜引用的問題根本原因是物件的引用會隨著重新渲染而變化，而 Ref 中儲存的值不會在每次渲染時銷燬和新建。

可以把 useRef 當作 useState({current: initialValue })[0]

具體做法是使用 useRef 建立元件例項 instanceRef，並把這個元件用到的所有狀態都儲存在這個 instanceRef 當中。

```ts const myComponent = () => { const instanceRef = useRef({ state1: ... state2: ...

value1: ...
value2: ...

func1: ...
func2: ...

});

// ... } ```

需要更新檢視時，手動呼叫 forceUpdate()。

ts const forceUpdate = React.useReducer(() => ({}), {})[1]

這是一個比較少眾的方案，但社群裡也有對應的實踐。比如 react-table 中的 useTable API，它將 table 有關的屬性和方法都存在了 instanceRef 中，並用 rerender 方法(也就是 forceUpdate) 手動控制檢視更新。

```js function useTable(options: Options) { const instanceRef = React.useRef(undefined!)

const rerender = React.useReducer(() => ({}), {})[1]

if (!instanceRef.current) { instanceRef.current = createTableInstance< TData, TValue, TFilterFns, TSortingFns, TAggregationFns >(options, rerender) }

return instanceRef.current } ```

這種做法確實可以解決引用變化的問題，但是程式碼不宜維護：

  1. 對 state 的取值需要從 someState 改為 ref.someState，一旦一個元件這樣寫了之後，之後要有什麼新的狀態也只好放到 ref 裡面，整個 instanceRef 的複雜度會不斷提高。
  2. 檢視上有任何狀態不匹配的表現時，問題排查困難，為了同步狀態只有使用 forceUpdate 來解決。
  3. 每次更新檢視需要手動呼叫 forceUpdate，不太符合函數語言程式設計的思想，官方是不推薦這種方式的。

WX20220329-100156@2x.png

展望

以上的方案都有點投機取巧，算不上最佳實踐。未來會有更好的方案嗎？

Record 和 Tuple 型別

在 JS 中，物件的比較不是值的比較，而是引用的比較。這點是由 JS 語言本身決定的。有沒有可能從 JS 語言這方面去解決呢？

在最近的 proposal-record-tuple 提案中，JS 新增了兩個原始資料型別：Record 和 Tuple。它讓 js 原生支援了不可變資料型別，可以讓 js 開出一條原生 immutable 賽道。

Record 和 Tuple 其實就是一個只讀的 Object 和 Array，在原先的物件和陣列前面加 # 就能完成定義。

```ts // Record const myRecords = #{ x: 1, y: 2 };

// Tuple const myTuplee = #[1, 2, 3]; ```

關鍵的是，Record 和 Tuple 的比較採用的是值比較，而不是引用比較：

```ts const a = #{}; const b = #{}; console.log(a === b); // true

const c = #[] const d = #[]; console.log(c === d); // true ```

有了這個機制，我們不用再 memo 所有物件，不用再見到 useMemo 滿天飛的程式碼了！但遺憾的是，這次只提案了 Object 和 Array，Function 仍然沒有得到支援，所以 useCallback 還是得繼續接著用。

如果你還想深入瞭解該提案能夠幫助解決 React 的哪些問題，推薦精讀《Records & Tuples for React》 by 黃子毅老師

React Forget

在 React Conf 2021 上，黃玄老師分享了一個名為 React Forget 的編譯器。

v2-52d7502e71bae8204aaba2647fb7da47_1440w.jpeg

簡單來說，這個編譯器會在程式碼編譯時，檢測 useMemo 和 useCallback 的必要性並自動幫你加上，來優化元件的重新渲染過程。

不只是 useMemo 和 useCallback，React 節點是否需要 memo 也會被檢測，所以未來 React.memo 可能也不再需要了，真正實現 React without memo。

v2-9aa6eba4308dadf31b9d7d0514047837_1440w.jpeg

完整演講影片 請點此。

結語

JS 引用型別特性給 React 函式元件的使用帶來了心智負擔和使用成本。

在當下，React 的高自由度可以讓我們去選擇契合業務場景的解決方案。

在未來，可能會從 JS 語言本身和 React 方面來根本解決引用型別問題。

謝謝支援❤️

如果本文對你有幫助，幫我點個贊吧（關注更好^ ^。

我的公眾號「小李的前端小屋」最近剛剛建立，還在不斷完善中，關注我，一起變強！🚀

參考

  • http://giacomocerquone.com/whats-an-object-identity-in-javascript/
  • http://www.zhenghao.io/posts/memo-or-not?utm_campaign=This%20Week%20In%20React&utm_medium=email&utm_source=Revue%20newsletter
  • http://kentcdodds.com/blog/usememo-and-usecallback#why-is-usecallback-worse
  • http://royi-codes.vercel.app/thousand-usecallbacks/
  • http://zhuanlan.zhihu.com/p/443807113
  • http://javascript.plainenglish.io/react-conf-2021-react-forget-310ef73e9a70
「」
「」