现代React状态模式指南

点击上方关注 TianTianUp，一起学习，天天进步

大家好，我是小弋。

今天分享的内容是现代React状态相关的文章。

简介

自2013年成立以来，React已经推出了一套强大的工具，帮助开发人员减轻了创建Web应用程序的一些琐事，使他们能够专注于重要的事情。

尽管React有很多功能，而且在开发者中一直很受欢迎，但是我一次又一次地发现，我们中的很多人都在问同一个问题。我们如何使用React处理复杂的状态？

在这篇文章中，我们将研究什么是状态，我们如何组织它，以及随着我们应用程序的复杂性增加而采用的不同模式。

---

了解React中的state

在其最纯粹的形式中，React可以被认为是一个蓝图。给定一些状态，你的应用程序将以某种方式出现。React更倾向于声明式而不是命令式，这是一种华丽的说法，即你写下你想要发生的事情，而不是写下实现它的步骤。正因为如此，正确管理状态变得极其重要，因为状态控制着你的应用程序的行为方式。

State in action

在我们开始之前，简单地讨论一下什么是状态会很有帮助。就我个人而言，我认为状态是一个可变值的集合，它随时间变化，并直接影响组件行为。

状态与prop非常相似，但不同的是，状态可以在其定义的上下文中改变，而接收到的道具如果不通过回调函数就无法改变。

让我们来看看:

const UserList = () => {
    const [users, setUsers] = useState([])

     useEffect(() => {
       const getUsers = async () => {
           const response = await fetch("https://myuserapi.com/users")
           const users = await response.json()
           setUsers(users)
       }
       getUsers()
     }, [])

    if (users.length < 1) return null;

    return <ul>
      {users.map(user => <li>{user.name}</li>)}
    </ul>
}

在这个例子中，我们在组件安装时从API中获取用户，并在收到响应后更新用户数组。我们天真地假设调用总是成功的，以减少这个例子的复杂性。

我们可以看到，状态被用来渲染带有用户名字的列表项，如果数组中没有用户，它将返回空。状态随着时间的推移而变化，并被用来直接影响组件的行为。

这里值得注意的另一件事是，我们正在使用React的内置状态管理方法，使用useState Hook。根据你的应用程序和状态管理的复杂性，你可能只需要使用React的内置Hook来管理你的状态。

然而，从React的大量状态管理解决方案中可以看出，内置的状态管理方法有时是不够的。让我们来看看其中的一些原因。

---

了解prop

让我们考虑一个稍微复杂的应用程序。随着你的应用程序的增长，你不得不创建多层的组件，以分离关注点和/或提高可读性。当你有多个组件需要的状态时，问题就出现了，这些组件在树上有不同的位置。

如果我们想给UserMenu和Profile组件提供用户数据，我们必须把状态放在App中，因为这是唯一能把数据传播到每个需要它的组件的地方。

这意味着我们将通过那些可能不需要这些数据的组件，比如说仪表盘和设置--将不必要的数据污染给它们。

现在，如果你需要在另一个组件中操作这些数据怎么办？那么，你就需要向需要进行更新的组件提供更新函数（上一个例子中的setUsers函数），增加另一个需要向下传播的属性--所有这些都是为了一个状态。现在想象一下，再增加五个属性就更复杂了。它很快就会失去控制。

对我来说，这意味着我对通过多层组件来更新器函数有多舒服。就我个人而言，我对三层有一个硬性的限制；在那之后，我就会去找另一个解决方案。但在那之前，我坚持使用React的内置功能。

状态库也是有成本的，除非你确定绝对需要，否则没有理由增加不必要的复杂性。

重新渲染的问题

由于React在状态更新后会自动触发重新渲染，所以一旦应用程序增长，内部状态处理就会出现问题。组件树的不同分支可能需要相同的数据，而为这些组件提供相同数据的唯一方法是将状态提升到最近