React Hooks 完全指南，读React作者博文感悟（2W字精华）

运行

() => { document.title = 'You clicked 0 times' }

。

现在我们回顾一下我们点击之后发生了什么：

• 你的组件: 喂 React, 把我的状态设置为

  1

  。
• React: 给我状态为

  1

  时候的UI。
• 你的组件: 给你需要渲染的内容:

  <span> You clicked 1 times</span>

  。
• 记得在渲染完了之后调用这个effect：

  () => { document.title = 'You clicked 1 times' }

  。

运行

() => { document.title = 'You clicked 1 times' }

。

每一次渲染都有它自己的...所有

我们现在知道effects会在每次渲染后运行，并且概念上它是组件输出的一部分，可以"看到"属于某次特定渲染的props和state。

我们来做一个思想实验，思考下面的代码：

function Counter() {
const [count, setCount] = useState(0);

useEffect(() => {    setTimeout(() => {      console.log(`You clicked ${count} times`);    }, 3000);  });
return (
<div>
<p>You clicked {count} times</p>
<button onClick={() => setCount(count + 1)}>
Click me
</button>
</div>
);
}

如果我点击了很多次并且在effect里设置了延时，打印出来的结果会是什么呢？

你可能会认为这是一个很绕的题并且结果是反直觉的。完全错了！我们看到的就是顺序的打印输出 — 每一个都属于某次特定的渲染，因此有它该有的

count

不过，class中的

this.state

this.state.count

5

我觉得Hooks这么依赖Javascript闭包是挺讽刺的一件事。有时候组件的class实现方式会受闭包相关的苦（the canonical wrong-value-in-a-timeout confusion），但其实这个例子中真正的混乱来源是可变数据（React 修改了class中的

this.state

当封闭的值始终不会变的情况下闭包是非常棒的。这使它们非常容易思考因为你本质上在引用常量。正如我们所讨论的，props和state在某个特定渲染中是不会改变的。顺便说一下，我们可以使用闭包修复上面的class版本...

逆潮而动

到目前为止，我们可以明确地喊出下面重要的事实： 每一个组件内的函数（包括事件处理函数，effects，定时器或者API调用等等）会捕获某次渲染中定义的props和state。

所以下面的两个例子是相等的：

function Example(props) {
useEffect(() => {
setTimeout(() => {
console.log(props.counter);
}, 1000);
});

}

function Example(props) {
const counter = props.counter;
useEffect(() => {
setTimeout(() => {
console.log(counter);
}, 1000);
});

}

在组件内什么时候去读取props或者state是无关紧要的。因为它们不会改变。在单次渲染的范围内，props和state始终保持不变。（解构赋值的props使得这一点更明显。）

当然，有时候你可能想在effect的回调函数里读取最新的值而不是捕获的值。最简单的实现方法是使用refs，这篇文章的最后一部分介绍了相关内容。

需要注意的是当你想要从 过去 渲染中的函数里读取 未来 的props和state，你是在逆潮而动。虽然它并没有 错（有时候可能也需要这样做），但它因为打破了默认范式会使代码显得不够"干净"。这是我们有意为之的，因为它能帮助突出哪些代码是脆弱的，是需要依赖时间次序的。在class中，如果发生这种情况就没那么显而易见了。

下面这个计数器版本 模拟了class中的行为：

function Example() {
const [count, setCount] = useState(0);
const latestCount = useRef(count);
useEffect(() => {
latestCount.current = count;
setTimeout(() => {
console.log(`You clicked ${latestCount.current} times`);
}, 3000);
});
}

在React中去直接修改值看上去有点怪异。然而，在class组件中React正是这样去修改

this.state

latestCount.current

那Effect中的清理又是怎样的呢？

像 文档中解释的, 有些 effects 可能需要有一个清理步骤。本质上，它的目的是消除副作用（effect)，比如取消订阅。

思考下面的代码:

useEffect(() => {
ChatAPI.subscribeToFriendStatus(props.id, handleStatusChange);
return () => {
ChatAPI.unsubscribeFromFriendStatus(props.id, handleStatusChange);
};
});

假设第一次渲染的时候

props

{id: 10}

{id: 20}

