React: 函数组件与类有什么不一样?

时间 2020-07-06 标签 react 函数组件类有什么不一样

原文: How Are Function Components Different from Classes?
原译文: 函数组件与类有什么不一样?javascript

函数组件与类有什么不一样?

React函数组件与React类组件有何不一样？html

有一段时间，规范的答案是: 类能够访问更多功能（如状态）。有了Hooks，就再也不是这样了。java

也许你据说其中一个在性能上会更好。那么是哪个? 许多这样的benchmarks是有缺陷的，因此我会当心地从中得出结论。性能主要取决于代码在作什么，而不是你选择的是函数仍是类。在咱们的观察中，虽然优化策略有点不一样，但性能差别能够忽略不计。react

在任何一种状况下，咱们都不建议重写现有组件，除非你有其余缘由，而且你也不介意成为早期实践者。Hooks仍然是新的（就像2014年的React同样），而且一些“最佳实践”还没有进入教程。git

这给咱们带来了什么? React函数和类之间有什么根本的区别吗?固然，在心智模型中存在。 在这篇文章中，我将看看它们之间的最大区别。 自从2015年引入函数组件以来，它就一直存在，但它常常被忽视:github

函数组件捕获渲染的值。web

让咱们来解释下这意味着什么。编程

注意: 这篇文章不是对类或函数的价值判断。我只描述了React中这两种编程模型之间的区别。有关更普遍地采用功能的问题，请参阅Hooks FAQ。数组

考虑这个组件：浏览器

function ProfilePage(props) {
  const showMessage = () => {
    alert('Followed ' + props.user);
  };

  const handleClick = () => {
    setTimeout(showMessage, 3000);
  };

  return (
    <button onClick={handleClick}>Follow</button>
  );
}

它显示一个按钮，使用setTimeout模拟网络请求，而后显示弹出框。例如，若是props.user是'Dan'，它将在三秒后显示'Followed Dan'。很简单。

(请注意，在上面的示例中我是否使用箭头或函数声明并不重要。function handleClick()将以彻底相同的方式工做。)

咱们把它写成一个类会怎么样？一个简单的翻译多是这样的:

class ProfilePage extends React.Component {
  showMessage = () => {
    alert('Followed ' + this.props.user);
  };

  handleClick = () => {
    setTimeout(this.showMessage, 3000);
  };

  render() {
    return <button onClick={this.handleClick}>Follow</button>;
  }
}

一般认为这两段代码是等价的。人们常常在这些模式之间自由地重构，而不注意它们的含义:

可是，这两个代码片断略有不一样。 好好看看他们。你看到区别了吗? 就我我的而言，我花了一段时间才明白这一点。

前面有剧透，若是你想本身弄明白，这里有一个在线演示。 本文的其他部分解释了差别及其重要性。

在咱们继续以前，我想强调一点，我所描述的差别与React Hooks自己无关。以上示例甚至没有使用Hooks！

这都是React中函数和类之间的区别。若是你计划在React应用程序中更频繁地使用函数，则可能须要了解它。

咱们将经过React应用程序中常见的bug说明其差别。

打开此示例沙箱并使用选择的当前配置文件和上面的两个ProfilePage实现 – 每一个都渲染一个Follow按钮。

使用两个按钮尝试此操做序列：

点击其中一个"follow"按钮
在3秒以前更改所选的我的资料(笔：就是那个下拉框)。
查看弹出的文字。

你会注意到一个特殊的区别：

使用上面的ProfilePage 函数，单击Follow Dan的我的资料，而后导航到Sophie’s仍然会弹框'Followed Dan'。
使用上面的ProfilePage 类，他将会弹出'Followed Sophie'：

在此示例中，第一个行为是正确的行为。若是我follow一我的而后导航到另外一我的的我的资料，个人组件不该该对我follow的人感到困惑。 类的实现显然是错误的。

(你应该关注Sophie。)

那么为何咱们的类示例会以这种方式运行？

让咱们仔细看看咱们类中的showMessage方法：

class ProfilePage extends React.Component {
  showMessage = () => {
    alert('Followed ' + this.props.user);
  };

这个类的方法从this.props.user读取。Props在React中是不可变的，所以它们永远不会改变。 然而，this是，而且一直是可变的。

实际上，这就是this在一个类中的所有的目的。React自己会随着时间的推移而改变，以便你能够在render和生命周期方法中读取新版本。

所以，若是咱们的组件在请求处于运行状态时从新呈现，则this.props将会更改。showMessage方法从“过新”的props中读取user。

这就暴露了一个关于用户界面性质的有趣观察。若是咱们说UI在概念上是当前应用程序状态的函数， 那么事件处理程序就是呈现结果的一部分——就像可视化输出同样。 咱们的事件处理程序“属于”具备特定props和状态的特定渲染。

可是，调用其回调读取this.props的超时会中断该关联。咱们的showMessage回调没有“绑定”到任何特定的渲染，所以它“失去”正确的props。从this读取切断了这种联系。

假设函数组件不存在。 咱们如何解决这个问题？

咱们但愿以某种方式“修复”具备正确props的render和读取它们的showMessage回调之间的链接。沿途的某个地方props丢失了。

一种方法是在事件早期读取this.props，而后将它们显式传递到超时完成处理程序：

class ProfilePage extends React.Component {
  showMessage = (user) => {    alert('Followed ' + user);
  };

