为什么要使用React Hooks，官翻

Hooks是即将推出的功能，它允许您在不编写类的情况下使用状态和其他React功能。目前在React v16.7.0-alpha中可用

import { useState } from 'react'; 
function Example() { 
    // Declare a new state variable, which we'll call "count" 
    const [count, setCount] = useState(0); 
    return ( 
        <div> <p>You clicked {count} times</p> 
            <button onClick={() => setCount(count + 1)}> Click me </button> 
        </div>
    )
}复制代码

useState这个方法是我们接触到的第一个”hook”。我们用它完成了一个最简单的组件，接下来我们会看到更多有趣的应用。

useState这个新函数是我们将要学习的第一个“Hook”，但这个例子只是一个预告片。如果它对你没有意义，请不要担心！你可以直接跳转到下一页直接学习react hooks。

在这个页面上，我们将继续解释为什么我们将Hook添加到React，以及它们如何帮助您编写出色的应用程序。

视频介绍

在React Conf 2018，Sophie Alpert 和 Dan Abramov介绍了Hooks，然后Ryan Florence演示了如何用它们重构我们的应用。需要翻墙，自己搭墙。

No Breaking Changes

没有破坏式/颠覆式变更，在我们继续学习之前，你需要注意：

• 完全可选择 您可以在一些组件中尝试Hooks，而无需重写任何现有代码。但是如果你不想学习也不想使用，也没有关系。
  
• 100% 向后兼容 Hooks不包含任何破坏式<颠覆式>更新。
• 开始使用 Hooks已经包含在alpha版本中。而且我们期望在接受社区反馈后把他们加入到React 16.7版本中。

class不会被移除 你可以在本页的最后一节中了解到更多关于Hooks的渐进式策略。

Hooks不会取代或影响你对React的理解  相反，Hooks提供了一种更直观的API,来帮助你理解那些你已知的props, state, context, refs 和生命周期等旧的API，你可以用一种更强大的方式将它们整合起来。

如果你只是想要学学Hooks如何使用，你可以直接跳到下一页。当然你也可以继续读这一页。你将会在这里了解到更多我们引入Hooks的原因，以及要如何在已有的代码上使用Hooks重构我们的应用。

Motivation/动机

Hooks解决了我们在过去五年来编写和维护react遇到的各种看似不相关的问题。不论你是否正在学习react，每天都在使用它，甚至是你只是在使用一些与React具有相似组件模型的框架，你或多或少都会注意到这些问题。

跨组件复用含状态的逻辑（stateful logic）十分困难

React没有提供一种将复用行为绑定 attach 到组件的方法（比如将其连接到store，类似redux这类状态管理库的connect方法）。如果您已经使用React一段时间，您可能熟悉通过 render props 和 higher-order 高阶组件等模式，来试图解决这些问题。但是这些模式要求您在使用它们时重构组件，这可能很麻烦并且使代码难以为继。使用Hooks，您可以从组件中提取有状态的逻辑，以便可以独立测试并重复使用。如果你在React DevTools中看到一个典型的React应用程序，你可能会发现一个由包含 providers, consumers/消费者, higher-order/高阶组件，render props和其他抽象层的组件组成的“包装器地狱”。 虽然我们可以在DevTools中过滤它们，但这反应出一个更深层次的问题：React需要一个更好的原生方法来共享stateful logic。

使用Hooks，你可以把含有state的逻辑从组件中提取抽象出来，以便于独立测试和复用。

同时，Hooks允许您在不更改组件结构的情况下重用有状态的逻辑。这样就可以轻松地在许多组件之间或与社区共享Hook。

我们将在构建你自己的Hooks中进行更多的讨论。

复杂的组件变得难以理解

我们往往不得不维护一个在开始十分简单，但却慢慢演变成了一个无法管理的stateful logic/含有state逻辑的混乱的和一堆含有副作用的组件。

[随着开发的深入它们会变得越来越大、越来越混乱，各种逻辑在组件中散落的到处都是，每个生命周期钩子中都包含了一堆互不相关的逻辑]。

比如，我们的组件可能会在 componentDidMount 和 componentDidUpdate中执行一些数据拉取的工作，但是，在相同的componentDidMount方法可能还包含一些无关逻辑，比如设置事件监听（之后需要在 componentWillUnmount 中清除）。

一起更改的相互关联的代码被拆分，但完全不相关的代码最终组合在一个方法中。 这使得引入错误和不一致变得太容易了。

最终的结果是强相关的代码被分离，反而是不相关的代码被组合在了一起。这显然会轻易的导致bug和异常。

在许多情况下，我们也不太可能将这些组件分解成更小的组件，因为stateful logic到处都是。

测试他们也很困难。这也是为什么很多人喜欢将React和状态管理的库组合使用的原因之一。

但是，这通常会引入太多的抽象，要求您在不同的文件之间跳转，并使得重用组件变得更加困难。

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

我们将在使用Effect Hook中更多地讨论这个问题。

不止是人，连机器也对class难以理解

除了使代码重用和代码组织更加困难之外，我们发现类可能是学习React的一大障碍。

你不得不了解this在javascript中是如何工作的，这与它在大多数语言中的工作方式非常不同。 您必须记住绑定事件处理程序。

没有不稳定的语法提议，代码非常冗长。 人们可以很好地理解props，statte和自上而下的数据流，但仍然要与class类作斗争。 React中的函数和类组件之间的区别以及何时使用每个组件都导致即使是经验丰富的React开发人员之间也会产生分歧。

此外，React已经发布五年有余了，我们希望它在下一个五年里继续保持稳定。正如Svelte，Angular，Glimmer和其他人所表明的那样，提前编译组件具有很大的未来潜力。特别是如果它不限于模板。最近，我们一直在尝试使用Prepack进行component folding，而且我们已经初步看到了成果。但是，我们发现类组件（class组件）可能会鼓励无意识的模式，使这些优化回归到较慢的路径。

class组件为今天的工具带来了很多问题，例如，classes不能很好的被minify，并且它们使热更新的模块（flaky ）变得不稳定和不可靠，同时他们也造成了太多不必要的组件更新。 我们想要提供一种更便于优化的API。

为了解决这些问题，Hooks允许您在没有类的情况下使用更多React的功能。 从概念上讲，React组件一直是更接近于函数的。 Hooks拥抱函数，但是并不会修改React的基本概念。Hooks在你不需要学习复杂的函数式编程或者响应式编程的情况下，为你提供了逃离这些问题的途径。

渐进策略

太长不看版: 我们完全没有把classes从React中移除的打算。

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

我们也理解添加新的底层API的学习理解门槛非常的高。对于好奇的读者，我们准备了一份详细的RFC来提供更多我们设计Hook的细节和动机，并提供有关特定设计决策和相关现有技术的额外视角。

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

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

Next Steps

在本页末尾，您应该大致了解Hook正在解决的问题，但很多细节可能都不清楚。 别担心！ 现在让我们进入下一页，我们将通过示例开始学习Hooks。

本文结合了react官网原文和react中文网还有谷歌翻译完成，在原文有些生涉难懂地方和eact中文网轻微走形的情况下略作修改，方便自己和大家阅读。

~_` 安利一下谷歌翻译真好用

参考链接

React Hooks

React Hooks 中文网