JavaScript / 前端 / 译文 · 10月 7, 2020 0

React v16.8.x – Hooks 简介

Hooks 是 React v16.8 加入的新特性,它可以让你使用 state 和其他特性,而不用类组件。

import React, { useState } from 'react';
function Example() {
  // 声明一个 state
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

新函数 useState 是我们学到的第一个 Hooks ,这个例子也只是意思一下,如果它没有意义,请不要担心!
你可以在下一页开始学习 Hooks。在本节,我们将继续解释为什么我们向 React 添加 Hooks,以及它如何帮你写出更好的应用。

注意
React v16.8.0 是第一个支持 hooks 的版本。升级时不要忘了升级所有的包,包括 React DOM。React Native 将在下一个稳定的版本支持 hooks。

无破坏性的改变

继续之前,注意 hooks :

  • 选择性使用。你可以在一些组件中使用 hooks 而不用重写已存在的组件代码。如果你不想用,不必马上学习 hooks。
  • 100% 向后兼容。hooks 没有任何破坏性的改变。

React 并没有计划移除类组件。您可以在本页底部阅读有关 Hooks 逐步采用策略的更多信息。

Hooks 不会取代你对 React 概念的了解。相反,hooks 基于你所了解的 React 概念,如:props,state,context,ref,和生命周期等, 提供了一个更直接的 API 。正如后面我们将了解的,hooks 为使用它们提供了更强力的方式。

如果您只是想开始学习 Hooks,请随意直接跳到下一页!您还可以继续阅读此页面,详细了解我们为何添加 Hooks,以及我们如何在不重写应用程序的情况下开始使用它们。

动机

Hook解决了 React 中我们在编写和维护数以万计的组件时遇到的各种看似无关的问题。无论您是在学习 React,每天使用它,还是更喜欢使用具有类似组件模型的不同 JS 库,您都可能会发现其中的一些问题。

在组件之间重用有状态逻辑很困难

React没有提供将可重用行为“附加”到组件的方法(例如,与状态树store连接)。如果您已经使用React一段时间,你可能知道使用 props 来控制渲染或者HOC高阶函数来解决这些问题。但是这些模式需要你在使用它们时重构组件,这可能很麻烦,使代码更难以跟进。如果你查看典型的React应用程序调试工具 DevTools,可能会发现由提供者,消费者,高阶组件,props渲染和其他抽象层围绕的组件的“包装器地狱”。虽然我们可以在DevTools中过滤掉它们,但这指出了更深层次的根本问题:React需要一个更好的方式来共享有状态逻辑。

使用Hooks,你可以从组件中提取有状态逻辑,以便可以独立测试并重复使用。Hooks允许你在不更改组件层次结构的情况下重用有状态逻辑。这样可以轻松地在许多组件之间或与社区共享Hook。

复杂的组件变得难以理解

我们经常不得不维护一些从简单开始,但最后却变成了无法管理的混乱的状态逻辑和副作用的组件。每个生命周期方法经常常包含大量不相关逻辑。例如,组件可能会在componentDidMount和componentDidUpdate中获取数据。但是,同一个componentDidMount方法可能还包含一些设置事件侦听器的无关逻辑,并在componentWillUnmount中执行清理。一起更改的相互关联的代码被拆分,但完全不相关的代码最终组合在一个方法中。这使得引入错误和不一致变得太容易了。

在许多情况下,不可能将这些组件分解为较小的组件,因为有状态逻辑遍布整个地方。测试它们也很困难。这是许多人更喜欢将React与单独的状态管理库相结合的原因之一。但是,这通常会引入太多的抽象,要求您在不同的文件之间跳转,并使重用组件更加困难。

为了解决这个问题,Hooks允许您根据相关的部分(例如设置订阅或获取数据)将一个组件拆分为更小的函数,而不是强制基于生命周期方法的拆分。你还可以选择使用reducer管理组件的本地状态,以使其更具可预测性。

类会混淆人和机器

除了使代码重用和代码组织更加困难之外,我们发现类可能成为学习React的一大障碍。您必须了解 this 在JavaScript中是如何工作的,这与它在大多数语言中的工作方式有很大不同。您必须谨记绑定事件处理程序。如果没有不稳定的语法规则,代码将非常冗长。人们可以很好地理解props,state 和自上而下的数据流,但仍然很困惑类组件。React中函数和类组件之间的区别以及何时使用每个组件,即使在经验丰富的React开发人员之间也存在分歧。

此外,React已经推出了大约五年,我们希望确保它在未来五年内继续保持。正如Svelte,Angular,Glimmer和其他框架所表明的那样,提前编译组件具有很大的潜力。特别是如果它不限于模板。最近,我们一直在尝试使用Prepack进行组件折叠,我们已经看到了期望的早期结果。但是,我们发现类组件可能会鼓励无意识的模式,使这些优化回归到较慢的路径。类也为如今的前端工具提出了问题。例如,类不能很好的精简,并且它们使得热加载片段化和不可靠。我们希望提供一种API,使代码更有可能保持在可优化的路径上。

为了解决这些问题,Hooks允许您在没有类的情况下使用更多React的功能。从概念上讲,React组件始终更接近函数。Hooks拥抱函数,但不会抛弃React的根本精髓。Hooks提供了对命令式逃生舱口的访问,并且不需要您学习复杂的功能或反应式编程技术。

逐步采用策略

我们知道React开发人员专注于发布产品,没有时间研究每个正在发布的新API。Hooks是非常新的,在考虑学习或采用它们之前等待更多示例和教程可能会更好。

我们也理解为React添加新特性的标准非常高。对于好奇的读者,我们已经准备了一个详细的RFC,其中包含了更多动机细节,并提供了有关特定设计决策和现有技术相关的额外视角。

至关重要的是,Hooks与现有代码并行工作,因此您可以逐步采用它们。我们正在分享这个实验性的API,以便从社区中那些有兴趣塑造React未来的人那里获得早期反馈 – 我们将在公开场合迭代Hooks。

最后,不必急于迁移到Hooks。我们建议避免任何“重大改写”,特别是对于现有的复杂类组件。开始“考虑Hooks”需要一点精神上的转变。根据我们的经验,最好先在新的和非关键组件中练习Hooks,并确保团队中的每个人都对它们感到满意。在您尝试使用Hooks之后,请随时向我们发送反馈,无论是积极的还是消极的。

我们打算让Hooks涵盖所有现有的类用例,但是在可预见的将来我们将继续支持类组件。在Facebook,我们有数万个组件作使用类编写,我们绝对没有计划重写它们。相反,我们开始在新代码中使用Hooks与类并行。

冀ICP备19028007号