一、为什么须要函数组件？
开篇咱们先来聊“Why”。React-Hooks 这个货色比拟特地，它是 React 团队在真刀真枪的 React 组件开发实际中，逐步认知到的一个改良点，这背地其实波及对类组件和函数组件两种组件模式的思考和偏重。因而，你首先得晓得，什么是类组件、什么是函数组件，并实现对这两种组件模式的辨析。
类组件（Class Component）
所谓类组件，就是基于 ES6 Class 这种写法，通过继承 React.Component 得来的 React 组件。
class DemoClass extends React.Component {
// 初始化类组件的 state
state = {text: ""};
// 编写生命周期办法 didMount
componentDidMount() {// 省略业务逻辑}
// 编写自定义的实例办法
changeText = (newText) => {
// 更新 state
this.setState({text: newText});
};
// 编写生命周期办法 render
render() {
return (
<div className="demoClass">
<p>{this.state.text}</p>
<button onClick={this.changeText}> 点我批改 </button>
</div>
);
}
}函数组件 / 无状态组件（Function Component/Stateless Component）
函数组件顾名思义，就是以函数的状态存在的 React 组件。晚期并没有 React-Hooks 的加持，函数组件外部无奈定义和保护 state，因而它还有一个别名叫“无状态组件”。以下是一个典型的函数组件：
function DemoFunction(props) {const { text} = props
return (
<div className="demoFunction">
<p>{`function 组件所接管到的来自外界的文本内容是：[${text}]`}</p>
</div>
);
}两类组件的不同
函数组件与类组件的比照：无关“优劣”，只谈“不同”。你能够说，在 React-Hooks 呈现之前的世界里，类组件的能力边界显著强于函数组件，但要进一步推导“类组件强于函数组件”，未免显得有些牵强。同理，一些文章中一味宣扬函数组件轻量优雅上手迅速，不久的未来肯定会把类组件干没（类组件：我做错了什么？）之类的，更是不可偏听偏信。
当咱们探讨这两种组件模式时，不应怀揣“孰优孰劣”这样的偏见，前端培训而应该更多地去关注两者的不同，进而把不同的个性与不同的场景做连贯，这样能力求得一个全面的、辩证的认知。
类组件须要继承 class，函数组件不须要；
类组件能够拜访生命周期办法，函数组件不能；
类组件中能够获取到实例化后的 this，并基于这个 this 做各种各样的事件，而函数组件不能够；
类组件中能够定义并保护 state（状态），而函数组件不能够；
函数组件更轻量，更响应 React 设计思维的“笨重快艇”，更加符合 React 框架的设计理念。同样逻辑的函数组件相比类组件而言，代码复杂度要低得多得多。
类组件更重，包裹在面向对象思维下的“重装战舰”
函数组件会捕捉 render 外部的状态，这是两类组件最大的不同。类组件很难做到这一点。
不夸大地说，React 组件自身的定位就是函数，一个吃进数据、吐出 UI 的函数。作为开发者，咱们编写的是申明式的代码，而 React 框架的次要工作，就是及时地把申明式的代码转换为命令式的 DOM 操作，把数据层面的形容映射到用户可见的 UI 变动中去。这就意味着从原则上来讲，React 的数据应该总是紧紧地和渲染绑定在一起的，而类组件做不到这一点。
从新了解类组件：包裹在面向对象思维下的“重装战舰”
React 类组件外部预置了相当多的“现成的货色”等着你去调度 / 定制，state 和生命周期就是这些“现成货色”中的典型。要想得到这些货色，难度也不大，你只须要轻轻地继承一个 React.Component 即可。
比拟全面的组件带来的问题是
（1）很多问题不须要编写一个类组件来解决，过于简单
（2）开发者编写的逻辑在封装后是和组件粘在一起的，这就使得类 组件外部的逻辑难以实现拆分和复用。如果你想要突破这个僵局，则须要进一步学习更加简单的设计模式（比方高阶组件、Render Props 等），用更高的学习老本来替换一点点编码的灵便度。
这所有的所有，光是想想就让人头秃。所以说，类组件诚然弱小，但它绝非万能。
深刻了解函数组件：响应 React 设计思维的“笨重快艇”
咱们再来看这个函数组件的 case：
function DemoFunction(props) {const { text} = props
return (
<div className="demoFunction">
<p>{`function 组件所接管到的来自外界的文本内容是：[${text}]`}</p>
</div>
);
}当然啦，要是你认为函数组件的简略是因为它只能承当渲染这一种工作，那可就太小瞧它了。它同样可能承接绝对简单的交互逻辑，像这样：
function DemoFunction(props) {const { text} = props
const showAlert = () => {alert(` 我接管到的文本是 ${text}`)
}
return (
<div className="demoFunction">
<p>{`function 组件所接管到的来自外界的文本内容是：[${text}]`}</p>
<button onClick={showAlert}> 点击弹窗 </button>
</div>
);
}相比于类组件，函数组件肉眼可见的特质天然包含轻量、灵便、易于组织和保护、较低的学习老本等。这些因素毫无疑问是重要的，它们也的确驱动着 React 团队做出扭转。然而除此之外，还有一个非常容易被大家漠视、也极少有人能真正了解到的知识点，我在这里要着重讲一下。这个知识点缘起于 React 作者 Dan 晚期特意为类组件和函数组件写过的一篇十分棒的比照文章，这篇文章很长，然而通篇都在论证这一句话：
函数组件会捕捉 render 外部的状态，这是两类组件最大的不同。
不夸大地说，React 组件自身的定位就是函数，一个吃进数据、吐出 UI 的函数。作为开发者，咱们编写的是申明式的代码，而 React 框架的次要工作，就是及时地把申明式的代码转换为命令式的 DOM 操作，把数据层面的形容映射到用户可见的 UI 变动中去。这就意味着从原则上来讲，React 的数据应该总是紧紧地和渲染绑定在一起的，而类组件做不到这一点。
为什么类组件做不到？这里我摘出上述文章中的 Demo，站在一个新的视角来解读一下“函数组件会捕捉 render 外部的状态，这是两类组件最大的不同”这个论断。
在线测试 Demo
这个组件返回的是一个按钮，交互内容也很简略：点击按钮后，过 3s，界面上会弹出“Followed xxx”的文案。相似于咱们在微博上点击“关注某人”之后弹出的“已关注”这样的揭示。
看起来如同没啥故障，然而如果你在这个在线 Demo 中尝试点击基于类组件模式编写的 ProfilePage 按钮后 3s 内把用户切换为 Sophie
明明咱们是在 Dan 的主页点击的关注，后果却提醒了“Followed Sophie”！
这个景象必然让许多人感到困惑：user 的内容是通过 props 下发的，props 作为不可变值，为什么会从 Dan 变成 Sophie 呢？
因为尽管 props 自身是不可变的，但 this 却是可变的，this 上的数据是能够被批改的，this.props 的调用每次都会获取最新的 props，而这正是 React 确保数据实时性的一个重要伎俩。
少数状况下，在 React 生命周期对执行程序的调控下，this.props 和 this.state 的变动都可能和预期中的渲染动作保持一致。但在这个案例中，咱们通过 setTimeout 将预期中的渲染推延了 3s，突破了 this.props 和渲染动作之间的这种机会上的关联，进而导致渲染时捕捉到的是一个谬误的、批改后的 this.props。这就是问题的所在。
props 会在 ProfilePage 函数执行的一瞬间就被捕捉，而 props 自身又是一个不可变值，因而咱们能够充沛确保从当初开始，在任何机会下读取到的 props，都是最后捕捉到的那个 props。深圳前端培训当父组件传入新的 props 来尝试从新渲染 ProfilePage 时，实质上是基于新的 props 入参发动了一次全新的函数调用，并不会影响上一次调用对上一个 props 的捕捉。这样一来，咱们便确保了渲染后果的确可能合乎预期。
如果你认真浏览了我后面说过的那些话，置信你当初肯定也不仅仅可能充沛了解 Dan 所想要表白的“函数组件会捕捉 render 外部的状态”这个论断，而是可能更进一步地意识到这样一件事件：函数组件真正地把数据和渲染绑定到了一起。
为什么须要 Hooks？
正因为函数组件的长处，函数组件变得不可或缺。因而函数组件相较于类组件缺失的 state、生命周期等性能，须要应用 Hooks 来欠缺。
Hooks 的实质：一套可能使函数组件更弱小、更灵便的“钩子”
React-Hooks 是什么？它是一套可能使函数组件更弱小、更灵便的“钩子”。
后面咱们曾经说过，函数组件比起类组件“少”了很多货色，比方生命周期、对 state 的治理等。这就给函数组件的应用带来了十分多的局限性，导致咱们并不能应用函数这种模式，写出一个真正的全功能的组件。
React-Hooks 的呈现，就是为了帮忙函数组件补齐这些（绝对于类组件来说）缺失的能力。
如果说函数组件是一台笨重的快艇，那么 React-Hooks 就是一个内容丰盛的零部件箱。“重装战舰”所预置的那些设施，这个箱子里根本全都有，同时它还不强制你全都要，而是容许你自在地抉择和应用你须要的那些能力，而后将这些能力以 Hook（钩子）的模式“钩”进你的组件里，从而定制出一个最适宜你的“专属战舰”。
二、How 怎么应用 react-hooks？
编码实例来帮忙你意识 useState、useEffect 这两个有代表性的 Hook。请你摒弃“意识的 API 名字越多就越牛”这种谬误的学习理念。如果你心愿把握尽可能多的 Hook 的用法，点击这里能够一键进入 React-Hooks API 文档的陆地。对本课时来说，所有波及对 API 用法的介绍都是“教具”，仅仅是为后续更深层次的常识解说作铺垫。
useState 给函数定义一个 state
（1）定义函数组件的一个状态
const [name, setName] = useState(‘initialState’);
（2）应用属性
console.log(state)
(3)批改属性
setName(‘fang’)
useState 返回的是一个数组，数组的第一个元素对应的是咱们想要的那个 state 变量，第二个元素对应的是可能批改这个变量的 API。
咱们能够通过数组解构的语法，将这两个元素取出来，并且依照咱们本人的想法命名。状态和批改状态的 API 名都是能够自定义的。
后续咱们能够通过调用 setState(”)，来批改 state 的值。
状态更新后会触发渲染层面的更新，这点和类组件是统一的。
当咱们在函数组件中调用 React.useState 的时候，实际上是给这个组件关联了一个状态——留神，是“一个状态”而不是“一批状态”。这一点是绝对于类组件中的 state 来说的。在类组件中，咱们定义的 state 通常是一个如下所示的对象。而在 useState 这个钩子的应用背景下，state 就是独自的一个状态，它能够是任何你须要的 JS 类型。
this.state {
text: "初始文本",
length: 10000,
author: ["xiuyan", "cuicui", "yisi"]
}useEffect() 用于为函数组件引入副作用的钩子
函数组件相比于类组件来说，最显著的差别就是 state 和生命周期的缺失。useState 为函数组件引入了 state，而 useEffect 则在肯定水平上补救了生命周期的缺席。副作用就是说函数组件的 render 在执行前后会执行一些其余函数。相似于 Java 中的 AOP。useEffect 可能为函数组件引入副作用。过来咱们习惯放在 componentDidMount、componentDidUpdate 和 componentWillUnmount 三个生命周期里来做的事，当初能够放在 useEffect 里来做，比方操作 DOM、订阅事件、调用内部 API 获取数据等。
useEffect(callBack, []) useEffect 能够接管两个参数，别离是回调函数与依赖数组。
（1）每一次渲染后都执行的副作用：传入回调函数，不传依赖数组。调用模式如下所示：
useEffect(callBack)
（2）仅在挂载阶段执行一次的副作用：传入回调函数，且这个函数的返回值不是一个函数，同时传入一个空数组。调用模式如下所示：
useEffect(()=>{
// 这里是业务逻辑 }, [])
（3）仅在挂载阶段和卸载阶段执行的副作用：传入回调函数，且这个函数的返回值是一个函数，同时传入一个空数组。如果回调函数自身记为 A，返回的函数记为 B，那么将在挂载阶段执行 A，卸载阶段执行 B。调用模式如下所示：
useEffect(()=>{
// 这里是 A 的业务逻辑
// 返回一个函数记为 B
return ()=>{}
}, [])（4）每一次渲染都触发，且卸载阶段也会被触发的副作用：传入回调函数，且这个函数的返回值是一个函数，同时不传第二个参数。如下所示：
useEffect(()=>{
// 这里是 A 的业务逻辑
// 返回一个函数记为 B
return ()=>{}
})（5）依据肯定的依赖条件来触发的副作用：传入回调函数，同时传入一个非空的数组，如下所示：
useEffect(()=>{
// 这是回调函数的业务逻辑
// 若 xxx 是一个函数，则 xxx 会在组件每次因 num1、num2、num3 的扭转而从新渲染时被触发
return xxx
}, [num1, num2, num3])第（3）中状况须要留神，这种调用形式之所以会在卸载阶段去触发 B 函数的逻辑，是由 useEffect 的执行规定决定的：useEffect 回调中返回的函数被称为“革除函数”，当 React 辨认到革除函数时，会在调用新的 effect 逻辑之前执行革除函数外部的逻辑。这个法则不会受第二个参数或者其余因素的影响，只有你在 useEffect 回调中返回了一个函数，它就会被作为革除函数来解决。
第（4）中状况，其实你只有记住，如果你有一段 effect 逻辑，须要在每次调用它之前对上一次的 effect 进行清理，那么把对应的清理逻辑写进 useEffect 回调的返回函数（下面示例中的 B 函数）里就行了。
第（5）中状况，这里我给出的一个示意数组是 [num1, num2, num3]。首先须要阐明，数组中的变量个别都是来源于组件自身的数据（props 或者 state）。若数组不为空，那么 React 就会在新的一次渲染后去比照前后两次的渲染，查看数组内是否有变量产生了更新（只有有一个数组元素变了，就会被认为更新产生了），并在有更新的前提上来触发 useEffect 中定义的副作用逻辑。
三、Why React-Hooks?
为什么应用 React-Hooks？
辞别难以了解的 Class；
解决业务逻辑难以拆分的问题；
使状态逻辑复用变得简略可行；
函数组件从设计思维上来看，更加符合 React 的理念。
辞别难以了解的 Class：把握 Class 的两大“痛点”
this。组件成员办法如果是一般 function，外面的 this 不示意组件本身实例。为了示意本身实例，之前通过用 bind、当初推崇箭头函数来实现。但不论什么招数，实质上都是在用实际层面的束缚来解决设计层面的问题。好在当初有了 Hooks，所有都不一样了，咱们能够在函数组件里放飞自我（毕竟函数组件是不必关怀 this 的）哈哈，解放啦。
生命周期。
1）学习老本
2）不合理的逻辑布局形式。须要将逻辑打散，放到各个生命周期里。比方申请数据放在 componentDidMount，剖析数据放在 componentDidUpdate。同一个数据处理逻辑扩散。逻辑已经一度与生命周期耦合在一起。
而在 Hooks 的帮忙下，咱们齐全能够把这些繁冗的操作依照逻辑上的关联拆分进不同的函数组件里：咱们能够有专门治理订阅的函数组件、专门解决 DOM 的函数组件、专门获取数据的函数组件等。Hooks 可能帮忙咱们实现业务逻辑的聚合，防止简单的组件和冗余的代码。
状态复用：Hooks 将简单的问题变简略
过来咱们复用状态逻辑，靠的是 HOC（高阶组件）和 Render Props 这些组件设计模式，这是因为 React 在原生层面并没有为咱们提供相干的路径。但这些设计模式并非万能，它们在实现逻辑复用的同时，也毁坏着组件的构造，其中一个最常见的问题就是“嵌套天堂”景象。
Hooks 能够视作是 React 为解决状态逻辑复用这个问题所提供的一个原生路径。当初咱们能够通过自定义 Hook，达到既不毁坏组件构造、又可能实现逻辑复用的成果。
在意识到 Hooks 带来的利好的同时，还须要意识到它的局限性。
对于 Hooks 的局限性，目前社区鲜少有人探讨。这里我想联合团队开发过程当中遇到的一些瓶颈，和你分享实际中的几点感触：
Hooks 临时还不能齐全地为函数组件补齐类组件的能力：比方 getSnapshotBeforeUpdate、componentDidCatch 这些生命周期，目前都还是强依赖类组件的。官网尽管立了“会尽早把它们加进来”的 Flag，然而说真的，这个 Flag 真的立了蛮久了……（扶额）
“轻量”简直是函数组件的基因，这可能会使它不可能很好地消化“简单”：咱们有时会在类组件中见到一些办法十分繁多的实例，如果用函数组件来解决雷同的问题，业务逻辑的拆分和组织会是一个很大的挑战。我集体的感觉是，从头到尾都在“过于简单”和“适度拆分”之间摇摆不定，哈哈。耦合和内聚的边界，有时候真的很难把握，函数组件给了咱们肯定水平的自在，却也对开发者的程度提出了更高的要求。
Hooks 在应用层面有着严格的规定束缚：这也是咱们下个课时要重点讲的内容。对于现在的 React 开发者来说，如果不能牢记并践行 Hooks 的应用准则，如果对 Hooks 的要害原理没有扎实的把握，很容易把本人的 React 我的项目搞成大型车祸现场。
四、React-Hooks 应用准则
只在 React 函数中调用 Hook；这个是说不要再一般函数中应用 Hook。
不要在循环、条件或嵌套函数中调用 Hook。准则 2 中强调的所有“不要”，都是在指向同一个目标，那就是要确保 Hooks 在每次渲染时都放弃同样的执行程序。
从源码调用流程看：Hooks 的失常运作，在底层依赖于程序链表。首次渲染时，每定义一个 Hook，就会将初始化后的 hook 对象放入链表。当前应用 Hook 时，会依照首次渲染的程序将 Hook 和链表中的 hook 对象顺次对应，不是依照 hook 变量名字应用。如果首次渲染和当前渲染数量或者地位不对应，数据就会错乱。
准则 2 例子
（1）以 useState 为例。如果首次渲染时应用到的 useState 为：
[name, setName] = useState(“ 修言 ”);
[age] = useState(“99”);
[career, setCareer] = useState(“ 我是一个前端，爱吃小熊饼干 ”);
（2）再次渲染时，因为 if 等判断条件使得只有一次调用：此时的 useState 会和下面首次渲染生成的链表中的第一个对应，从而导致数据错乱。
useState(“ 我是一个前端，爱吃小熊饼干 ”)