状态管理
本页内容

状态管理

React 中的状态管理通常涉及在客户端维护服务器数据的同步缓存。然而,当使用 React Router 作为框架时,由于其固有的数据同步处理方式,大多数传统的缓存解决方案变得多余。

理解 React 中的状态管理

在一个典型的 React 上下文中,当我们提到“状态管理”时,我们主要讨论的是如何将服务器状态与客户端同步。更恰当的术语可能是“缓存管理”,因为服务器是真理的来源,而客户端状态主要充当缓存的角色。

React 中流行的缓存解决方案包括

  • Redux:一个用于 JavaScript 应用程序的可预测状态容器。
  • React Query:用于在 React 中获取、缓存和更新异步数据的 Hooks。
  • Apollo:一个全面的 JavaScript 状态管理库,与 GraphQL 集成。

在某些情况下,使用这些库可能是必要的。然而,由于 React Router 独特的以服务器为中心的方法,它们的实用性变得不那么普遍。事实上,大多数 React Router 应用程序完全放弃了它们。

React Router 如何简化状态

React Router 通过加载器、actions 和表单等机制无缝地弥合了后端和前端之间的差距,并通过重新验证实现自动同步。这使开发人员能够在组件中直接使用服务器状态,而无需管理缓存、网络通信或数据重新验证,从而使大多数客户端缓存变得多余。

以下是为什么在 React Router 中使用典型的 React 状态模式可能是一种反模式的原因

  1. 网络相关状态:如果你的 React 状态正在管理任何与网络相关的内容——例如来自加载器的数据、待处理的表单提交或导航状态——那么你很可能正在管理 React Router 已经管理的状态

    • useNavigation:此 Hook 使您可以访问 navigation.statenavigation.formDatanavigation.location 等。
    • useFetcher:这有助于与 fetcher.statefetcher.formDatafetcher.data 等交互。
    • loaderData:访问路由的数据。
    • actionData:访问来自最新 action 的数据。
  2. 在 React Router 中存储数据:开发人员可能倾向于存储在 React 状态中的许多数据在 React Router 中有更自然的归宿,例如

    • URL 搜索参数:URL 中保存状态的参数。
    • Cookies存储在用户设备上的小数据片段。
    • 服务器会话服务器管理的用户会话。
    • 服务器缓存:服务器端缓存的数据,用于更快地检索。
  3. 性能考虑:有时,利用客户端状态来避免冗余数据获取。使用 React Router,您可以在加载器中使用 Cache-Control 标头,从而利用浏览器的原生缓存。但是,这种方法有其局限性,应谨慎使用。通常,优化后端查询或实现服务器缓存更有益。这是因为这些更改使所有用户受益,并且无需使用个人浏览器缓存。

作为过渡到 React Router 的开发人员,至关重要的是认识并接受其固有的效率,而不是应用传统的 React 模式。React Router 为状态管理提供了简化的解决方案,从而减少了代码、更新鲜的数据,并且没有状态同步错误。

示例

有关使用 React Router 的内部状态来管理网络相关状态的示例,请参阅 Pending UI。

URL 搜索参数

考虑一个 UI,让用户可以在列表视图或详细视图之间自定义。您的直觉可能是使用 React 状态

export function List() {
  const [view, setView] = useState("list");
  return (
    <div>
      <div>
        <button onClick={() => setView("list")}>
          View as List
        </button>
        <button onClick={() => setView("details")}>
          View with Details
        </button>
      </div>
      {view === "list" ? <ListView /> : <DetailView />}
    </div>
  );
}

现在考虑一下,当用户更改视图时,您希望 URL 更新。请注意状态同步

import { useNavigate, useSearchParams } from "react-router";

export function List() {
  const navigate = useNavigate();
  const [searchParams] = useSearchParams();
  const [view, setView] = useState(
    searchParams.get("view") || "list"
  );

  return (
    <div>
      <div>
        <button
          onClick={() => {
            setView("list");
            navigate(`?view=list`);
          }}
        >
          View as List
        </button>
        <button
          onClick={() => {
            setView("details");
            navigate(`?view=details`);
          }}
        >
          View with Details
        </button>
      </div>
      {view === "list" ? <ListView /> : <DetailView />}
    </div>
  );
}

您可以直接使用普通的旧 HTML 表单在 URL 中读取和设置状态,而不是同步状态

import { Form, useSearchParams } from "react-router";

export function List() {
  const [searchParams] = useSearchParams();
  const view = searchParams.get("view") || "list";

  return (
    <div>
      <Form>
        <button name="view" value="list">
          View as List
        </button>
        <button name="view" value="details">
          View with Details
        </button>
      </Form>
      {view === "list" ? <ListView /> : <DetailView />}
    </div>
  );
}

持久化 UI 状态

考虑一个 UI,它可以切换侧边栏的可见性。我们有三种处理状态的方法

  1. React 状态
  2. 浏览器本地存储
  3. Cookies

在本次讨论中,我们将分析与每种方法相关的权衡。

React 状态

React 状态为临时状态存储提供了一个简单的解决方案。