React只会在浏览器绘制后运行effects。这使得你的应用更流畅因为大多数effects并不会阻塞屏幕的更新。Effect的清除同样被延迟了。 上一次的effect会在重新渲染后被清除：

• React 渲染

  {id: 20}

  的UI。
• 浏览器绘制。我们在屏幕上看到

  {id: 20}

  的UI。
• React 清除

  {id: 10}

  的effect。
• React 运行

  {id: 20}

  的effect。

你可能会好奇：如果清除上一次的effect发生在props变成

{id: 20}

{id: 10}

引用上半部分得到的结论:

现在答案显而易见。effect的清除并不会读取"最新"的props。它只能读取到定义它的那次渲染中的props值：

同步， 而非生命周期

我最喜欢React的一点是它统一描述了初始渲染和之后的更新。这降低了你程序的熵。

比如我有个组件像下面这样：

function Greeting({ name }) {
return (
<h1 className="Greeting">
Hello, {name}
</h1>
);
}

我先渲染

<greeting name="Dan"></greeting>

<greeting name="Yuzhi"></greeting>

<greeting name="Yuzhi"></greeting>

人们总是说："重要的是旅行过程，而不是目的地"。在React世界中，恰好相反。 重要的是目的，而不是过程。这就是JQuery代码中

$.addClass

$.removeClass

React会根据我们当前的props和state同步到DOM。"mount"和"update"之于渲染并没有什么区别。

你应该以相同的方式去思考effects。 **

useEffect

function Greeting({ name }) {
useEffect(() => {    document.title = 'Hello, ' + name;  });  return (
<h1 className="Greeting">
Hello, {name}
</h1>
);
}

这就是和大家熟知的 _mount/update/unmount_心智模型之间细微的区别。理解和内化这种区别是非常重要的。 如果你试图写一个effect会根据是否第一次渲染而表现不一致，你正在逆潮而动。如果我们的结果依赖于过程而不是目的，我们会在同步中犯错。

先渲染属性A，B再渲染C，和立即渲染C并没有什么区别。虽然他们可能短暂地会有点不同（比如请求数据时），但最终的结果是一样的。

不过话说回来，在 _每一次_渲染后都去运行所有的effects可能并不高效。（并且在某些场景下，它可能会导致无限循环。）

所以我们该怎么解决这个问题？

告诉React去比对你的Effects

其实我们已经从React处理DOM的方式中学习到了解决办法。React只会更新DOM真正发生改变的部分，而不是每次渲染都大动干戈。

当你把

<h1 className="Greeting">
Hello, Dan
</h1>

更新到

<h1 className="Greeting">
Hello, Yuzhi
</h1>

React 能够看到两个对象:

const oldProps = {className: 'Greeting', children: 'Hello, Dan'};
const newProps = {className: 'Greeting', children: 'Hello, Yuzhi'};

它会检测每一个props，并且发现

children

className

domNode.innerText = 'Hello, Yuzhi';

我们也可以用类似的方式处理effects吗？如果能够在不需要的时候避免调用effect就太好了。

举个例子，我们的组件可能因为状态变更而重新渲染：

function Greeting({ name }) {
const [counter, setCounter] = useState(0);

useEffect(() => {
document.title = 'Hello, ' + name;
});

return (
<h1 className="Greeting">
Hello, {name}
<button onClick={() => setCounter(counter + 1)}>Increment</button>
</h1>
);
}

但是我们的effect并没有使用

counter

name

document.title

name

document.title

好了，那React可以...区分effects的不同吗？

let oldEffect = () => { document.title = 'Hello, Dan'; };
let newEffect = () => { document.title = 'Hello, Dan'; };

并不能。React并不能猜测到函数做了什么如果不先调用的话。（源码中并没有包含特殊的值，它仅仅是引用了

name

这是为什么你如果想要避免effects不必要的重复调用，你可以提供给

useEffect

useEffect(() => {
document.title = 'Hello, ' + name;
}, [name]);

这好比你告诉React："Hey，我知道你看不到这个函数里的东西，但我可以保证只使用了渲染中的

name

如果当前渲染中的这些依赖项和上一次运行这个effect的时候值一样，因为没有什么需要同步React会自动跳过这次effect：

