資訊專欄INFORMATION COLUMN
摘要：即使中沒有錯誤，仍然會執(zhí)行，這一點一般都是知道的。我們認為這是正確的前進道路，兼具戰(zhàn)略性和務(wù)實性降低使用門檻開發(fā)人員遷移到的障礙之一是從到的并不輕松的遷移。下一步將通過一系列功能和插件為的平滑過渡提供支持，并以此回饋社區(qū)。
useState vs useReducer
關(guān)于 finally 的一些特殊場景
TSLint in 2019
Screenshot To Code
優(yōu)化 React App 性能的 5 個建議
禁用大體積依賴的 import
理解 TS 類型注解
Back/forward cache for Chrome
ES 新提案：Promise.any(promises)
為什么這個函數(shù)不能 new
函數(shù)組件和類組件的根本差異
Preact X Alpha 0 released
Chromium Edge 截圖透出
React 函數(shù)組件的 TypeScript 寫法
用 Jest 和 Enzyme 寫測試
useState vs useReducer這兩個內(nèi)置的 React Hooks 都可以處理狀態(tài)，那么我們應(yīng)該如何對二者進行選擇呢？
根據(jù)我個人的實踐來看，在 H5 項目中，useReducer 可以很好的按照 Redux 的模式完成許多工作，同時又可以不引入 Redux 的依賴。那么大佬們是怎么說的呢？
Matt Hamlin 的文章 useReducer, don"t useState 對這個問題進行了討論。在本文中，我們先來看下作者在他自己的項目中被問到的一個問題
我們來看看所謂的 Subscribe 組件的實現(xiàn)：
const [submitted, setSubmitted] = React.useState(false) const [loading, setLoading] = React.useState(false) const [response, setResponse] = React.useState(null) const [errorMessage, setErrorMessage] = React.useState(null)
是的，因為有了這么些狀態(tài)，就不免相應(yīng)的有很多調(diào)用狀態(tài)更新方法的地方：
async function handleSubmit(values) {
setSubmitted(false)
setLoading(true)
try {
const responseJson = await fetch(/* stuff */).then(r => r.json())
setSubmitted(true)
setResponse(responseJson)
setErrorMessage(null)
} catch (error) {
setSubmitted(false)
setErrorMessage("Something went wrong!")
}
setLoading(false)
}
可如果我們用 useReducer 重寫上面的邏輯，就會變成下面這樣：
const [state, dispatch] = React.useReducer(reducer, {
submitted: false,
loading: false,
response: null,
errorMessage: null,
})
而 reducer 的實現(xiàn)就像下面這樣：
const types = {
SUBMIT_STARTED: 0,
SUBMIT_COMPLETE: 1,
SUBMIT_ERROR: 2,
};
function reducer(state, action) {
switch (action.type) {
case types.SUBMIT_STARTED: {
return { ...state, submitted: false, loading: true };
}
case types.SUBMIT_COMPLETE: {
return {
...state,
submitted: true,
response: action.response,
errorMessage: null,
loading: false,
};
}
case types.SUBMIT_ERROR: {
return {
...state,
submitted: false,
errorMessage: action.errorMessage,
loading: false,
};
}
default: {
return state;
}
}
}
相應(yīng)的 handleSubmit 方法就可以調(diào)整為：
async function handleSubmit(values) {
dispatch({ type: types.SUBMIT_STARTED });
try {
const responseJson = await fetch(/* stuff */).then(r => r.json());
dispatch({ type: types.SUBMIT_COMPLETE, response: responseJson });
} catch (error) {
dispatch({ type: types.SUBMIT_ERROR, errorMessage: "Something went wrong!" });
}
}
Matt Hamlin 在他的文章中列舉了如下幾點來表明 useReducer 相比 useState 的優(yōu)越性：
更容易管理較大較復(fù)雜的狀態(tài)
更容易被其他開發(fā)者所理解
更容易測試
對于上面這種特定的例子，作者并不覺得第一條和第二條真的成立。只是 4 個狀態(tài)元素很難說就是個大的復(fù)雜的狀態(tài)，而且前后似乎也看不出有什么更容易理解。作者認為這兩種寫法是一樣的。
至于測試，作者表示絕對同意 reducer 更容易讀力測試，如果有很多業(yè)務(wù)邏輯，這確實是個很好的優(yōu)勢。
在作者看來，有一個原因他會更愿意使用 useState：
當我們并不確定一個組件的具體實現(xiàn)同時我們需要構(gòu)建這一組件的時候。
當我們構(gòu)建一個新的組件，我們經(jīng)常需要在組件的實現(xiàn)代碼中添加/刪除狀態(tài)。作者認為，面對這種情況，reducer 的寫法調(diào)整起來會更加麻煩。一旦你確定了你希望你的組件是什么樣的，你就可以決定是否從若干個 useState 的寫法轉(zhuǎn)換成一個 useReducer 來寫。此外，你也可以考慮使用 useReducer 來實現(xiàn)其中的一部分，并使用 useState 來實現(xiàn)其他部分的邏輯。作者認為，等到確定代碼究竟要調(diào)整成什么樣子時再開始抽象會更好一些。
總的來說，二者自然是兼具優(yōu)點與缺點的，具體還是得看要怎么用。結(jié)合我自己的實踐，我發(fā)覺文中的意思乍看有些廢話，但實際上是有道理的。在我使用 useState 寫完之后確定了邏輯，就會開始覺得 useState 的寫法有些凌亂，此時在已經(jīng)確定了各個狀態(tài)的情況下，再調(diào)整成 useReducer 就水到渠成了。
源地址：https://kentcdodds.com/blog/s...
關(guān)于 finally 的一些特殊場景今天我們來看下 finally 在一些特殊場景下的行為。
場景列舉 在 catch 中 throw如果我們在 catch 塊中拋出一個異常，且異常沒有相應(yīng)的 catch 來捕獲，會發(fā)生什么情況呢？
function example() {
try {
fail()
}
catch (e) {
console.log("Will finally run?")
throw e
}
finally {
console.log("FINALLY RUNS!")
}
console.log("This shouldn"t be called eh?")
}
example()
finally 會執(zhí)行，即使最后一句 console 并沒有。finally 是比較特殊的，它使得我們可以執(zhí)行在拋出異常和離開函數(shù)之間的東西，即使異常本身是在 catch 塊中拋出的。
沒有 catch 的情況如果沒有 catch，finally 又會有怎樣的行為呢？當然這一點一般都知道。
function example() {
try {
console.log("Hakuna matata")
}
finally {
console.log("What a wonderful phrase!")
}
}
example()
即使 try 中沒有錯誤，finally 仍然會執(zhí)行，這一點一般都是知道的。當然，如果有錯誤，那么 finally 也是會執(zhí)行的。也就是說，finally 會覆蓋這兩種情況，如下：
try 中 return 的 finally如果我們沒有出現(xiàn)錯誤，并且只是 return 了，會怎么執(zhí)行呢？
function example() {
try {
console.log("I"m picking up my ball and going home.")
return
}
finally {
console.log("Finally?")
}
}
example()
總結(jié)
finally 總會執(zhí)行，即使因為拋出異常或執(zhí)行 return 而提前結(jié)束。
這樣就讓其非常有用，當我們有無論如何都要執(zhí)行的東西時，放在 finally 就總是可以執(zhí)行，例如 cleanup 等等。
源地址：https://frontarm.com/james-k-...
TSLint in 2019Palantir 是 TSLint 的創(chuàng)建及主要維護團隊，而 TSLint 是 TypeScript 的標準 linter。由于 TypeScript 社區(qū)致力于統(tǒng)一 TypeScript 和 JavaScript 的開發(fā)體驗，因而作者他們支持 TSLint 和 ESLint 的融合工作。在這篇博文中，他們解釋了這樣做的原因并闡述了如何去做。
TSLint 與 ESLint 的現(xiàn)狀如今，TSLint 已經(jīng)是事實上的用 TypeScript 實現(xiàn)的項目和 TypeScript 自身實現(xiàn)的標準 linter。 TSLint 生態(tài)系統(tǒng)由核心規(guī)則集、社區(qū)維護的自定義規(guī)則和配置包組成。
與之相對的是，ESLint 是標準的 JavaScript linter。和 TSLint 一樣，它由核心規(guī)則集和社區(qū)維護的自定義規(guī)則組成。 ESLint 支持 TSLint 缺少的許多功能，例如條件 lint 配置和自動縮進。與之相對的是，ESLint 規(guī)則不能（至少現(xiàn)在不能）從 TypeScript 提供的靜態(tài)分析和類型推理中受益，因此無法捕獲 TSLint 語義規(guī)則所涵蓋的一類錯誤和代碼嗅探。
TypeScript + ESLintTypeScript 團隊的戰(zhàn)略方向（Roadmap）是為了實現(xiàn)「每家每戶每個 JavaScript 程序員都可以用上類型」，哈哈哈搞笑。換句話說，他們的方向是使用類型和靜態(tài)分析等 TypeScript 功能，漸進式的豐富 JavaScript 開發(fā)人員的體驗，直到 TypeScript 和 JavaScript 開發(fā)人員體驗融合統(tǒng)一為止。
很明顯，linting 是 TypeScript 和 JavaScript 開發(fā)人員使用體驗的一個核心部分，因此 Palantir 的 TSLint 團隊與 Redmond 的 TypeScript 核心團隊會面，討論 TypeScript / JavaScript 的融合之于 linting 的意義。TypeScript 社區(qū)旨在滿足 JavaScript 開發(fā)人員的需求，ESLint 是 JavaScript linting 的首選工具。我們計劃棄用 TSLint，集中精力為 ESLint 改進 TypeScript 支持。我們認為這是正確的前進道路，兼具戰(zhàn)略性和務(wù)實性：
降低使用門檻
JavaScript 開發(fā)人員遷移到 TypeScript 的障礙之一是從 ESLint 到 TSLint 的并不輕松的遷移。允許開發(fā)人員從他們現(xiàn)有的 ESLint 設(shè)置開始，逐步添加 TypeScript 特定的靜態(tài)分析可以減少這一障礙。
統(tǒng)一社區(qū)
ESLint 和 TSLint 共同的核心目標是：通過強大的核心規(guī)則集和大量插件提供出色的代碼 linting 體驗。現(xiàn)在，在 ESLint 中可以使用 TypeScript 解析，我們認為社區(qū)最好能夠做到標準化，而不是在競爭中維護不同的代碼。
性能更好的分析架構(gòu)
ESLint API 允許更有效地實現(xiàn)某些類檢查。雖然可以重構(gòu) TSLint 的 API，但是利用 ESLint 的架構(gòu)并將我們的開發(fā)資源集中在其他地方似乎是明智的。
下一步Palantir 將通過一系列功能和插件為 ESLint 的平滑過渡提供支持，并以此回饋 TSLint 社區(qū)。例如：
在 TypeScript 中使用 ESLint 規(guī)則的支持及文檔：issue。
typescript-eslint 的測試架構(gòu)：ESLint 內(nèi)置的檢查并不好用，且語法很難閱讀。我們想要帶來類似TSLint’s testing infrastructure 的東西以確保 TSLint 規(guī)則的開發(fā)體驗。
語義化的基于類型的檢查規(guī)則：移植并添加使用 TypeScript 語言服務(wù)的新規(guī)則。
一旦我們認為，ESLint 已經(jīng)參照 TSLint 完成了各個特性，我們就會廢棄 TSLint 并幫助用戶遷移到 ESLint。我們總結(jié)下目前的主要任務(wù)是：
繼續(xù) TSLint 的支持：最重要的維護任務(wù)是確保新的變異版本和特性的兼容性。
TSLint -> ESLint 兼容包：一旦 ESLint 的靜態(tài)分析檢查可以與 TSLint 相提并論，我們就會推出 eslint-config-palantir 包，一個插入式的替代 TSLint 規(guī)則的 ESLint 包。
源地址：https://medium.com/palantir/t...
Screenshot To Code從設(shè)計稿變前端代碼的故事已經(jīng)說了很久，而這兩天再次更新的 Screenshot To Code 是除了 pix2code 等之外的更讓人興奮的模型。
看看效果我們來看下整個三步走，首先是將設(shè)計稿傳入訓練好的網(wǎng)絡(luò)模型（圖中其實是在 Jupyter Notebook 里執(zhí)行 python 腳本）：
然后模型就會將圖片轉(zhuǎn)換成 HTML 標簽：
還是很騷的哈。最后渲染出來的靜態(tài)頁面如下，看上去效果很酷啊，不過我們也都知道，展示效果嘛。
簡單分析框架使用的還是 Keras，然后倉庫中提供了 HTML 和 Bootstrap 版本。具體核心邏輯可以參考這篇文章，筆者尚未深入研讀，這里就不秀了。
大致的意思是，HTML 標簽的輸出，是以一個標簽和 screenshoot 為輸入得到下一個標簽，然后再以已有的標簽再去推測后續(xù)的標簽。
這種思路是借鑒了一個 word 跟著一個 word 的預(yù)測，因此網(wǎng)絡(luò)模型中也大量用到了 LSTM。
還是可以再了解了解這塊東西的，晚點再深入讀來看看。
源地址：https://yuque.antfin-inc.com/...
優(yōu)化 React App 性能的 5 個建議本篇將從 render 角度來探討 5 個 React App 的優(yōu)化技巧。需要聲明的是，文中將涉及部分 React 16.8.2 的內(nèi)容，也就是說會有些 Hooks 相關(guān)內(nèi)容。當然，這不是全部，不過理解了 React Hooks 后食用效果更佳。
當我們討論 React App 的性能問題時，不可避免的就是要探討我們的組件渲染的有多快。在進入到具體優(yōu)化建議之前，我們先要理解以下 3 點：
當我們在說「渲染」時，我們在說什么？
什么時候會有「渲染」？
在「渲染」過程中會發(fā)生什么？
關(guān)于 render 函數(shù)這部分我們將從一種更簡單的方式來理解 reconciliation 和 diffing 的概念，當然文檔在這里。
哪個是 render 函數(shù)？這個問題其實寫過 React 的人都會知道，這里簡單說下：
在 class 組件中，指的是 render 方法：
class Foo extends React.Component {
render() {
return Foo
;
}
}
在函數(shù)式組件中，我們指的是函數(shù)組件本身：
function Foo() {
return Foo
;
}
render 什么時候會執(zhí)行？
render 函數(shù)會在兩種場景下被調(diào)用：
1. 狀態(tài)更新時import React from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
render() {
return {count}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
可以看到，代碼中的邏輯是我們點擊就會更新 count，到 10 以后，就會維持在 10。增加一個 console.log，這樣我們就可以知道 render 是否被調(diào)用了。
總結(jié)：繼承了 React.Component 的 class 組件，即使狀態(tài)沒變化，只要調(diào)用了setState 就會觸發(fā) render。
我們用函數(shù)實現(xiàn)相同的組件，當然因為要有狀態(tài)，我們用上了 useState hook：
import React, { useState } from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
render() {
return {count}
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
我們可以注意到，當狀態(tài)值不再改變之后，render 的調(diào)用就停止了。
總結(jié)：對函數(shù)式組件來說，狀態(tài)值改變時會觸發(fā) render 函數(shù)的調(diào)用。
2. 父容器重新渲染時import React from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
state = { name: "App" };
render() {
return (
Foo
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
只要點擊了 App 組件內(nèi)的 Change name 按鈕，就會重新 render。而且可以注意到，不管 Foo 具體實現(xiàn)是什么，F(xiàn)oo 都會被重新渲染。
總結(jié)：無論組件是繼承自 React.Component 的 class 組件還是函數(shù)式組件，只要父容器重新 render 了，組件的 render 都會被再次調(diào)用。
render 函數(shù)執(zhí)行時發(fā)生了什么？只要 render 函數(shù)被調(diào)用，就會有兩個步驟按順序執(zhí)行。這兩個步驟非常重要，理解了它們才好知道如何去優(yōu)化 React App。
Diffing在此步驟中，React 將新調(diào)用的 render 函數(shù)返回的樹與舊版本的樹進行比較，這一步是 React 決定如何更新 DOM 的必要步驟。雖然 React 使用高度優(yōu)化的算法執(zhí)行此步驟，但仍然需要付出一定性能開銷。
Reconciliation基于 diffing 的結(jié)果，React 更新 DOM 樹。這一步同樣要因為卸載和掛載 DOM nodes 帶來了許多的性能開銷。
Tip Tip #1：慎重分配 state 以避免不必要的 render 調(diào)用我們以下面的例子為例，其中 App 會渲染兩個組件：
CounterLabel，接收 count 值和一個增加父組件 App 中的狀態(tài) count 的值的方法。
List，接收 item 的列表。
import React, { useState } from "react";
import ReactDOM from "react-dom";
const ITEMS = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
function App() {
const [count, setCount] = useState(0);
const [items, setItems] = useState(ITEMS);
return (
setCount(count + 1)} />
);
}
function CounterLabel({ count, increment }) {
return (
<>
{count}
);
}
function List({ items }) {
console.log("List render");
return (
只要父組件 App 中的狀態(tài)被更新，CounterLabel 和 List 就都會更新。
當然，CounterLabel 重新渲染是正常的，因為 count 發(fā)生了變化，自然要重新渲染。但是對于 List 而言，就完全是不必要的更新了，因為它的渲染是獨立于 count 值的。盡管 React 并不會在 reconciliation 階段真的更新 DOM，畢竟完全沒變化，但是仍然會執(zhí)行 diffing 階段來對前后的樹進行對比，這仍然存在性能開銷。
還記得 render 執(zhí)行的 diffing 和 reconciliation 階段嗎？前面講過的東西在這里碰到了。
因此，為了避免不必要的 diffing 開銷，我們應(yīng)當考慮將特定的狀態(tài)值放到更低的層級或組件中（與 React 中所說的「提升」概念正好相反）。在這個例子中，我們就是要將 count 值放到 CounterLabel 組件中管理來解決這個問題。
Tip #2：合并狀態(tài)更新因為每次狀態(tài)更新都會觸發(fā)新的 render 調(diào)用，那么更少的狀態(tài)更新也就可以更少的調(diào)用 render 了。
我們知道，React class 組件有 componentDidUpdate(prevProps, prevState) 的鉤子，可以用來檢測 props 或 state 有沒有發(fā)生變化。盡管有時有必要在 props 發(fā)生變化時再觸發(fā) state 更新，但我們總可以避免在一次 state 變化后再進行一次 state 更新這種操作：
import React from "react";
import ReactDOM from "react-dom";
function getRange(limit) {
let range = [];
for (let i = 0; i < limit; i++) {
range.push(i);
}
return range;
}
class App extends React.Component {
state = {
numbers: getRange(7),
limit: 7
};
handleLimitChange = e => {
const limit = e.target.value;
const limitChanged = limit !== this.state.limit;
if (limitChanged) {
this.setState({ limit });
}
};
componentDidUpdate(prevProps, prevState) {
const limitChanged = prevState.limit !== this.state.limit;
if (limitChanged) {
this.setState({ numbers: getRange(this.state.limit) });
}
}
render() {
return (
{this.state.numbers.map((number, idx) => (
{number}
))}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
這里渲染了一個范圍的數(shù)字序列，范圍為 0 到 limit。只要用戶改變了 limit 值，我們就會在 componentDidUpdate 中進行檢測，并設(shè)定新的數(shù)字列表。
毫無疑問，上面的代碼是可以滿足需求的，但是，我們?nèi)匀豢梢赃M行優(yōu)化。
上面的代碼中，每次 limit 發(fā)生改變，我們都會觸發(fā)兩次狀態(tài)更新：第一次是為了修改 limit，第二次是為了修改展示的數(shù)字列表。這樣一來，每次 limit 的變化會帶來兩次 render 開銷：
// 初始狀態(tài)
{ limit: 7, numbers: [0, 1, 2, 3, 4, 5, 6]
// 更新 limit -> 4
render 1: { limit: 4, numbers: [0, 1, 2, 3, 4, 5, 6] } //
render 2: { limit: 4, numbers: [0, 2, 3]
我們的代碼邏輯帶來了下面的問題：
我們觸發(fā)了比實際需要更多的狀態(tài)更新；
我們出現(xiàn)了「不連續(xù)」的渲染結(jié)果，數(shù)字列表與 limit 不匹配。
為了改進，我們應(yīng)避免在不同的狀態(tài)更新中改變數(shù)字列表。事實上，我們可以在一次狀態(tài)更新中搞定：
import React from "react";
import ReactDOM from "react-dom";
function getRange(limit) {
let range = [];
for (let i = 0; i < limit; i++) {
range.push(i);
}
return range;
}
class App extends React.Component {
state = {
numbers: [1, 2, 3, 4, 5, 6],
limit: 7
};
handleLimitChange = e => {
const limit = e.target.value;
const limitChanged = limit !== this.state.limit;
if (limitChanged) {
this.setState({ limit, numbers: getRange(limit) });
}
};
render() {
return (
{this.state.numbers.map((number, idx) => (
{number}
))}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
Tip #3：使用 PureComponent 和 React.memo 以避免不必要的 render 調(diào)用
我們在之前的例子中看到將特定狀態(tài)值放到更低的層級來避免不必要渲染的方法，不過這并不總是有用。
我們來看下下面的例子：
import React, { useState } from "react";
import ReactDOM from "react-dom";
function App() {
const [isFooVisible, setFooVisibility] = useState(false);
return (
{isFooVisible ? (
setFooVisibility(false)} />
) : (
)}
);
}
function Foo({ hideFoo }) {
return (
<>
Foo
);
}
function Bar({ name }) {
return {name}
;
}
const rootElement = document.getElementById("root");
ReactDOM.render(
可以看到，只要父組件 App 的狀態(tài)值 isFooVisible 發(fā)生變化，F(xiàn)oo 和 Bar 就都會被重新渲染。
這里因為需要決定 Foo 是否要被渲染出來，我們需要將 isFooVisible 放在 App中維護，因此也就不能將狀態(tài)拆除放到更低的層級。不過，在 isFooVisible 發(fā)生變化時重新渲染 Bar 仍然是不必要的，因為 Bar 并不依賴 isFooVisible。我們只希望 Bar 在傳入屬性 name 變化時重新渲染。
那我們該怎么搞呢？兩種方法。
其一，對 Bar 做記憶化（memoize）：
const Bar = React.memo(function Bar({name}) {
return {name}
;
});
這就能保證 Bar 只在 name 發(fā)生變化時才重新渲染。
此外，另一個方法就是讓 Bar 繼承 React.PureComponent 而非 React.Component：
class Bar extends React.PureComponent {
render() {
return {name}
;
}
}
是不是很熟悉？我們經(jīng)常提到使用 React.PureComponent 能帶來一定的性能提升，避免不必要的 render。
總結(jié)：避免組件不必要的渲染的方法有：React.memo 包起來的函數(shù)式組件，繼承自 React.PureComponent 的 class 組件。
為什么不讓每個組件都繼承 PureComponent 或者用 memo 包呢？如果這條建議可以讓我們避免不必要的重新渲染，那我們?yōu)槭裁床话衙總€ class 組件變成 PureComponent、把每個函數(shù)式組件用 React.memo 包起來？為什么有了更好的方法還要有 React.Component 呢？為什么函數(shù)式組件不默認記憶化呢？
毫無疑問，這些方法并不總是萬靈藥呀。
我們先來考慮下 PureComponent 和 React.memo 的組件到底做了什么？
每次更新的時候（包括狀態(tài)更新或上層組件重新渲染），它們就會在新 props、state 和舊 props、state 之間對 key 和 value 進行淺比較。淺比較是個嚴格相等的檢查，如果檢測到差異，render 就會執(zhí)行：
// 基本類型的比較
shallowCompare({ name: "bar"}, { name: "bar"}); // output: true
shallowCompare({ name: "bar"}, { name: "bar1"}); // output: false
盡管對于基本類型（如字符串、數(shù)字、布爾）的比較工作的很好，如對象這類復(fù)雜的值可能就會帶來意想不到的行為：
shallowCompare({ name: {first: "John", last: "Schilling"}},
{ name: {first: "John", last: "Schilling"}}); // output: false
上述兩個 name 對象的引用是不同的。
我們重新看下之前的例子，然后修改我們傳入 Bar 的 props：
import React, { useState } from "react";
import ReactDOM from "react-dom";
const Bar = React.memo(function Bar({ name: { first, last } }) {
console.log("Bar render");
return (
{first} {last}
);
});
function Foo({ hideFoo }) {
return (
<>
Foo
);
}
function App() {
const [isFooVisible, setFooVisibility] = useState(false);
return (
{isFooVisible ? (
setFooVisibility(false)} />
) : (
)}
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
盡管 Bar 做了記憶化且 props 值并沒有發(fā)生變動，每次父組件重新渲染時它仍然會重新渲染。這是因為每次比較的兩個對象盡管擁有相同的值，卻因為淺比較的引用不同觸發(fā)重新渲染。
我們也可以把函數(shù)作為屬性向組件傳遞，當然，在 JavaScript 中函數(shù)也是傳遞的引用，因此淺比較也是基于其傳遞的引用。
因此，如果我們傳遞的是箭頭函數(shù)（匿名函數(shù)），組件仍然會在父組件重新渲染時重新渲染。
Tip #4：更好的 props 寫法前面的問題的一種解決方法是改寫我們的 props。
我們不傳遞對象作為 props，而是將對象拆分成基本類型：
而對于傳遞箭頭函數(shù)的場景，我們可以代以只唯一聲明過一次的函數(shù)，從而總可以拿到相同的引用，如下所示：
class App extends React.Component{
constructor(props) {
this.doSomethingMethod = this.doSomethingMethod.bind(this);
}
doSomethingMethod () { // do something}
render() {
return
Tip #5：控制更新
還是那句話，任何方法總有其適用范圍。
第三條建議雖然處理了不必要的更新問題，但我們也不總能使用它。
而第四條，在某些情況下我們并不能拆分對象，如果我們傳遞了某種嵌套確實復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，那我們也很難將其拆分開來。
不僅如此，我們并不總能傳遞只聲明了一次的函數(shù)。比如在我們的例子中，如果 App 是個函數(shù)式組件，恐怕就不能做到這一點了（在 class 組件中，我們可以用 bind 或者類內(nèi)箭頭函數(shù)來保證 this 的指向及唯一聲明，而在函數(shù)式組件中則可能會導(dǎo)致一些問題）。
幸運的是，無論是 class 組件還是函數(shù)式組件，我們都有辦法控制淺比較的邏輯。
在 class 組件中，我們可以使用生命周期鉤子 shouldComponentUpdate(prevProps, prevState) 來返回一個布爾值，當返回值為 true 時才會觸發(fā) render。
而如果我們使用 React.memo，我們可以傳遞一個比較函數(shù)作為第二個參數(shù)。
注意！React.memo 的第二參數(shù)（比較函數(shù)）和 shouldComponentUpdate 的邏輯是相反的，只有當返回值為 false 的時候才會觸發(fā) render。參考文檔。
const Bar = React.memo(
function Bar({ name: { first, last } }) {
console.log("update");
return (
{first} {last}
);
},
(prevProps, newProps) =>
prevProps.name.first === newProps.name.first &&
prevProps.name.last === newProps.name.last
);
盡管這條建議是可行的，但我們?nèi)砸⒁?strong>比較函數(shù)的性能開銷。如果 props 對象過深，反而會消耗不少的性能。
總結(jié)上述場景仍不夠全面，但多少能帶來一些啟發(fā)性思考。當然我們還有許多其他的問題需要考慮，但遵守上述的準則仍能帶來相當不錯的性能提升。
源地址：https://medium.com/@siffogh3/...
禁用大體積依賴的 importAddy Osmani 大佬推薦了一個 ESLint 的方法來達成這一效果。
有時候我們可能在團隊的項目中禁用大體積依賴包的引入，而這一點我們可以借助 ESLint 來指定項目中不引用特定的依賴來做到，也即 no-restricted-modules 規(guī)則。
如下的例子展示的是禁用 moment.js 的引入（這類體積大的直接引用的話肯定就爆了，不過我們也常常會考慮按需加載）。這條規(guī)則也支持自定義提示信息，所以錯誤提示可以建議大家使用小一些的包來代替，如 date-fns、Luxon 等。
{
"rules": {
"no-restricted-imports": ["error", {
"paths": [{
"name": "moment",
"message": "Use date-fns or Luxon instead!"
}]
}]
}
}
這樣一來，當團隊中有人嘗試著如下寫法，就會報錯：
import moment from "moment";
另一個例子是禁用 lodash：
{
"rules": {
"no-restricted-imports": ["error", {
"name": "lodash",
"message": "Use lodash-es instead!",
}],
}
}
當然，我們也可以不適用錯誤提示，一個數(shù)組搞定：
{
"rules": {
"no-restricted-imports": ["error", "underscore", "bluebird"]
}
}
當然，還有一些高級用法，no-restricted-modules 還支持類似 .gitignore 風格的模式。例如，如果有人嘗試著引入匹配了 legacy/* 模式的包，我們就會報錯，如 import helpers from "legacy/helpers"; 這種：
{
"rules": {
"no-restricted-imports": ["error", {
"patterns": ["legacy/*"]
}],
}
}
源地址：https://addyosmani.com/blog/d...
理解 TS 類型注解這篇文章來自 Dr. Axel Rauschmayer 的博客，對 TypeScript 的靜態(tài)類型注解進行了梳理。今天來學習下。
1. 我們會學到什么在讀完本篇文章后，我們應(yīng)該能夠理解下面這段代碼的含義：