优点:

  • 简单:易于实现和理解。
  • 封装:状态的作用域限定于组件。

缺点:

  • 瞬态:无法在页面刷新、稍后返回页面或卸载和重新挂载组件后继续存在。

实现:

function Sidebar() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setIsOpen((open) => !open)}>
        {isOpen ? "Close" : "Open"}
      </button>
      <aside hidden={!isOpen}>
        <Outlet />
      </aside>
    </div>
  );
}

本地存储

为了在组件生命周期之外持久化状态,浏览器本地存储是更进一步的选择。有关更高级的示例,请参阅我们关于客户端数据的文档。

优点:

  • 持久化:跨页面刷新和组件挂载/卸载维护状态。
  • 封装:状态的作用域限定于组件。

缺点:

  • 需要同步:React 组件必须与本地存储同步以初始化和保存当前状态。
  • 服务器渲染限制:在服务器端渲染期间,windowlocalStorage 对象不可访问,因此状态必须在浏览器中使用 effect 初始化。
  • UI 闪烁:在初始页面加载时,本地存储中的状态可能与服务器渲染的内容不匹配,并且当 JavaScript 加载时,UI 将会闪烁。

实现:

function Sidebar() {
  const [isOpen, setIsOpen] = useState(false);

  // synchronize initially
  useLayoutEffect(() => {
    const isOpen = window.localStorage.getItem("sidebar");
    setIsOpen(isOpen);
  }, []);

  // synchronize on change
  useEffect(() => {
    window.localStorage.setItem("sidebar", isOpen);
  }, [isOpen]);

  return (
    <div>
      <button onClick={() => setIsOpen((open) => !open)}>
        {isOpen ? "Close" : "Open"}
      </button>
      <aside hidden={!isOpen}>
        <Outlet />
      </aside>
    </div>
  );
}

在这种方法中,状态必须在 effect 中初始化。这对于避免服务器端渲染期间的并发症至关重要。直接从 localStorage 初始化 React 状态会导致错误,因为在服务器渲染期间 window.localStorage 不可用。

function Sidebar() {
  const [isOpen, setIsOpen] = useState(
    // error: window is not defined
    window.localStorage.getItem("sidebar")
  );

  // ...
}

通过在 effect 中初始化状态,服务器渲染的状态与本地存储中存储的状态之间可能存在不匹配。这种差异将导致页面渲染后不久出现短暂的 UI 闪烁,应避免这种情况。

Cookies

Cookies 为此用例提供了全面的解决方案。但是,此方法引入了额外的初步设置,然后才能在组件中访问状态。

优点:

  • 服务器渲染:状态在服务器上可用于渲染,甚至可用于服务器 action。
  • 单一真理来源:消除了状态同步的麻烦。
  • 持久性:跨页面加载和组件挂载/卸载维护状态。如果您切换到数据库支持的会话,状态甚至可以跨设备持久存在。
  • 渐进增强:即使在 JavaScript 加载之前也能工作。

缺点:

  • 样板代码:由于网络,需要更多代码。
  • 暴露:状态未封装到单个组件,应用程序的其他部分必须知道 cookie。

实现:

首先,我们需要创建一个 cookie 对象

import { createCookie } from "react-router";
export const prefs = createCookie("prefs");

接下来,我们设置服务器 action 和加载器以读取和写入 cookie

import { data, Outlet } from "react-router";
import type { Route } from "./+types/sidebar";

import { prefs } from "./prefs-cookie";

// read the state from the cookie
export async function loader({
  request,
}: Route.LoaderArgs) {
  const cookieHeader = request.headers.get("Cookie");
  const cookie = (await prefs.parse(cookieHeader)) || {};
  return data({ sidebarIsOpen: cookie.sidebarIsOpen });
}

// write the state to the cookie
export async function action({
  request,
}: Route.ActionArgs) {
  const cookieHeader = request.headers.get("Cookie");
  const cookie = (await prefs.parse(cookieHeader)) || {};
  const formData = await request.formData();

  const isOpen = formData.get("sidebar") === "open";
  cookie.sidebarIsOpen = isOpen;

  return data(isOpen, {
    headers: {
      "Set-Cookie": await prefs.serialize(cookie),
    },
  });
}

服务器代码设置完成后,我们可以在 UI 中使用 cookie 状态

function Sidebar({ loaderData }: Route.ComponentProps) {
  const fetcher = useFetcher();
  let { sidebarIsOpen } = loaderData;

  // use optimistic UI to immediately change the UI state
  if (fetcher.formData?.has("sidebar")) {
    sidebarIsOpen =
      fetcher.formData.get("sidebar") === "open";
  }

  return (
    <div>
      <fetcher.Form method="post">
        <button
          name="sidebar"
          value={sidebarIsOpen ? "closed" : "open"}
        >
          {sidebarIsOpen ? "Close" : "Open"}
        </button>
      </fetcher.Form>
      <aside hidden={!sidebarIsOpen}>
        <Outlet />
      </aside>
    </div>
  );
}