const oldEffect = () => { document.title = 'Hello, Dan'; };
const oldDeps = ['Dan'];

const newEffect = () => { document.title = 'Hello, Dan'; };
const newDeps = ['Dan'];

即使依赖数组中只有一个值在两次渲染中不一样，我们也不能跳过effect的运行。要同步所有！

关于依赖项不要对React撒谎

关于依赖项对React撒谎会有不好的结果。直觉上，这很好理解，但我曾看到几乎所有依赖class心智模型使用

useEffect

function SearchResults() {
async function fetchData() {

}

useEffect(() => {
fetchData();
}, []);

}

(官网的Hooks FAQ 解释了应该怎么做。 我们在下面 会重新回顾这个例子。)

"但我只是想在挂载的时候运行它！"，你可能会说。现在只需要记住：如果你设置了依赖项， effect中用到的所有组件内的值都要包含在依赖中。这包括props，state，函数 — 组件内的任何东西。

有时候你是这样做了，但可能会引起一个问题。比如，你可能会遇到无限请求的问题，或者socket被频繁创建的问题。 解决问题的方法不是移除依赖项。我们会很快了解具体的解决方案。

不过在我们深入解决方案之前，我们先尝试更好地理解问题。

如果设置了错误的依赖会怎么样呢？

如果依赖项包含了所有effect中使用到的值，React就能知道何时需要运行它：

useEffect(() => {
document.title = 'Hello, ' + name;
}, [name]);

(依赖发生了变更，所以会重新运行effect。)

但是如果我们将

[]

useEffect(() => {
document.title = 'Hello, ' + name;
}, []);

(依赖没有变，所以不会再次运行effect。)

在这个例子中，问题看起来显而易见。但在某些情况下如果你脑子里"跳出"class组件的解决办法，你的直觉很可能会欺骗你。

举个例子，我们来写一个每秒递增的计数器。在Class组件中，我们的直觉是："开启一次定时器，清除也是一次"。这里有一个例子说明怎么实现它。当我们理所当然地把它用

useEffect

[]

function Counter() {
const [count, setCount] = useState(0);

useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, []);
return <h1>{count}h1>;
}

然而，这个例子只会递增一次。 天了噜。

如果你的心智模型是"只有当我想重新触发effect的时候才需要去设置依赖"，这个例子可能会让你产生存在危机。你想要触发一次因为它是定时器 — 但为什么会有问题？

如果你知道依赖是我们给React的暗示，告诉它effect所有需要使用的渲染中的值，你就不会吃惊了。effect中使用了

count

在第一次渲染中，

count

0

setCount(count + 1)

setCount(0 + 1)

[]

setCount(0 + 1)

function Counter() {
useEffect(
() => {
const id = setInterval(() => {
setCount(0 + 1);
}, 1000);
return () => clearInterval(id);
},
[]
);
}

function Counter() {
useEffect(
() => {
const id = setInterval(() => {
setCount(1 + 1);
}, 1000);
return () => clearInterval(id);
},
[]
);

}

我们对React撒谎说我们的effect不依赖组件内的任何值，可实际上我们的effect有依赖！

我们的effect依赖

count

const count = //...

useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, []);

因此，设置

[]

(依赖没有变，所以不会再次运行effect。)

类似于这样的问题是很难被想到的。因此，我鼓励你将诚实地告知effect依赖作为一条硬性规则，并且要列出所以依赖。（我们提供了一个lint规则如果你想在你的团队内做硬性规定。）

两种诚实告知依赖的方法

有两种诚实告知依赖的策略。你应该从第一种开始，然后在需要的时候应用第二种。

第一种策略是在依赖中包含所有effect中用到的组件内的值。让我们在依赖中包含

count

useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, [count]);

现在依赖数组正确了。虽然它可能不是 _太理想_但确实解决了上面的问题。现在，每次

count

setCount(count + 1)

count

function Counter() {

useEffect(
() => {
const id = setInterval(() => {
setCount(0 + 1);
}, 1000);
return () => clearInterval(id);
},
[0]
);

}

function Counter() {
useEffect(
() => {
const id = setInterval(() => {
setCount(1 + 1);
}, 1000);
return () => clearInterval(id);
},
[1]   );

}

