我在大廠寫React學到了什么？性能優化篇

作者： ssh前端 2020-10-30 12:40:04

開發項目管理

我工作中的技術棧主要是 React + TypeScript，這篇文章我想總結一下如何在項目中運用 React 的一些技巧去進行性能優化，或者更好的代碼組織。

[[349492]]

前言

我工作中的技術棧主要是 React + TypeScript，這篇文章我想總結一下如何在項目中運用 React 的一些技巧去進行性能優化，或者更好的代碼組織。

性能優化的重要性不用多說，谷歌發布的很多調研精確的展示了性能對于網站留存率的影響，而代碼組織優化則關系到后續的維護成本，以及你同事維護你代碼時候“口吐芬芳”的頻率??，本篇文章看完，你一定會有所收獲。

神奇的 children

我們有一個需求，需要通過 Provider 傳遞一些主題信息給子組件：

看這樣一段代碼：

import React, { useContext, useState } from "react"; 
 
const ThemeContext = React.createContext(); 
 
export function ChildNonTheme() { 
  console.log("不關心皮膚的子組件渲染了"); 
  return <div>我不關心皮膚，皮膚改變的時候別讓我重新渲染！</div>; 
} 
 
export function ChildWithTheme() { 
  const theme = useContext(ThemeContext); 
  return <div>我是有皮膚的哦~ {theme}</div>; 
} 
 
export default function App() { 
  const [theme, setTheme] = useState("light"); 
  const onChangeTheme = () => setTheme(theme === "light" ? "dark" : "light"); 
  return ( 
    <ThemeContext.Provider value={theme}> 
      <button onClick={onChangeTheme}>改變皮膚</button> 
      <ChildWithTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
    </ThemeContext.Provider> 
  ); 
}

這段代碼看起來沒啥問題，也很符合擼起袖子就干的直覺，但是卻會讓 ChildNonTheme 這個不關心皮膚的子組件，在皮膚狀態更改的時候也進行無效的重新渲染。

這本質上是由于 React 是自上而下遞歸更新，這樣的代碼會被 babel 翻譯成 React.createElement(ChildNonTheme) 這樣的函數調用，React官方經常強調 props 是immutable 的，所以在每次調用函數式組件的時候，都會生成一份新的 props 引用。

來看下 createElement 的返回結構：

const childNonThemeElement = { 
  type: 'ChildNonTheme', 
  props: {} // <- 這個引用更新了 
}

正是由于這個新的 props 引用，導致 ChildNonTheme 這個組件也重新渲染了。

那么如何避免這個無效的重新渲染呢?關鍵詞是「巧妙利用 children」。

import React, { useContext, useState } from "react"; 
 
const ThemeContext = React.createContext(); 
 
function ChildNonTheme() { 
  console.log("不關心皮膚的子組件渲染了"); 
  return <div>我不關心皮膚，皮膚改變的時候別讓我重新渲染！</div>; 
} 
 
function ChildWithTheme() { 
  const theme = useContext(ThemeContext); 
  return <div>我是有皮膚的哦~ {theme}</div>; 
} 
 
function ThemeApp({ children }) { 
  const [theme, setTheme] = useState("light"); 
  const onChangeTheme = () => setTheme(theme === "light" ? "dark" : "light"); 
  return ( 
    <ThemeContext.Provider value={theme}> 
      <button onClick={onChangeTheme}>改變皮膚</button> 
      {children} 
    </ThemeContext.Provider> 
  ); 
} 
 
export default function App() { 
  return ( 
    <ThemeApp> 
      <ChildWithTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
      <ChildNonTheme /> 
    </ThemeApp> 
  ); 
}

沒錯，唯一的區別就是我把控制狀態的組件和負責展示的子組件給抽離開了，通過 children 傳入后直接渲染，由于 children 從外部傳入的，也就是說 ThemeApp 這個組件內部不會再有 React.createElement 這樣的代碼，那么在 setTheme 觸發重新渲染后，children 完全沒有改變，所以可以直接復用。

