今亮點！如何優(yōu)雅的使用 React Context

2023-06-16 10:06:14來源：大轉(zhuǎn)轉(zhuǎn)FE

在開始今天的文章之前，大家不妨先想一下觸發(fā)React組件re-render的原因有哪些，或者說什么時候React組件會發(fā)生re-render。

(相關(guān)資料圖)

先說結(jié)論：

狀態(tài)變化父組件re-renderContext變化Hooks變化

這里有個誤解：props變化也會導(dǎo)致re-render。其實不會的，props的變化往上追溯是因為父組件的state變化導(dǎo)致父組件re-render，從而引起了子組件的re-render，與props是否變化無關(guān)的。只有那些使用了React.memo和useMemo的組件，props的變化才會觸發(fā)組件的re-render。

針對上述造成re-render的原因，又該通過怎樣的策略優(yōu)化呢？感興趣的朋友可以看這篇文章：React re-renders guide: everything, all at once。

接下來開始我們今天的主題：如何優(yōu)雅的使用React Context。上面我們提到了Context的變化也會觸發(fā)組件的re-render，那React Context又是怎么工作呢？先簡單介紹一下Context的工作原理。

Context 的工作原理

Context是React提供的一種直接訪問祖先節(jié)點上的狀態(tài)的方法，從而避免了多級組件層層傳遞props的頻繁操作。

創(chuàng)建 Context

通過React.createContext創(chuàng)建Context對象

export function createContext(  defaultValue) {  const context = {    $$typeof: REACT_CONTEXT_TYPE,    _currentValue: defaultValue,     _currentValue2: defaultValue,     _threadCount: 0,    Provider: (null: any),    Consumer: (null: any),  };  context.Provider = {    $$typeof: REACT_PROVIDER_TYPE,    _context: context,  };  context.Consumer = context;  return context;}

React.createContext的核心邏輯：

將初始值存儲在context._currentValue創(chuàng)建Context.Provider和Context.Consumer對應(yīng)的ReactElement對象

在fiber樹渲染時，通過不同的workInProgress.tag處理Context.Provider和Context.Consumer類型的節(jié)點。

主要看下針對Context.Provider的處理邏輯：