这能解决问题但是我们的定时器会在每一次

count

(依赖发生了变更，所以会重新运行effect。)

第二种策略是修改effect内部的代码以确保它包含的值只会在需要的时候发生变更。我们不想告知错误的依赖 - 我们只是修改effect使得依赖更少。

让我们来看一些移除依赖的常用技巧。

我们想去掉effect的

count

useEffect(() => {
const id = setInterval(() => {
setCount(count + 1);
}, 1000);
return () => clearInterval(id);
}, [count]);

为了实现这个目的，我们需要问自己一个问题： 我们为什么要用

count

setCount

count

count

setState

useEffect(() => {
const id = setInterval(() => {
setCount(c => c + 1);
}, 1000);
return () => clearInterval(id);
}, []);

我喜欢把类似这种情况称为"错误的依赖"。是的，因为我们在effect中写了

setCount(count + 1)

count

count

count+1

count

这正是

setCount(c => c + 1)

注意我们做到了移除依赖，并且没有撒谎。我们的effect不再读取渲染中的

count

(依赖没有变，所以不会再次运行effect。)

你可以自己 试试。

尽管effect只运行了一次，第一次渲染中的定时器回调函数可以完美地在每次触发的时候给React发送

c => c + 1

count

函数式更新 和 Google Docs

还记得我们说过同步才是理解effects的心智模型吗？同步的一个有趣地方在于你通常想要把同步的"信息"和状态解耦。举个例子，当你在Google Docs编辑文档的时候，Google并不会把整篇文章发送给服务器。那样做会非常低效。相反的，它只是把你的修改以一种形式发送给服务端。

虽然我们effect的情况不尽相同，但可以应用类似的思想。 只在effects中传递最小的信息会很有帮助。 类似于

setCount(c => c + 1)

setCount(count + 1)

表达 意图（而不是结果）和Google Docs 如何处理共同编辑异曲同工。虽然这个类比略微延伸了一点，函数式更新在React中扮演了类似的角色。它们确保能以批量地和可预测的方式来处理各种源头（事件处理函数，effect中的订阅，等等）的状态更新。

然而，即使是

setCount(c => c + 1)

setCount(c => c + 1)

useReducer

解耦来自Actions的更新

我们来修改上面的例子让它包含两个状态：

count

step

step

function Counter() {
const [count, setCount] = useState(0);
const [step, setStep] = useState(1);

useEffect(() => {
const id = setInterval(() => {
setCount(c => c + step);
}, 1000);
return () => clearInterval(id);
}, [step]);
return (
<>
<h1>{count}</h1>
<input value={step} onChange={e => setStep(Number(e.target.value))} />
</>
);
}

(这里是demo.)

注意 我们没有撒谎。既然我们在effect里使用了

step

这个例子目前的行为是修改

step

不过，假如我们不想在

step

step

当你想更新一个状态，并且这个状态更新依赖于另一个状态的值时，你可能需要用

useReducer

当你写类似

setSomething(something => ...)

我们用一个

dispatch

step

const initialState = {
count: 0,
step: 1,
};

function reducer(state, action) {
const { count, step } = state;
if (action.type === 'tick') {
return { count: count + step, step };
} else if (action.type === 'step') {
return { count, step: action.step };
} else {
throw new Error();
}
}

const [state, dispatch] = useReducer(reducer, initialState);
const { count, step } = state;

useEffect(() => {
const id = setInterval(() => {
dispatch({ type: 'tick' });
}, 1000);
return () => clearInterval(id);
}, [dispatch]);

(查看 demo。)

你可能会问："这怎么就更好了？"答案是 React会保证

dispatch

我们解决了问题!

（你可以从依赖中去除

dispatch

setState

useRef

相比于直接在effect里面读取状态，它dispatch了一个 _action_来描述发生了什么。这使得我们的effect和

step

(这里是demo 如果你之前错过了。)

为什么useReducer是Hooks的作弊模式

我们已经学习到如何移除effect的依赖，不管状态更新是依赖上一个状态还是依赖另一个状态。 但假如我们需要依赖 props 去计算下一个状态呢？举个例子，也许我们的API是

