React不能將useMemo設置為默認方法原因是什么

這篇文章主要介紹了React不能將useMemo設置為默認方法原因是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇React不能將useMemo設置為默認方法原因是什么文章都會有所收獲，下面我們一起來看看吧。

memo

const MyComponent = React.memo(function MyComponent(props) {
  /* 使用 props 渲染 */
});

React.memo 為高階組件。 如果你的組件在相同 props 的情況下渲染相同的結果，那么你可以通過將其包裝在 React.memo 中調用，以此通過記憶組件渲染結果的方式來提高組件的性能表現。這意味著在這種情況下，React 將跳過渲染組件的操作并直接復用最近一次渲染的結果。

useMemo

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

把待執行函數和依賴項數組作為參數傳入 useMemo，返回一個 memoized 值。它僅會在某個依賴項改變時才重新計算 memoized 值。這種優化有助于避免在每次渲染時都進行高開銷的計算。
如果沒有提供依賴項數組，useMemo 在每次渲染時都會計算新的值。

useCallback

const memoizedCallback = useCallback(
  () => {
    doSomething(a, b);
  },
  [a, b],
);

把回調函數及依賴項數組作為參數傳入 useCallback，它將返回該回調函數的 memoized 版本，該回調函數僅在某個依賴項改變時才會更新。

當你把回調函數傳遞給經過優化的并使用引用相等性去避免非必要渲染（例如 shouldComponentUpdate）的子組件時，它將非常有用。

useCallback(fn, deps) 相當于 useMemo(() => fn, deps)。

網上關于React 性能優化的教程????

看起來啊，這兩個 Hooks 確實是可以通過避免非必要渲染，減少我們頁面的重繪，從而提高性能
網上有很多 React 的教程，其中提到性能優化時，也都會告訴你，用 React 開發者工具檢測什么組件出現了太多次的渲染，以及是什么導致的，那就在那上面包裹一個 useMemo

“用它！用它！”

但有沒有想過一個問題：這種特性，為什么 React 不直接在所有相關的東西里面都內部 實現呢？或者說為什么不把他們搞成 default 呢？

不要把它當作語義上的保證

官方文檔告訴你：

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

它本身也不是那么地能保證嘎嘎**好用 **

為什么可能更糟糕????

比如現在有一個方法

const edit = id => {
  setList(list => list.filter(idx => idx !== id))
}

我們“常規”地用 useCallback 優化一下

const edit = useCallback(id => {
  setList(list => list.filter(idx => idx !== id))
}, [])

每行代碼的成本????

實際上，上面優化 后的代碼實際上就相當于這樣：

const edit = id => {
  setList(list => list.filter(idx => idx !== id))
}
const memorizedEdit = useCallback(edit, []) //  多了這一行

可以看作是多了一些東西：

• 一個數組：deps

• 調用 useCallback

• 定義多一個函數，Javascript 在每次渲染的時候都會給函數定義分配內存，并且 useCallback 這個方法會讓其需要更多的內存分配

啊，當然里面這個 deps 數組可以用 useMemo 將其 memorize ，但是~ 這會導致到處都是 useMemo，以及 useMemo 也會像上面 useCallback 一樣帶來一些新的東西...

deps 空間成本以及其帶來的時間成本

前面說到了使用這些肯定會帶有dependency list，它是一個數組，當然有空間成本。除此之外，每次render時自然還要將數組中的每一個值進行一個比對的行為，檢查是否有新的變化
遍歷數組，這也是一個時間復雜度為O(N)的過程~

成本和收獲相近時????

實際上，哪怕成本和收獲相近，那不就是他們其實啥也沒干？ 但你的代碼大小、復雜度等等卻是實實在在的增加了~ 甚至會進一步導致更容易寫出糟糕的代碼

日常開發的“性能優化”????

現在大部分日常項目中的“計算”，對于現代瀏覽器、電腦硬件等，都是非常微乎其微的。實際上，你可能并不需要這些“優化”。所以我建議大部分時候，先讓能達成最終需求效果的代碼跑成功了，遇到性能瓶頸了再添加這些優化的手段

小結????