虽然这确实是更多代码,涉及到应用程序的更多部分来解释网络请求和响应,但 UX 大大提高。此外,状态来自单一真理来源,无需任何状态同步。

总而言之,所讨论的每种方法都提供了一组独特的优势和挑战

  • React 状态:提供简单但瞬态的状态管理。
  • 本地存储:提供持久性,但有同步要求和 UI 闪烁。
  • Cookies:提供强大、持久的状态管理,但代价是增加了样板代码。

这些方法都没有错,但是如果您想跨访问持久化状态,cookie 提供最佳的用户体验。

表单验证和 Action 数据

客户端验证可以增强用户体验,但通过更多地倾向于服务器端处理并让其处理复杂性,可以实现类似的增强。

以下示例说明了管理网络状态、协调来自服务器的状态以及在客户端和服务器端冗余地实现验证的固有复杂性。这仅用于说明,因此请原谅您发现的任何明显的错误或问题。

export function Signup() {
  // A multitude of React State declarations
  const [isSubmitting, setIsSubmitting] = useState(false);

  const [userName, setUserName] = useState("");
  const [userNameError, setUserNameError] = useState(null);

  const [password, setPassword] = useState(null);
  const [passwordError, setPasswordError] = useState("");

  // Replicating server-side logic in the client
  function validateForm() {
    setUserNameError(null);
    setPasswordError(null);
    const errors = validateSignupForm(userName, password);
    if (errors) {
      if (errors.userName) {
        setUserNameError(errors.userName);
      }
      if (errors.password) {
        setPasswordError(errors.password);
      }
    }
    return Boolean(errors);
  }

  // Manual network interaction handling
  async function handleSubmit() {
    if (validateForm()) {
      setSubmitting(true);
      const res = await postJSON("/api/signup", {
        userName,
        password,
      });
      const json = await res.json();
      setIsSubmitting(false);

      // Server state synchronization to the client
      if (json.errors) {
        if (json.errors.userName) {
          setUserNameError(json.errors.userName);
        }
        if (json.errors.password) {
          setPasswordError(json.errors.password);
        }
      }
    }
  }

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault();
        handleSubmit();
      }}
    >
      <p>
        <input
          type="text"
          name="username"
          value={userName}
          onChange={() => {
            // Synchronizing form state for the fetch
            setUserName(event.target.value);
          }}
        />
        {userNameError ? <i>{userNameError}</i> : null}
      </p>

      <p>
        <input
          type="password"
          name="password"
          onChange={(event) => {
            // Synchronizing form state for the fetch
            setPassword(event.target.value);
          }}
        />
        {passwordError ? <i>{passwordError}</i> : null}
      </p>

      <button disabled={isSubmitting} type="submit">
        Sign Up
      </button>

      {isSubmitting ? <BusyIndicator /> : null}
    </form>
  );
}

后端端点 /api/signup 也执行验证并发送错误反馈。请注意,一些必要的验证(例如检测重复用户名)只能在服务器端使用客户端无权访问的信息来完成。

export async function signupHandler(request: Request) {
  const errors = await validateSignupRequest(request);
  if (errors) {
    return { ok: false, errors: errors };
  }
  await signupUser(request);
  return { ok: true, errors: null };
}

现在,让我们将其与基于 React Router 的实现进行对比。action 保持不变,但由于通过 actionData 直接利用服务器状态以及利用 React Router 固有的网络状态,组件得到了极大的简化。

import { useNavigation } from "react-router";
import type { Route } from "./+types/signup";

export async function action({
  request,
}: ActionFunctionArgs) {
  const errors = await validateSignupRequest(request);
  if (errors) {
    return { ok: false, errors: errors };
  }
  await signupUser(request);
  return { ok: true, errors: null };
}

export function Signup({
  actionData,
}: Route.ComponentProps) {
  const navigation = useNavigation();

  const userNameError = actionData?.errors?.userName;
  const passwordError = actionData?.errors?.password;
  const isSubmitting = navigation.formAction === "/signup";

  return (
    <Form method="post">
      <p>
        <input type="text" name="username" />
        {userNameError ? <i>{userNameError}</i> : null}
      </p>

      <p>
        <input type="password" name="password" />
        {passwordError ? <i>{passwordError}</i> : null}
      </p>

      <button disabled={isSubmitting} type="submit">
        Sign Up
      </button>

      {isSubmitting ? <BusyIndicator /> : null}
    </Form>
  );
}

我们之前示例中的广泛状态管理被简化为仅三行代码。我们消除了 React 状态、更改事件侦听器、提交处理程序以及用于此类网络交互的状态管理库的必要性。

通过 actionData 可以直接访问服务器状态,通过 useNavigation(或 useFetcher)可以访问网络状态。

作为额外的技巧,即使在 JavaScript 加载之前,表单也是可用的(请参阅渐进增强)。不是由 React Router 管理网络操作,而是由默认浏览器行为介入。

如果您发现自己陷入管理和同步网络操作状态的困境,React Router 可能提供更优雅的解决方案。

文档和示例 CC 4.0