<counter step="{1}"></counter>

props.step

实际上， 我们可以避免！我们可以把 _reducer_函数放到组件内去读取props：

function Counter({ step }) {
const [count, dispatch] = useReducer(reducer, 0);

function reducer(state, action) {
if (action.type === 'tick') {
return state + step;
} else {
throw new Error();
}
}

useEffect(() => {
const id = setInterval(() => {
dispatch({ type: 'tick' });
}, 1000);
return () => clearInterval(id);
}, [dispatch]);

return <h1>{count}</h1>;
}

这种模式会使一些优化失效，所以你应该避免滥用它，不过如果你需要你完全可以在reducer里面访问props。（这里是demo。）

即使是在这个例子中，React也保证

dispatch

你可能会疑惑：这怎么可能？在之前渲染中调用的reducer怎么"知道"新的props？答案是当你

dispatch

这就是为什么我倾向认为

useReducer

把函数移到Effects里

一个典型的误解是认为函数不应该成为依赖。举个例子，下面的代码看上去可以运行正常：

function SearchResults() {
const [data, setData] = useState({ hits: [] });

async function fetchData() {
const result = await axios(
'https://hn.algolia.com/api/v1/search?query=react',
);
setData(result.data);
}

useEffect(() => {
fetchData();
}, []);

(这个例子 改编自Robin Wieruch这篇很棒的文章 —点击查看 ！)

需要明确的是，上面的代码可以正常工作。 但这样做在组件日渐复杂的迭代过程中我们很难确保它在各种情况下还能正常运行。

想象一下我们的代码做下面这样的分离，并且每一个函数的体量是现在的五倍，然后我们在某些函数内使用了某些state或者prop：

function SearchResults() {
const [query, setQuery] = useState('react');

function getFetchUrl() {
return 'https://hn.algolia.com/api/v1/search?query=' + query;  }

async function fetchData() {
const result = await axios(getFetchUrl());
setData(result.data);
}

useEffect(() => {
fetchData();
}, []);

}

如果我们忘记去更新使用这些函数（很可能通过其他函数调用）的effects的依赖，我们的effects就不会同步props和state带来的变更。这当然不是我们想要的。

幸运的是，对于这个问题有一个简单的解决方案。 如果某些函数仅在effect中调用，你可以把它们的定义移到effect中：

function SearchResults() {

useEffect(() => {
function getFetchUrl() {
return 'https://hn.algolia.com/api/v1/search?query=react';
}
async function fetchData()
const result = await axios(getFetchUrl());
setData(result.data);
}
fetchData();
}, []);

}

(这里是demo.)

这么做有什么好处呢？我们不再需要去考虑这些"间接依赖"。我们的依赖数组也不再撒谎： 在我们的effect中确实没有再使用组件范围内的任何东西。

如果我们后面修改

getFetchUrl

query

query

function SearchResults() {
const [query, setQuery] = useState('react');

useEffect(() => {
function getFetchUrl() {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}

async function fetchData() {
const result = await axios(getFetchUrl());
setData(result.data);
}

fetchData();
}, [query]);

}

(这里是demo.)

添加这个依赖，我们不仅仅是在"取悦React"。在query改变后去重新请求数据是合理的。

useEffect

感谢

eslint-plugin-react-hooks

exhaustive-deps

非常棒。

但我不能把这个函数放到Effect里

有时候你可能不想把函数移入effect里。比如，组件内有几个effect使用了相同的函数，你不想在每个effect里复制黏贴一遍这个逻辑。也或许这个函数是一个prop。

在这种情况下你应该忽略对函数的依赖吗？我不这么认为。再次强调， effects不应该对它的依赖撒谎。通常我们还有更好的解决办法。一个常见的误解是，"函数从来不会改变"。但是这篇文章你读到现在，你知道这显然不是事实。实际上，在组件内定义的函数每一次渲染都在变。

函数每次渲染都会改变这个事实本身就是个问题。 比如有两个effects会调用

getFetchUrl

function SearchResults() {
function getFetchUrl(query) {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}

useEffect(() => {
const url = getFetchUrl('react');
}, []);

useEffect(() => {
const url = getFetchUrl('redux');
}, []);

}