讓我們再看一下被 ThemeApp 包裹下的，它會作為 children 傳遞給 ThemeApp，ThemeApp 內部的更新完全不會觸發外部的 React.createElement，所以會直接復用之前的 element 結果：

// 完全復用，props 也不會改變。 
const childNonThemeElement = { 
  type: ChildNonTheme, 
  props: {} 
}

在改變皮膚之后，控制臺空空如也!優化達成。

總結下來，就是要把渲染比較費時，但是不需要關心狀態的子組件提升到「有狀態組件」的外部，作為 children 或者props傳遞進去直接使用，防止被帶著一起渲染。

神奇的 children - 在線調試地址

當然，這個優化也一樣可以用 React.memo 包裹子組件來做，不過相對的增加維護成本，根據場景權衡選擇吧。

Context 讀寫分離

想象一下，現在我們有一個全局日志記錄的需求，我們想通過 Provider 去做，很快代碼就寫好了：

import React, { useContext, useState } from "react"; 
import "./styles.css"; 
 
const LogContext = React.createContext(); 
 
function LogProvider({ children }) { 
  const [logs, setLogs] = useState([]); 
  const addLog = (log) => setLogs((prevLogs) => [...prevLogs, log]); 
  return ( 
    <LogContext.Provider value={{ logs, addLog }}> 
      {children} 
    </LogContext.Provider> 
  ); 
} 
 
function Logger1() { 
  const { addLog } = useContext(LogContext); 
  console.log('Logger1 render') 
  return ( 
    <> 
      <p>一個能發日志的組件1</p> 
      <button onClick={() => addLog("logger1")}>發日志</button> 
    </> 
  ); 
} 
 
function Logger2() { 
  const { addLog } = useContext(LogContext); 
  console.log('Logger2 render') 
  return ( 
    <> 
      <p>一個能發日志的組件2</p> 
      <button onClick={() => addLog("logger2")}>發日志</button> 
    </> 
  ); 
} 
 
function LogsPanel() { 
  const { logs } = useContext(LogContext); 
  return logs.map((log, index) => <p key={index}>{log}</p>); 
} 
 
export default function App() { 
  return ( 
    <LogProvider> 
      {/* 寫日志 */} 
      <Logger1 /> 
      <Logger2 /> 
      {/* 讀日志 */} 
      <LogsPanel /> 
      </div> 
    </LogProvider> 
  ); 
}

我們已經用上了上一章節的優化小技巧，單獨的把 LogProvider 封裝起來，并且把子組件提升到外層傳入。

先思考一下最佳的情況，Logger 組件只負責發出日志，它是不關心logs的變化的，在任何組件調用 addLog 去寫入日志的時候，理想的情況下應該只有 LogsPanel 這個組件發生重新渲染。

但是這樣的代碼寫法卻會導致每次任意一個組件寫入日志以后，所有的 Logger 和 LogsPanel 都發生重新渲染。

這肯定不是我們預期的，假設在現實場景的代碼中，能寫日志的組件可多著呢，每次一寫入就導致全局的組件都重新渲染?這當然是不能接受的，發生這個問題的本質原因官網 Context 的部分已經講得很清楚了：

當 LogProvider 中的 addLog 被子組件調用，導致 LogProvider重渲染之后，必然會導致傳遞給 Provider 的 value 發生改變，由于 value 包含了 logs 和 setLogs 屬性，所以兩者中任意一個發生變化，都會導致所有的訂閱了 LogProvider 的子組件重新渲染。

那么解決辦法是什么呢?其實就是讀寫分離，我們把 logs(讀)和 setLogs(寫)分別通過不同的 Provider 傳遞，這樣負責寫入的組件更改了 logs，其他的「寫組件」并不會重新渲染，只有真正關心 logs 的「讀組件」會重新渲染。

