3

React 是一个视图层框架,其核心思想是 UI = f(state),即「UI 是 state 的投影」,state 自上而下流动,整个 React 组件树由 state 驱动。当一个 React 应用程序足够复杂,组件嵌套足够深时,组件树中的状态流动会变得难以控制(例如你如何跟踪父节点的 state 流动到叶子节点时产生的变化)。这时我们就需要对 state 进行管理,在进行状态管理的同时,还需要分清 React 应用中有哪些状态类型,方便制定出最适合的状态管理方案。

状态类型

React 应用程序状态从宏观意义上讲可以分为两类:

  1. 客户端状态 Client State:多数用于控制客户端的 UI 展示,如下文将介绍到的 Local state、Feature state、Application state 都属于客户端状态。
  2. 服务端状态 Server State:客户端通过异步请求获得的数据。

本地状态 - Local state

仅存在于单个组件中的状态,我们可以称之为「本地」或「UI」状态。

通常它可以帮助我们管理用户界面交互,例如显示和隐藏内容或启用和禁用按钮,它还经常在我们等待时控制渲染的内容。考虑以下示例:

function Text() {
  const [viewMore, setViewMore] = useState(false);
  return (
    <Fragment>
      <p>
        React makes it painless to create interactive UIs. 
        {
          viewMore && <span>
            Design simple views for each state in your application.
          </span>
        }
      </p>
      <button onClick={() => setViewMore(true)}>read more</button>
    </Fragment>
  )
}

viewMore 是一种仅对这个特定组件有意义的状态,它的作用是仅控制此处文本的可见性。

在此示例中, viewMore 对应用程序的其他组件对都是没用的,因此,您不必将此状态泄漏到 Text 组件之外。

特征状态 - Feature state

组合两个或多个组件,这些组件需要知道相同的信息,我们将这种状态定义为「特征」状态。

可以说,每一个非本地性的状态都属于这一类。然而,并非每个特征状态都是相同的,我们将在本文中进一步了解这一点。

特征状态的一个很好的例子是表单状态,它看起来有点像上面描述的 UI 状态,但它结合了多个输入,管理多个组件。

import { useState } from "react";
const Skill = ({ onChange }) => (
  <label>
    技能:
    <input type="text" onChange={(e) => onChange(e.target.value)} />
  </label>
);
const Years = ({ onChange }) => (
  <label>
    工龄:
    <input type="text" onChange={(e) => onChange(e.target.value)} />
  </label>
);

export default function Form() {
  const [skill, setSkill] = useState("");
  const [years, setYears] = useState("");

  const isFormReady = skill !== "" && years !== "";
  return (
    <form onSubmit={() => alert("提及成功")}>
      <Skill onChange={setSkill} /> <br />
      <Years onChange={setYears} />
      <button disabled={!isFormReady}>submit</button>
    </form>
  );
}

这里我们有一个 Form 表单,它包含两个字段 skillyears ,默认情况下,Form 表单的提交按钮处于禁用状态,仅当两个输入都有值时该按钮才变为启用状态,请注意 skillyears 都是必需的,以便我们可以计算 isFormReady 的值。Form 是实现此类逻辑的最佳场所,因为它包含了所有相关联的元素。

此示例体现了特征状态和应用状态之间的一个界限,在这里也可以使用 Redux 进行状态管理,但是这不是一种好的做法,我们应该在它被提升并成为应用程序状态之前更早地识别特征状态

应用状态 - Application state

应用程序状态是引导用户整体体验的状态,这可能是授权状态、配置文件数据或全局样式主题。在应用程序的任何地方都可能需要它。下面是一个简单的示例:

import React, { useContext, useState } from "react";
const ThemeContext = React.createContext();
const Theme = ({ onChange }) => {
  const { theme } = useContext(ThemeContext);
  return `Theme: ${theme}`;
}
const ThemeSelector = () => {
  const { theme, toggleTheme } = useContext(ThemeContext);
  return (
    <select value={theme} onChange={toggleTheme}>
      <option value="light">light</option>
      <option value="dark">dark</option>
    </select>
  );
}
export default function App() {
  const [theme, setTheme] = useState("light");
  const toggleTheme = () => setTheme(theme === "light" ? "dark" : "light");
  const themeStyle = {
    background: theme === "light" ? "#fff" : "#b9b9b9"
  };
  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      <div className="App">
        <header style={themeStyle}>
          <Theme />
        </header>
        <footer style={themeStyle}>
          <ThemeSelector />
        </footer>
      </div>
    </ThemeContext.Provider>
  );
}

这个例子中,有一个页头和一个页脚,他们都需要知道当前应用程序的主题。我们通过使用 Context API 将 theme 设置为应用状态,这样做的目的以便于 ThemeThemeSelector 也能轻松的访问(它们也需要访问 theme,但它们有可能嵌套于其他组件之中)。

如果某些属性许多组件都需要,并且可能需要从远程组件进行更新,那么我们可能必须将其设置为应用程序状态。

服务器状态 - Server state

服务器状态可以理解为接口状态,服务端状态有以下特点:存储在远端,本地无法直接控制、需要异步 API 来查询和更新、可能在不知情的情况下,被另一个请求方更改了数据,导致数据不同步等。

现有的状态管理库(如 Mobx、Redux 等)适用于管理客户端状态,但它们并不关心客户端是如何异步请求远端数据的,所以他们并不适合处理异步的、来自服务端的状态。

要识别服务器状态,您必须考虑数据更改的频率以及这些数据的来源。如果它或多或少是静态的,那么我们应该避免从服务端获取,只需将其存储到客户端并将其作为全局变量传递。

状态管理

