拒绝Redux？使用原生React管理状态

自从我们学习React的第一天起，我们就知道不要在React中使用太多状态。我们也知道应该尽可能多使用无状态的函数式组件，少使用有状态的类组件。

这些建议很容易让我们形成这样的判断，那就是我们完全不应该使用状态，当我们需要用到状态的时候，应该使用Redux之类的第三方状态管理库。

我们不喜欢使用React原生状态并不是没有原因的：

1. 当项目变大的时候，散落在许多组件中的局部状态很快会变得无法追踪；
2. 组件之间难以共享状态；
3. 从一个外部组件一层层将prop传递到内部组件很麻烦；这个问题被称作prop drilling；
4. 状态逻辑通常和UI逻辑混合在一起，导致调试和重用状态逻辑都很困难；
5. 在编译时，类组件比函数式组件更难优化。

严格来讲，prop drilling并不属于状态的问题，而是一个设计失误。它通常是由过多的不必要封装导致的。

Redux的优缺点

Redux是最流行的状态管理库，它通过将状态与UI隔离并中心化管理的方式减轻了以上所说的这些痛点。

它的整个逻辑十分简单，但却蕴含着强大的扩展性。我们可以用一个单向数据流图来描述Redux背后的运行机制：

除了store自身，所有其他的组件都是纯函数。这是一个函数式编程中的概念，指的是函数的结果只取决于函数的输入，而不取决于任何其他的状态。

纯函数更容易测试、理解和调试。通过强制使用函数式编程这一编程风格，Redux减少了维护状态逻辑的负担。

然而，Redux也有自己特有的麻烦。一个人们广为诟病的问题就是在搭建项目初期，它需要写太多样板代码。

对于小项目而言，这个问题尤为严重。添加一个新的action通常需要我们定一个新action、添加一个新action creator、修改reducer、更新container等一系列操作。为了完成这个功能，我们需要在许多个不同的文件之间跳转，最后把一个5行之内可以做完的事情扩展成20行。

甚至说，我们到底要不要中心化的store也是一个值得讨论的问题，就像我们要不要用全局变量一样。

和局部状态相比，全局状态更难重用。重构全局状态可能会意外地导致部分现有代码不可用。不合理地使用Redux container也会有性能问题。

在另一边，近几年React为了让状态管理更好用做出了许多努力，引入了Context API和Hooks等新特性来解决过去的痛点。

原生React

React支持两种组件：类组件（支持状态和hook，也就是componentDidMount等函数）和函数式组件（不支持状态，更加简单）。

在过去，如果我们想使用函数式组件，又想维护某些内部状态，唯一的办法就是使用Redux之类的状态管理库。

在React增加了Context API和hooks之后，我们有了更多的选择。

因为这两个新API是React官方支持的，我建议在使用第三方的状态管理库之前，先了解一下它们再做决定。

React Hooks

React hooks API提供了一种在函数式组件中管理状态的方法。

这句话第一眼看上去自相矛盾，因为函数式在某种程度上就意味着无状态。但是，我们先将这一问题搁置在一边，只把函数式组件当作一种设计模式来看待。

和类组件相比，函数式组件有更紧凑的形式，需要更少的样板代码，更可读，对编译器来说也更容易分析和优化。

然而，不能够在函数式组件中维护状态为我们带来了极大的不便：即使是引入一个boolean这样小的状态，都需要我们将整个函数式组件重写为类组件。

React hooks API通过允许我们在函数式组件中使用状态来解决了这个困境。而且，它也允许我们将状态逻辑从UI逻辑中剥离出来，重用到其他的UI组件中。

下面这个简短的例子展示了我们如何在函数式组件中使用React hooks：

import React, { useState } from 'react'

const Counter: React.FC = () => {
  const [counter, setCounter] = useState(0)
  return (
    <div>
      <p>Counter: {counter}</p>
      <button onClick={() => setCounter(counter + 1)}>
        Increment
      </button>
    </div>
  )
}

useState返回当前状态和一个函数（这个函数可以用来更新状态），它的参数是初始状态。这个函数第一次被调用的时候，它将组件的内部状态初始化为给定的初始值。

这个状态是维护在这个组件之内的，不会被同一个组件的多个实例之间共享。

我们可以在一个函数式组件中调用useState许多次。React hooks API鼓励我们将一个复杂的状态分解成多个可重用的简单状态。

我们可以进一步将状态逻辑封装在单独的函数中（称为custom hook），以便我们在其他组件中重用这个状态逻辑：

import React, {useState} from 'react'

// A custom hook
const useCounter = (initial: number) => {
  const [counter, setCounter] = useState(initial)

  return {
    counter,
    increment () {
      setCounter(counter + 1)
    },
    reset () {
      setCounter(initial)
    }
  }
}

const Counter: React.FC = () => {
  const { counter, increment, reset } = useCounter(0)
  return (
    <div>
      <p>Counter: {counter}</p>
      <button onClick={increment}>
        Increment
      </button>
      <button onClick={reset}>
        Reset
      </button>
    </div>
  )
}

每一个使用setState的地方，我们都可以用React hooks代替，因为React hooks全方面地超越了原来的setState：它允许将一个组件的状态拆分成小的可重用的状态，鼓励我们多用函数式组件，少用类组件。

React Context API

React Context API比React hooks更早引入React，但是它是用来解决一个完全不同的问题的：状态共享和prop drilling。

这个功能可能会让你联想到Redux的用途，但是React Context API事实上并不鼓励用它来维护一个巨大的中心化store。官方文档中说到：

Context主要是用在数据需要被不同层次的多个组件访问的时候。尽可能少用它，因为它会使组件重用更加困难。

React Context API和React hooks的设计哲学是相同的，那就是尽可能避免状态共享。

我们不得不使用React Context API的典型场景有：

• 用户登录信息；
• UI主题；
• locale设置。

例如，我们可以通过把UI主题放到Context中的方法来避免手动逐层传递：

import React, { useContext } from 'react'

const ThemeContext = React.createContext('light')

const UserComponent: React.FC = () => {
  const theme = useContext(ThemeContext)
  return (
    <div>
      Current theme: {theme}
    </div>
  )
}

const App: React.FC = () => {
  return (
    <ThemeContext.Provider value="dark">
      <UserComponent />
    </ThemeContext.Provider>
  )
}

通过合理地组合React Context API和React hooks，我们可以在完全不用Redux的情况下管理程序状态。

然而，就像编程世界中的其他开放性问题一样，状态管理也没有万金油。具体怎么做取决于业务逻辑的复杂性、程序的规模和其他各种因素。

我们应该在实际中选择最合适的方法。我的建议是，在项目初期，可以使用Context API和React hooks作为开始，随着项目的进行，只在必要的时候才引入Redux。