function LogProvider({ children }) { 
  const [logs, setLogs] = useState([]); 
  const addLog = useCallback((log) => { 
    setLogs((prevLogs) => [...prevLogs, log]); 
  }, []); 
  return ( 
    <LogDispatcherContext.Provider value={addLog}> 
      <LogStateContext.Provider value={logs}> 
        {children} 
      </LogStateContext.Provider> 
    </LogDispatcherContext.Provider> 
  ); 
}

我們剛剛也提到，需要保證 value 的引用不能發生變化，所以這里自然要用 useCallback 把 addLog 方法包裹起來，才能保證 LogProvider 重渲染的時候，傳遞給的LogDispatcherContext的value 不發生變化。

現在我從任意「寫組件」發送日志，都只會讓「讀組件」LogsPanel 渲染。

Context 讀寫分離 - 在線調試

Context 代碼組織

上面的案例中，我們在子組件中獲取全局狀態，都是直接裸用 useContext：

import React from 'react' 
import { LogStateContext } from './context' 
 
function App() { 
  const logs = React.useContext(LogStateContext) 
}

但是是否有更好的代碼組織方法呢?比如這樣：

import React from 'react' 
import { useLogState } from './context' 
 
function App() { 
  const logs = useLogState() 
} 
// context 
import React from 'react' 
 
const LogStateContext = React.createContext(); 
 
export function useLogState() { 
  return React.useContext(LogStateContext) 
}

在加上點健壯性保證?

import React from 'react' 
 
const LogStateContext = React.createContext(); 
const LogDispatcherContext = React.createContext(); 
 
export function useLogState() { 
  const context = React.useContext(LogStateContext) 
  if (context === undefined) { 
    throw new Error('useLogState must be used within a LogStateProvider') 
  } 
  return context 
} 
 
export function useLogDispatcher() { 
  const context = React.useContext(LogDispatcherContext) 
  if (context === undefined) { 
    throw new Error('useLogDispatcher must be used within a LogDispatcherContext') 
  } 
  return context 
}

如果有的組件同時需要讀寫日志，調用兩次很麻煩?

export function useLogs() { 
  return [useLogState(), useLogDispatcher()] 
} 
export function App() { 
  const [logs, addLogs] = useLogs() 
  // ... 
}

根據場景，靈活運用這些技巧，讓你的代碼更加健壯優雅~

組合 Providers

假設我們使用上面的辦法管理一些全局的小狀態，Provider 變的越來越多了，有時候會遇到嵌套地獄的情況：

const StateProviders = ({ children }) => ( 
  <LogProvider> 
    <UserProvider> 
      <MenuProvider> 
        <AppProvider> 
          {children} 
        </AppProvider> 
      </MenuProvider> 
    </UserProvider> 
  </LogProvider> 
) 
 
function App() { 
  return ( 
    <StateProviders> 
      <Main /> 
    </StateProviders> 
  ) 
}

有沒有辦法解決呢?當然有，我們參考 redux 中的 compose 方法，自己寫一個 composeProvider 方法：

function composeProviders(...providers) { 
  return ({ children }) => 
    providers.reduce( 
      (prev, Provider) => <Provider>{prev}</Provider>, 
      children, 
    ) 
}

代碼就可以簡化成這樣：

const StateProviders = composeProviders( 
  LogProvider, 
  UserProvider, 
  MenuProvider, 
  AppProvider, 
) 
 
function App() { 
  return ( 
    <StateProvider> 
      <Main /> 
    </StateProvider> 
  ) 
}

總結

本篇文章主要圍繞這 Context 這個 API，講了幾個性能優化和代碼組織的優化點，總結下來就是：

盡量提升渲染無關的子組件元素到「有狀態組件」的外部。
在需要的情況下對 Context 進行讀寫分離。
包裝Context 的使用，注意錯誤處理。
組合多個 Context，優化代碼。

本文轉載自微信公眾號「前端從進階到入院」，可以通過以下二維碼關注。轉載本文請聯系前端從進階到入院公眾號。

責任編輯：武曉燕來源：前端從進階到入院

Reac 性能優化