在这个例子中，你可能不想把

getFetchUrl

另一方面，如果你对依赖很"诚实"，你可能会掉到陷阱里。我们的两个effects都依赖

getFetchUrl

function SearchResults() {
function getFetchUrl(query) {    return 'https://hn.algolia.com/api/v1/search?query=' + query;  }
useEffect(() => {
const url = getFetchUrl('react');

}, [getFetchUrl]);

useEffect(() => {
const url = getFetchUrl('redux');

}, [getFetchUrl]);

}

一个可能的解决办法是把

getFetchUrl

相反的，我们有两个更简单的解决办法。

第一个， 如果一个函数没有使用组件内的任何值，你应该把它提到组件外面去定义，然后就可以自由地在effects中使用：

function getFetchUrl(query) {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}
function SearchResults() {
useEffect(() => {
const url = getFetchUrl('react');
}, []);

useEffect(() => {
const url = getFetchUrl('redux');
}, []);

}

你不再需要把它设为依赖，因为它们不在渲染范围内，因此不会被数据流影响。它不可能突然意外地依赖于props或state。

或者， 你也可以把它包装成

useCallback

function SearchResults() {
const getFetchUrl = useCallback((query) => {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}, []);

useEffect(() => {
const url = getFetchUrl('react');
}, [getFetchUrl]);

useEffect(() => {
const url = getFetchUrl('redux');
}, [getFetchUrl]);

}

useCallback

我们来看看为什么这种方式是有用的。之前，我们的例子中展示了两种搜索结果（查询条件分别为

'react'

'redux'

query

query

getFetchUrl

我们很快发现它遗漏了

query

function SearchResults() {
const [query, setQuery] = useState('react');
const getFetchUrl = useCallback(() => {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}, []);
}

如果我把

query

useCallback

getFetchUrl

query

function SearchResults() {
const [query, setQuery] = useState('react');

const getFetchUrl = useCallback(() => {
return 'https://hn.algolia.com/api/v1/search?query=' + query;
}, [query]);

useEffect(() => {
const url = getFetchUrl();
}, [getFetchUrl]);

}

我们要感谢

useCallback

query

getFetchUrl

query

getFetchUrl

这正是拥抱数据流和同步思维的结果。 对于通过属性从父组件传入的函数这个方法也适用：

function Parent() {
const [query, setQuery] = useState('react');

const fetchData = useCallback(() => {
const url = 'https://hn.algolia.com/api/v1/search?query=' + query;
}, [query]);
return <Child fetchData={fetchData} />
}

function Child({ fetchData }) {
let [data, setData] = useState(null);

useEffect(() => {
fetchData().then(setData);
}, [fetchData]);

}

因为

fetchData

Parent

query

Child

函数是数据流的一部分吗？

有趣的是，这种模式在class组件中行不通，并且这种行不通恰到好处地揭示了effect和生命周期范式之间的区别。考虑下面的转换：

class Parent extends Component {
state = {
query: 'react'
};

fetchData = () => {
const url = 'https://hn.algolia.com/api/v1/search?query=' + this.state.query;
};

render() {
return <Child fetchData={this.fetchData} />;
}
}

class Child extends Component {
state = {
data: null
};
componentDidMount() {
this.props.fetchData();
}
render() {
}
}

你可能会想："少来了Dan，我们都知道

useEffect

componentDidMount

componentDidUpdate

componentDidUpdate

class Child extends Component {
state = {
data: null
};

componentDidMount() {
this.props.fetchData();
}

componentDidUpdate(prevProps) {
if (this.props.fetchData !== prevProps.fetchData) {
this.props.fetchData();
}
}

render() {
}
}

当然如此，

fetchData

this.props.fetchData

prevProps.fetchData

componentDidUpdate(prevProps) {
this.props.fetchData();
}

等等，这样会在每次渲染后都去请求。(添加一个加载动画可能是一种有趣的发现这种情况的方式。)也许我们可以绑定一个特定的query?

render() {
return <Child fetchData={this.fetchData.bind(this, this.state.query)} />;
}

但这样一来，

this.props.fetchData !== prevProps.fetchData

true

query