  handleClick = () => {
    const {user} = this.props;    setTimeout(() => this.showMessage(user), 3000);
  };

  render() {
    return <button onClick={this.handleClick}>Follow</button>;
  }
}

这个能够运行。可是，这种方法会使代码随着时间的推移变得更加冗长和容易出错。若是咱们须要不止一个prop怎么办？若是咱们还须要访问该状态怎么办？若是showMessage调用另外一个方法，而且该方法读取this.props.something或this.state.something，咱们将再次遇到彻底相同的问题。 因此咱们必须经过从showMessage调用的每一个方法将this.props和this.state做为参数传递。

这样作会破坏一般由类提供的人体工程学。这也很难记住或执行, 这就是人们常常解决问题的缘由。

一样，在handleClick中嵌入alert代码并不能解决更大的问题。咱们但愿以一种容许将代码拆分为更多方法的方式来构造代码，同时还能够读取与这个调用相关的呈现所对应的props和状态。这个问题甚至不是React独有的 - 你能够在任何UI库中重现它，你只须要将数据放入可变的对象，好比this。

也许，咱们能够在构造函数中绑定方法？

class ProfilePage extends React.Component {
  constructor(props) {
    super(props);
    this.showMessage = this.showMessage.bind(this);    this.handleClick = this.handleClick.bind(this);  }

  showMessage() {
    alert('Followed ' + this.props.user);
  }

  handleClick() {
    setTimeout(this.showMessage, 3000);
  }