也就是說**，性能優化并不是 完全免費 的，這是絕對有成本的，甚至有時帶來的好處不能抵消成本。
所以你需要做的是負責任地進行優化**

選擇優化

demo 例子

先來看看這個例子

import { useState } from "react";
export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<div>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事了
	return <p>so big to make it render slowly</p>;
}

隨著 text 的變化，每一次都要渲染非常難辦的 <Big/>

哎不管他到底大不大，總之render不想老是帶ta玩就完事了

當然，你可能第一個想到的就是 套個 memo 就完了~

但是，有沒有其他選擇呢？即剩下 memo 的成本，又能對其進行性能優化?

抽離組件，帶走 state????

實際上，只有這兩行代碼在意 text不是嗎

<input value={text} onChange={e => setText(e.target.value)} />
<p>{text}</p>

我們將它倆抽離出來為一個組件Small，把 state 放進去就好了~

export default function App() {
	return (
		<div>
			<Small />
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事了
	return <p>so big to make it render slowly</p>;
}
function Small() {
	let [text, setText] = useState("zhou")
  return (
    <>
      <input value={text} onChange={e => setText(e.target.value)} />
      <p>{text}</p>
    </>
  )
}

現在好了，當 text 改變，自然就只有 Small會重新渲染，討厭的<Big/>就不會老來騷擾了，good~

抽離組件， 孤立 Big????

有時候，在意text的是父組件，但其中的“消耗大”的子組件其實并不在意，那該怎么將 care 的和 不 care 的隔離？

import { useState } from "react";
export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<div data-text = {text}>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事了
	return <p>so big to make it render slowly</p>;
}

看起來沒辦法只將 在意state的部分抽離出來，讓其帶走state了... 那我們直接把不在意的孤立了不就好了~

export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<TextAbout>
			<Big />
		</TextAbout>
	);
}
function Big() {
	// ... 很大很麻煩就完事了
	return <p>so big to make it render slowly</p>;
}
function TextAbout({children}){
	let [text, setText] = useState("zhou")
	return (
		<div data-text={text}>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			{children}
		</div>
	)
}

我們將text相關的父組件和子組件全部拿出來，作為TextAbout。不關心text且麻煩的Big留在App中，作為children屬性傳入TextAbout中。當text變化，TextAbout會重新渲染，但是其中保留的仍是之前從App中拿到的children屬性。

好慘的 <Big/>，被狠狠地孤立了，在里面，但不完全在里面 [doge]

小結

當你有使用memo等東東的想法時，你可以先試試不用他們~

那到底應該什么時候用????

前面我們說到了，需要負責任地使用

什么叫負責任地使用????

你怎么樣判斷付出的成本比收獲的少？或許你可以好好地 測量 一下~

React 官方的測量API Profiler

API Profiler

Profiler 測量一個 React 應用多久渲染一次以及渲染一次的“代價”。 它的目的是識別出應用中渲染較慢的部分，或是可以使用類似 memoization 優化的部分，并從相關優化中獲益。

具體用法看文檔啦，搬一大段到文章上也沒意思~

或許還有其他測量方法，自行查閱~

又或者你是完完全全地保證這個組件的渲染真的非常需要時間，能不渲染絕不再次渲染~比如一些很大的動畫？可視化的大屏？巨大圖表？（我猜的 [doge])

或許真的有需要????

真正“備忘錄”的作用????

這個點其實原生 JS 也是一樣的道理：一段代碼執行比較耗時，但是執行的結果經常用到，那就用一個東西將其結果存起來，再用到的時候直接取~ 以空間換時間--

其實 React 這幾個 API 某種程度也是有 空間換時間 的思想

大概是這樣

const ans = useMemo(() => calculate(a, b), [a, b]);

有時需要“引用相等”????

寫 JS 的都知道的：

{} !== {}
[] !== []
()=>{} !== ()=>{}

以上都為 true~
這意味著useEffect等hook中比對deps時會出現：他完全一樣，但是 React 不認為他一樣

React 中用的是Object.is，但是對于這些情況，和===差不多

關于“React不能將useMemo設置為默認方法原因是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“React不能將useMemo設置為默認方法原因是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。