想要解决这个class组件中的难题，唯一现实可行的办法是硬着头皮把

query

Child

Child

query

class Parent extends Component {
state = {
query: 'react'
};
fetchData = () => {
const url = 'https://hn.algolia.com/api/v1/search?query=' + this.state.query;
};
render() {
return <Child fetchData={this.fetchData} query={this.state.query} />;  }
}

class Child extends Component {
state = {
data: null
};
componentDidMount() {
this.props.fetchData();
}
componentDidUpdate(prevProps) {
if (this.props.query !== prevProps.query) {
this.props.fetchData();
}
}
render() {
}
}

在使用React的class组件这么多年后，我已经如此习惯于把不必要的props传递下去并且破坏父组件的封装以至于我在一周之前才意识到我为什么一定要这样做。

在class组件中，函数属性本身并不是数据流的一部分。组件的方法中包含了可变的

this

this.props.fetchData

使用

useCallback

useCallback

props.fetchData

类似的，

useMemo

function ColorPicker() {

const [color, setColor] = useState('pink');
const style = useMemo(() => ({ color }), [color]);
return <Child style={style} />;
}

我想强调的是，到处使用

useCallback

useCallback

在上面的例子中，我更倾向于把

fetchData

props.onComplete

说说竞态

下面是一个典型的在class组件里发请求的例子：

class Article extends Component {
state = {
article: null
};
componentDidMount() {
this.fetchData(this.props.id);
}
async fetchData(id) {
const article = await API.fetchArticle(id);
this.setState({ article });
}

}

你很可能已经知道，上面的代码埋伏了一些问题。它并没有处理更新的情况。所以第二个你能够在网上找到的经典例子是下面这样的：

class Article extends Component {
state = {
article: null
};
componentDidMount() {
this.fetchData(this.props.id);
}
componentDidUpdate(prevProps) {
if (prevProps.id !== this.props.id) {
this.fetchData(this.props.id);
}
}
async fetchData(id) {
const article = await API.fetchArticle(id);
this.setState({ article });
}

}

这显然好多了！但依旧有问题。有问题的原因是请求结果返回的顺序不能保证一致。比如我先请求

{id: 10}

{id: 20}

{id: 20}

这被叫做竞态，这在混合了

async

await

Effects并没有神奇地解决这个问题，尽管它会警告你如果你直接传了一个

async

如果你使用的异步方式支持取消，那太棒了。你可以直接在清除函数中取消异步请求。

或者，最简单的权宜之计是用一个布尔值来跟踪它：

function Article({ id }) {
const [article, setArticle] = useState(null);

useEffect(() => {
let didCancel = false;
async function fetchData() {
const article = await API.fetchArticle(id);
if (!didCancel) {
setArticle(article);
}
}
fetchData();

return () => { didCancel = true; };
}, [id]);

}

这篇文章讨论了更多关于如何处理错误和加载状态，以及抽离逻辑到自定义的Hook。我推荐你认真阅读一下如果你想学习更多关于如何在Hooks里请求数据的内容。

提高水准

在class组件生命周期的思维模型中，副作用的行为和渲染输出是不同的。UI渲染是被props和state驱动的，并且能确保步调一致，但副作用并不是这样。这是一类常见问题的来源。

而在

useEffect

useEffect

然而，用好

useEffect

这难免让人担忧如果

useEffect

我看到不同的应用在创造他们自己的Hooks，比如封装了应用鉴权逻辑的

useFetch

useTheme

useEffect

目前为止，

useEffect

[]

长远来看， Suspense用于数据请求 会允许第三方库通过第一等的途径告诉React暂停渲染直到某些异步事物（任何东西：代码，数据，图片）已经准备就绪。

当Suspense逐渐地覆盖到更多的数据请求使用场景，我预料

useEffect

在结束前

现在你差不多知道了我关于如何使用effects的所有知识，可以检查一下开头的TLDR。你现在觉得它说得有道理吗？我有遗漏什么吗？（我的纸还没有写完！）

最后

译者写了一个 React + Hooks 的 UI 库，方便大家学习和使用，

React + Hooks 项目实战

欢迎关注公众号「前端进阶课」认真学前端，一起进阶。