  render() {
    return <button onClick={this.handleClick}>Follow</button>;
  }
}

不，这不能解决任何问题。请记住，问题是咱们从this.props读取的太晚了 - 不是咱们正在使用的语法！可是，若是咱们彻底依赖JavaScript闭包，问题就会消失。

一般会避免闭包，由于很难想象随着时间的推移可能会发生改变的值。但在React中，props和状态是不可改变的！(或者至少，这是一个强烈的推荐。)这就消除了闭包的主要障碍。

这意味着，若是结束某个特定渲染中的props或状态，则始终能够期望它们保持彻底相同：

class ProfilePage extends React.Component {
  render() {
    // Capture the props!
    const props = this.props;

    // Note: we are *inside render*.
    // These aren't class methods.
    const showMessage = () => {
      alert('Followed ' + props.user);
    };

    const handleClick = () => {
      setTimeout(showMessage, 3000);
    };

    return <button onClick={handleClick}>Follow</button>;
  }
}

你在渲染时“捕获”了props：

这样，它内部的任何代码（包括showMessage）均可以保证看到这个特定渲染的props。React再也不“移动咱们的奶酪”了。

而后咱们能够在里面添加任意数量的辅助函数，它们都会使用捕获的props和状态。 闭包来救场了!

[上面的例子](example above)是正确的，但看起来很奇怪。若是在render中定义函数而不是使用类方法，那么拥有一个类有什么意义呢？

实际上，咱们能够经过删除它周围的类“外壳”来简化代码:

function ProfilePage(props) {
  const showMessage = () => {
    alert('Followed ' + props.user);
  };

  const handleClick = () => {
    setTimeout(showMessage, 3000);
  };

  return (
    <button onClick={handleClick}>Follow</button>
  );
}

就像上面同样，props仍然被捕获 - React将它们做为参数传递。与this不一样，props对象自己永远不会被React改变。

若是你在函数定义中对props进行解构，效果会更明显:

function ProfilePage({ user }) {  const showMessage = () => {
    alert('Followed ' + user);  };

  const handleClick = () => {
    setTimeout(showMessage, 3000);
  };

  return (
    <button onClick={handleClick}>Follow</button>
  );
}

当父组件使用不一样的props呈现ProfilePage时，React将再次调用ProfilePage函数。但咱们单击的事件处理程序“属于”上一个呈现，它有本身的user值和读取它的showMessage回调。它们都无缺无损。

这就是为何，在这个演示的功能版本中，单击关注Sophie的我的资料，而后将选择更改成Sunil会弹出'Followed Sophie'：

这个行为是正确的。(虽然你可能也想关注Sunil！)

如今咱们了解React中函数和类之间的巨大差别：

函数组件捕获呈现的值。

使用Hooks，一样的原则也适用于状态。 考虑这个例子：

function MessageThread() {
  const [message, setMessage] = useState('');

  const showMessage = () => {
    alert('You said: ' + message);
  };

  const handleSendClick = () => {
    setTimeout(showMessage, 3000);
  };

  const handleMessageChange = (e) => {
    setMessage(e.target.value);
  };

  return (
    <>
      <input value={message} onChange={handleMessageChange} />
      <button onClick={handleSendClick}>Send</button>
    </>
  );
}

(这里是在线演示。)

虽然这不是一个很是好的message应用的UI，但它说明了一样的观点：若是我发送特定消息，组件不该该对实际发送的消息感到困惑。这个函数组件的message捕获了“属于”呈现的状态，呈现返回了浏览器调用的单击处理程序。所以，当我单击"send"时，消息将设置为输入中的内容。

所以，默认状况下，咱们知道React中的函数捕获props和状态。可是，若是咱们想要阅读不属于这个特定渲染的最新props或状态，该怎么办？ 若是咱们想“从将来读取它们”怎么办？

在类中，你能够经过阅读this.props或this.state来实现它，由于this自己是可变的。React改变了它。在函数组件中，还能够有一个可变值，该值由全部组件呈现共享。它被称为“ref”：

function MyComponent() {
  const ref = useRef(null);
  // You can read or write `ref.current`.
  // ...
}

可是，你必须本身管理它。

ref与实例字段扮演相同的角色。这是进入可变命令式世界的出口。你可能熟悉“DOM refs”，但概念更为通用。它只是一个盒子，你能够把东西放进去。

即便在视觉上，this.something看起来像是something.current的镜子。它们表明了相同的概念。

默认状况下，React不会为函数组件中的最新props或状态建立ref。在许多状况下，你不须要它们，分配它们将是浪费工做。可是，若是你愿意，能够手动跟踪值：

function MessageThread() {
  const [message, setMessage] = useState('');
  const latestMessage = useRef('');

  const showMessage = () => {
    alert('You said: ' + latestMessage.current);
  };

  const handleSendClick = () => {
    setTimeout(showMessage, 3000);
  };

  const handleMessageChange = (e) => {
    setMessage(e.target.value);
    latestMessage.current = e.target.value;
  };
    
  // ... 
}

若是咱们在showMessage中读取message，咱们会在按下“发送”按钮时看到消息。可是当咱们读取latestMessage.current时，咱们获得最新的值 - 即便咱们在按下发送按钮后继续输入。

你能够比较两个演示，看看差别。ref是一种“选择退出”渲染一致性的方法，在某些状况下能够很方便。

一般，你应该避免在渲染期间读取或设置refs，由于它们是可变的。咱们但愿保持渲染的可预测性。可是，若是咱们想得到特定props或状态的最新值，那么手动更新ref会很烦人。 咱们能够经过使用effect来自动处理它：

function MessageThread() {
  const [message, setMessage] = useState('');

  // Keep track of the latest value.
  const latestMessage = useRef('');
  useEffect(() => {
    latestMessage.current = message;
  });

  const showMessage = () => {
    alert('You said: ' + latestMessage.current);
  };
  // ...
}

(这里是一个demo。)

咱们在effect 中进行赋值，以便ref值仅在DOM更新后更改。这确保了咱们的突变不会破坏依赖于可中断呈现的Time Slicing and Suspense等特性。

使用像这样的ref并非常常须要的。捕获props或状态一般是更好的默认配置。 可是，在处理间隔和订阅等命令式API时，它能够很方便。请记住，你能够跟踪任何这样的值 - 一个prop，一个状态变量，整个props对象，甚至是函数。

这种模式对于优化也很方便，例如当useCallback标识更改太频繁时。可是，using a reducer 一般是一个更好的解决方案。(后续的博客文章的主题！)

在这篇文章中，咱们研究了类中常见的破坏模式，以及闭包如何帮助咱们修复它。然而，你可能已经注意到，当你试图经过指定依赖项数组来优化Hooks时，可能会遇到使用过期闭包的bug。是否意味着闭包是问题？我不这么认为。

正如咱们上面所看到的，闭包实际上帮助咱们解决了很难注意到的细微问题。相似地，它们使在并发模式下编写正确工做的代码更加容易。这是可能的，由于组件内部的逻辑结束了正确的props和状态。

到目前为止，我所看到的全部状况下，“过期的闭包”问题都是因为错误地假设“函数不会更改”或“props老是相同”而发生的。 事实并不是如此，由于我但愿这篇文章有助于澄清这个问题。

函数与它们的props和状态密切相关，所以它们的身份也一样重要。这不是bug，而是函数组件的一个特性。例如，函数不该该从useeffect或usecallback的“依赖项数组”中排除。(正确的修复一般是useReducer或上面的useRef解决方案 - 咱们很快就会记录如何在它们之间进行选择。)

当咱们编写大多数带有函数的React代码时，咱们须要调整优化代码，以及哪些值会随时间变化。

正如 Fredrik所说 :

到目前为止，我在hook中发现的最好的规则是“编写代码时，就好像任何值均可以随时更改”。

函数也不例外。这将须要一段时间才能成为react学习材料中的常识。这须要从阶级观念上作一些调整。但我但愿这篇文章能够帮助你以新的眼光看待它。

React函数老是捕获它们的值 - 如今咱们知道缘由了。

他们是一个彻底不一样的神奇宝贝。