随着 React 生态不断壮大,社区中提供了多种方式来解决状态管理,有基于 Flux 思想的 Redux、Zustand 以及 React 自带的 useReducer + Context;有基于原子化的 Recoil、Jotail 等;还有响应式方案的代表 Mobx,在这里不过多针对介绍,我们来了解一些最常用的。

Hooks 是状态管理的主要机制

useStateuseReducer 是大多数人用来管理本地状态的方式,useState 实际上是 React 中重新渲染的主要机制,这也是为什么大多数状态管理库都在底层使用它的原因。如果深入研究,你会发现这些不同的第三方库提供的 Custom Hooks 都依赖于默认的 useStateuseReduceruseffect,下面是官网提供的一个 useReducer 的简单示例:

const initialState = {count: 0};

function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      throw new Error();
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
    </>
  );
}

状态提升 - Lifting State Up

在 React 中,将多个组件中需要共享的 state 向上移动到它们的最近共同父组件中,便可实现共享 state,这就是所谓的「状态提升」。

回顾一下本文开头的 view-more 示例(本地状态来控制文本的可见性)。但是,如果有一个新的要求,我们有一个全局的「展开文本」按钮,然后我们必须把这个状态提升,然后通过 props 传递下去。

// viewMore 是一个 local state
function Component() {
  const [viewMore, setViewMore] = useState(false);
  return (
    <Fragment>
      <p>Text... { viewMore && <span>More text ...</span>}</p>
      <button onClick={() => setViewMore(true)}>read more</button>
    </Fragment>
  );
}

// 将 viewMore 提升为组件的 feature state
function Component({ viewMore }) {
  return (
    <p>Text... { viewMore && <span>More text ...</span>}</p>
  );
}

当您看到一个局部状态变量变成一个 props 时,我们就可以视其为状态提升。这种方式的需要注意在 prop drilling 方面的找到平衡,您也不希望有许多只是负责将 props 传递给他们子组件的「中间人」组件。

使用 Context API

Context API 提供了一种通过组件树传递数据的方法,而无需在每个级别手动向下传递 props。

在典型的 React 应用程序中,数据通过 props 自上而下(父级到子级)传递,但这种做法对于某些类型的 props 而言是极其繁琐的(例如:地区偏好,UI 主题),这些属性是应用程序中许多组件都需要的。Context 提供了一种在组件之间共享此类值的方式,而不必显式地通过组件树的逐层传递 props。

Context 设计目的是为了共享那些对于一个组件树而言是「全局」的数据,例如当前认证的用户、主题或首选语言,因此 Context 主要应用于应用状态的管理(见应用状态示例)。

如果你只是想避免层层传递一些属性,组件组合(component composition)有时候是一个比 context 更好的解决方案。

组合模式 - Composition mode

Context API 适合管理应用状态,如果想避免 Props Drilling 等问题,可以采用组合模式。组合是一种通过将各组件联合在一起以创建更大组件的方式,组合不仅具有多变的灵活性和可重用性,还具有单一职责的特性,组合也是 React 的核心。 看一个官网的示例:

function SplitPane(props) {
  return (
    <div className="SplitPane">
      <div className="SplitPane-left">
        {props.left}
      </div>
      <div className="SplitPane-right">
        {props.right}
      </div>
    </div>
  );
}

function App() {
  return (
    <SplitPane
      left={
        <Contacts />
      }
      right={
        <Chat />
      } />
  );
}

示例中没有使用 children,而是自行约定将 ContactsChat 两个组件通过 props.left/props.right 传入,被传递的组件同父组件组成了更加复杂的组件,虽然被组合在一起,但各个成员组件都具有单一职责。

client-server 方式

这种方式体现在 ApolloReactQuery 中,基本上都是在应用程序中添加一个 layer/client 并由其负责从外部源请求/缓存数据。

它们带有一些不错的 hooks,对于客户端来说,这种方式看起来很像使用本地状态,它消除了数据存储和获取的繁杂性。下面是 Apollo 和 ReactQuery 的简单示例:

// Apollo 
import { useQuery, gql } from '@apollo/client';

// 在这个例子中,我们使用了 GraphQL
const EXCHANGE_RATES = gql`
  query GetExchangeRates {
    rates(currency: "USD") {
      currency
      rate
    }
  }
`;

function ExchangeRates() {
  const { loading, error, data } = useQuery(EXCHANGE_RATES);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error :(</p>;

  return data.rates.map(({ currency, rate }) => (
    <div key={currency}>
      <p>
        {currency}: {rate}
      </p>
    </div>
  ));
}
// ReactQuery
import React from "react";
import ReactDOM from "react-dom";
import { QueryClient, QueryClientProvider, useQuery } from "react-query";

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  );
}

function Example() {
  const { isLoading, error, data, isFetching } = useQuery("repoData", () =>
    fetch(
      "https://api.github.com/repos/tannerlinsley/react-query"
    ).then((res) => res.json())
  );

  if (isLoading) return "Loading...";
  if (error) return "An error has occurred: " + error.message;

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{" "}
      <strong>✨ {data.stargazers_count}</strong>{" "}
      <strong>🍴 {data.forks_count}</strong>
      <div>{isFetching ? "Updating..." : ""}</div>
    </div>
  );
}

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

从例子中我们发现,前端负责指定如何获取数据,其余的都取决于 Apollo/ReactQuery 客户端,包括前端需要的 loading 和一个 error 两种状态都由后端提供并管理。这使得前端拥有一个状态,但实际上允许在后端管理该状态,是一种有趣的结合。

结论

状态管理很复杂,状态管理没有最好的方案,只有最合适的方案。

关于第三方状态管理库推荐阅读 56 个 NPM 包解决 16 个 React 问题 里的小节。

参考:
https://krasimirtsonev.com/bl...
https://www.sytone.me/b-syste...


破晓L
2.1k 声望3.6k 粉丝

智慧之子 总以智慧为是