function updateContextProvider(  current: Fiber | null,  workInProgress: Fiber,  renderLanes: Lanes,) {  const providerType = workInProgress.type;  const context = providerType._context;    const newProps = workInProgress.pendingProps;  const oldProps = workInProgress.memoizedProps;    const newValue = newProps.value;  pushProvider(workInProgress, context, newValue);  if (oldProps !== null) {    // 更新 context 的核心邏輯  }  const newChildren = newProps.children;  reconcileChildren(current, workInProgress, newChildren, renderLanes);  return workInProgress.child;}

消費 Context

在React中提供了 3 種消費Context的方式

直接使用Context.Consumer組件（也就是上面createContext時創(chuàng)建的Consumer）類組件中，可以通過靜態(tài)屬性contextType消費Context函數(shù)組件中，可以通過useContext消費Context

這三種方式內(nèi)部都會調(diào)用prepareToReadContext和readContext處理Context。prepareToReadContext中主要是重置全局變量為readContext做準(zhǔn)備。

接下來主要看下readContext：

export function readContext(  context: ReactContext,  observedBits: void | number | boolean,): T {  const contextItem = {    context: ((context: any): ReactContext),    observedBits: resolvedObservedBits,    next: null,  };  if (lastContextDependency === null) {    lastContextDependency = contextItem;    currentlyRenderingFiber.dependencies = {      lanes: NoLanes,      firstContext: contextItem,      responders: null,    };  } else {    lastContextDependency = lastContextDependency.next = contextItem;  }  // 2. 返回 currentValue  return isPrimaryRenderer ? context._currentValue : context._currentValue2;}

readContext的核心邏輯：

構(gòu)建contextItem并添加到workInProgress.dependencies鏈表（contextItem中保存了對當(dāng)前context的引用，這樣在后續(xù)更新時，就可以判斷當(dāng)前fiber是否依賴了context，從而判斷是否需要re-render）返回對應(yīng)context的_currentValue值更新 Context

當(dāng)觸發(fā)Context.Provider的re-render時，重新走updateContextProvider中更新的邏輯：

function updateContextProvider(  current: Fiber | null,  workInProgress: Fiber,  renderLanes: Lanes,) {  // ...  // 更新邏輯  if (oldProps !== null) {      const oldValue = oldProps.value;      if (is(oldValue, newValue)) {        // 1. value 未發(fā)生變化時，直接走 bailout 邏輯        if (          oldProps.children === newProps.children &&          !hasLegacyContextChanged()        ) {          return bailoutOnAlreadyFinishedWork(            current,            workInProgress,            renderLanes,          );        }      } else {        // 2. value 變更時，走更新邏輯        propagateContextChange(workInProgress, context, renderLanes);      }  //...}

接下來看下propagateContextChange(核心邏輯在propagateContextChange_eager中) 的邏輯：

function propagateContextChange_eager < T > (    workInProgress: Fiber,    context: ReactContext < T > ,    renderLanes: Lanes,): void {    let fiber = workInProgress.child;    if (fiber !== null) {        fiber.return = workInProgress;    }    // 從子節(jié)點開始匹配是否存在消費了當(dāng)前 Context 的節(jié)點    while (fiber !== null) {        let nextFiber;        const list = fiber.dependencies;        if (list !== null) {            nextFiber = fiber.child;            let dependency = list.firstContext;            while (dependency !== null) {                // 1. 判斷 fiber 節(jié)點的 context 和當(dāng)前 context 是否匹配                if (dependency.context === context) {                    // 2. 匹配時，給當(dāng)前節(jié)點調(diào)度一個更新任務(wù)                    if (fiber.tag === ClassComponent) {}                    fiber.lanes = mergeLanes(fiber.lanes, renderLanes);                    const alternate = fiber.alternate;                    if (alternate !== null) {                        alternate.lanes = mergeLanes(alternate.lanes, renderLanes);                    }                    // 3. 向上標(biāo)記 childLanes                    scheduleContextWorkOnParentPath(                        fiber.return,                        renderLanes,                        workInProgress,                    );                    list.lanes = mergeLanes(list.lanes, renderLanes);                    break;                }                dependency = dependency.next;            }        } else if (fiber.tag === ContextProvider) {} else if (fiber.tag === DehydratedFragment) {} else {}        // ...        fiber = nextFiber;    }}

核心邏輯：

從ContextProvider的節(jié)點出發(fā)，向下查找所有fiber.dependencies依賴當(dāng)前Context的節(jié)點找到消費節(jié)點時，從當(dāng)前節(jié)點出發(fā)，向上回溯標(biāo)記父節(jié)點fiber.childLanes，標(biāo)識其子節(jié)點需要更新，從而保證了所有消費了該Context的子節(jié)點都會被重新渲染，實現(xiàn)了Context的更新總結(jié)在消費階段，消費者通過readContext獲取最新狀態(tài)，并通過fiber.dependencies關(guān)聯(lián)當(dāng)前Context在更新階段，從ContextProvider節(jié)點出發(fā)查找所有消費了該context的節(jié)點如何避免 Context 引起的 re-render

從上面分析Context的整個工作流程，我們可以知道當(dāng)ContextProvider接收到value變化時就會找到所有消費了該Context的組件進(jìn)行re-render，若ContextProvider的value是一個對象時，即使沒有使用到發(fā)生變化的value的組件也會造成多次不必要的re-render。

那我們怎么做優(yōu)化呢？直接說方案：

將ContextProvider的值做memoize處理對數(shù)據(jù)和API做拆分（或者說是將getter（state）和setter（API）做拆分）對數(shù)據(jù)做拆分（細(xì)粒度拆分）Context Selector

具體的case可參考上述提到的優(yōu)化文章：React re-renders guide: everything, all at once。

接下來開始我們今天的重點：Context Selector。開始之前先來個 case1：

import React, { useState } from "react";const StateContext = React.createContext(null);const StateProvider = ({ children }) => { console.log("StateProvider render");  const [count1, setCount1] = useState(1); const [count2, setCount2] = useState(1); return (     {children}   );};const Counter1 = () => { console.log("count1 render");  const { count1, setCount1 } = React.useContext(StateContext); return (  <>   Count1: {count1}
    );};const Counter2 = () => { console.log("count2 render");  const { count2, setCount2 } = React.useContext(StateContext);  return (  <>   Count2: {count2}
      );};const App = () => { return (           );};export default App;

?
開發(fā)環(huán)境記得關(guān)閉 StrictMode 模式，否則每次re-render都會走兩遍。具體使用方式和 StrictMode 的意義可參考官方文檔。
?

通過上面的case，我們會發(fā)現(xiàn)在count1觸發(fā)更新時，即使Counter2沒有使用count1也會進(jìn)行re-render。這是因為count1的更新會引起StateProvider的re-render，從而會導(dǎo)致StateProvider的value生成全新的對象，觸發(fā)ContextProvider的re-render，找到當(dāng)前Context的所有消費者進(jìn)行re-render。

如何做到只有使用到Context的value改變才觸發(fā)組件的re-render呢？社區(qū)有一個對應(yīng)的解決方案 dai-shi/use-context-selector: React useContextSelector hook in userland。

接下來我們改造一下上述的 case2：

import React, { useState } from "react";import { createContext, useContextSelector } from "use-context-selector";const context = createContext(null);const Counter1 = () => {  const count1 = useContextSelector(context, v => v[0].count1);  const setState = useContextSelector(context, v => v[1]);  const increment = () => setState(s => ({    ...s,    count1: s.count1 + 1,  }));  return (          Count1: {count1}            {Math.random()}    
  );};const Counter2 = () => {  const count2 = useContextSelector(context, v => v[0].count2);  const setState = useContextSelector(context, v => v[1]);  const increment = () => setState(s => ({    ...s,    count2: s.count2 + 1,  }));  return (          Count2: {count2}            {Math.random()}    
  );};const StateProvider = ({ children }) => (      {children}  );const App = () => (            );export default App

這時候問題來了，不是說好精準(zhǔn)渲染的嗎？怎么還是都會進(jìn)行re-render。解決方案：將react改為v17版本（v17對應(yīng)的case3），后面我們再說具體原因（只想說好坑..）。

use-context-selector

接下來我們主要分析下createContext和useContextSelector都做了什么（官方還有其他的 API ，感興趣的朋友可以自行查看，核心還是這兩個API）。

createContext

簡化一下，只看核心邏輯：

import { createElement, useLayoutEffect, useRef, createContext as createContextOrig } from "react"const CONTEXT_VALUE = Symbol();const ORIGINAL_PROVIDER = Symbol();const createProvider = (  ProviderOrig) => {  const ContextProvider = ({ value, children }) => {    const valueRef = useRef(value);    const contextValue = useRef();        if (!contextValue.current) {      const listeners = new Set();      contextValue.current = {        [CONTEXT_VALUE]: {          /* "v"alue     */ v: valueRef,          /* "l"isteners */ l: listeners,        },      };    }    useLayoutEffect(() => {      valueRef.current = value;  contextValue.current[CONTEXT_VALUE].l.forEach((listener) => {          listener({ v: value });        });    }, [value]);        return createElement(ProviderOrig, { value: contextValue.current }, children);  };  return ContextProvider;};export function createContext(defaultValue) {  const context = createContextOrig({    [CONTEXT_VALUE]: {      /* "v"alue     */ v: { current: defaultValue },      /* "l"isteners */ l: new Set(),    },  });  context[ORIGINAL_PROVIDER] = context.Provider;  context.Provider = createProvider(context.Provider);  delete context.Consumer; // no support for Consumer  return context;}

對原始的createContext包一層，同時為了避免value的意外更新造成消費者的不必要re-render，將傳遞給原始的createContext的value通過uesRef進(jìn)行存儲，這樣在React內(nèi)部對比新舊value值時就不會再操作re-render（后續(xù)value改變后派發(fā)更新時就需要通過listener進(jìn)行re-render了），最后返回包裹后的createContext給用戶使用。

useContextSelector

接下來看下簡化后的useContextSelector：

export function useContextSelector(context, selector) { const contextValue = useContextOrig(context)[CONTEXT_VALUE]; const { /* "v"alue */ v: { current: value }, /* "l"isteners */ l: listeners } = contextValue;  const selected = selector(value); const [state, dispatch] = useReducer(  (prev, action) => {   if ("v" in action) {    if (Object.is(prev[0], action.v)) {     return prev; // do not update    }    const nextSelected = selector(action.v);    if (Object.is(prev[1], nextSelected)) {     return prev; // do not update    }    return [action.v, nextSelected];   }  },  [value, selected] );  useLayoutEffect(() => {  listeners.add(dispatch);  return () => {   listeners.delete(dispatch);  };  }, [listeners]);  return state[1];}

核心邏輯：

每次渲染時，通過selector和value獲取最新的selected同時將useReducer對應(yīng)的dispatch添加到listeners當(dāng)value改變時，就會執(zhí)行l(wèi)isteners中收集到dispatch函數(shù)，從而在觸發(fā)reducer內(nèi)部邏輯，通過對比value和selected是否有變化，來決定是否觸發(fā)當(dāng)前組件的re-render在 react v18 下的 bug

回到上面的case在react v18的表現(xiàn)和在原始Context的表現(xiàn)幾乎一樣，每次都會觸發(fā)所有消費者的re-render。再看use-context-selector內(nèi)部是通過useReducer返回的dispatch函數(shù)派發(fā)組件更新的。

接下來再看下useReducer在react v18和v17版本到底有什么不一樣呢？看個簡單的case：

import React, { useReducer } from "react";const initialState = 0;const reducer = (state, action) => { switch (action) {  case "increment":   return state;  default:   return state; }};export const App = () => { console.log("UseReducer Render"); const [count, dispatch] = useReducer(reducer, initialState);  return (     Count = {count}
     
 );};

簡單描述下：多次點擊按鈕「Inacrement」，在react的v17和v18版本分別會有什么表現(xiàn)？

先說結(jié)論：

v17：只有首次渲染會觸發(fā)App組件的render，后續(xù)點擊將不再觸發(fā)re-renderv18：每次都會觸發(fā)App組件的re-render（即使?fàn)顟B(tài)沒有實質(zhì)性的變化也會觸發(fā)re-render）

這就要說到【eager state策略】了，在React內(nèi)部針對多次觸發(fā)更新，而最后狀態(tài)并不會發(fā)生實質(zhì)性變化的情況，組件是沒有必要渲染的，提前就可以中斷更新了。

也就是說useReducer內(nèi)部是有做一定的性能優(yōu)化的，而這優(yōu)化會存在一些bug，最后React團(tuán)隊也在v18后移除了該優(yōu)化策略（注：useState還是保留該優(yōu)化），詳細(xì)可看該相關(guān) PR Remove usereducer eager bailout。當(dāng)然該 PR 在社區(qū)也存在一些討論（Bug: useReducer and same state in React 18），畢竟無實質(zhì)性的狀態(tài)變更也會觸發(fā)re-render，對性能還是有一定影響的。

回歸到useContextSelector，無優(yōu)化版本的useReducer又是如何每次都觸發(fā)組件re-render呢？

具體原因：在上面useReducer中，是通過Object.is判斷value是否發(fā)生了實質(zhì)性變化，若沒有，就返回舊的狀態(tài)，在v17有優(yōu)化策略下，就不會再去調(diào)度更新任務(wù)了，而在v18沒有優(yōu)化策略的情況下，每次都會調(diào)度新的更新任務(wù)，從而引發(fā)組件的re-render。

通過 useSyncExternalStore 優(yōu)化

通過分析知道造成re-render的原因是使用了useReducer，那就不再依賴該hook，使用react v18新的 hook useSyncExternalStore 來實現(xiàn)useContextSelector（優(yōu)化后的 case4）。

export function useContextSelector(context, selector) { const contextValue = useContextOrig(context)[CONTEXT_VALUE]; const { /* "v"alue */ v: { current: value }, /* "l"isteners */ l: listeners } = contextValue;  const lastSnapshot = useRef(selector(value)); const subscribe = useCallback(  (callback) => {   listeners.add(callback);   return () => {    listeners.delete(callback);   };  },  [listeners] );  const getSnapshot = () => {  const {  /* "v"alue */ v: { current: value }  } = contextValue;    const nextSnapshot = selector(value);  lastSnapshot.current = nextSnapshot;  return nextSnapshot; };  return useSyncExternalStore(subscribe, getSnapshot);}

實現(xiàn)思路：

收集訂閱函數(shù)subscribe的callback（即useSyncExternalStore內(nèi)部的handleStoreChange）當(dāng)value發(fā)生變化時，觸發(fā)listeners收集到的callback，也就是執(zhí)行 handleStoreChange 函數(shù)，通過getSnapshot獲取新舊值，并通過Object.is進(jìn)行對比，判斷當(dāng)前組件是否需要更新，從而實現(xiàn)了useContextSelector的精確更新

當(dāng)然除了useReducer對應(yīng)的性能問題，use-context-selector還存在其他的性能，感興趣的朋友可以查看這篇文章從 0 實現(xiàn) use-context-selector。同時，use-context-selector也是存在一些限制，比如說不支持Class組件、不支持Consumer…

針對上述文章中，作者提到的問題二和問題三，個人認(rèn)為這并不是use-context-selector的問題，而是React底層自身帶來的問題。比如說：問題二，React組件是否re-render跟是否使用了狀態(tài)是沒有關(guān)系的，而是和是否觸發(fā)了更新狀態(tài)的dispatch有關(guān)，如果一定要和狀態(tài)綁定一起，那不就是Vue了嗎。對于問題三，同樣是React底層的優(yōu)化策略處理并沒有做到極致這樣。

總結(jié)

回到React Context工作原理來看，只要有消費者訂閱了該Context，在該Context發(fā)生變化時就會觸達(dá)所有的消費者。也就是說整個工作流程都是以Context為中心的，那只要把Context拆分的粒度足夠小就不會帶來額外的渲染負(fù)擔(dān)。但是這樣又會帶來其他問題：ContextProvider會嵌套多層，同時對于粒度的把握對開發(fā)者來說又會帶來一定的心智負(fù)擔(dān)。

從另一條路出發(fā)：Selector機(jī)制，通過選擇需要的狀態(tài)從而規(guī)避掉無關(guān)的狀態(tài)改變時帶來的渲染開銷。除了社區(qū)提到的 use-context-selector ，React團(tuán)隊也有一個相應(yīng)的RFC方案 RFC: Context selectors，不過這個RFC從 19 年開始目前還處于持續(xù)更新階段。

最后，對于React Context的使用，個人推薦：「不頻繁更改的全局狀態(tài)（比如說：自定義主題、賬戶信息、權(quán)限信息等）可以合理使用Context，而對于其他頻繁修改的全局狀態(tài)可以通過其他數(shù)據(jù)流方式維護(hù)，可以更好的避免不必要的re-render開銷」。

參考https://www.developerway.com/posts/react-re-renders-guidehttps://react.dev/reference/react/StrictMode#enabling-strict-mode-for-entire-apphttps://github.com/dai-shi/use-context-selectorhttps://github.com/facebook/react/pull/22445https://github.com/facebook/react/issues/24596https://react.dev/reference/react/useSyncExternalStorehttps://juejin.cn/post/7197972831795380279https://github.com/reactjs/rfcs/pull/119case1：https://codesandbox.io/s/serverless-frost-9ryw2x?file=/src/App.jscase2：https://codesandbox.io/s/use-context-selector-vvs93q?file=/src/App.jscase3：https://codesandbox.io/s/elegant-montalcini-nkrvlh?file=/src/App.jscase4：https://codesandbox.io/s/use-context-selector-smsft3?file=/src/App.js

關(guān)鍵詞：