状态管理

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

理解 React 中的状态管理

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

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

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

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

React Router 如何简化状态

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

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

网络相关状态： 如果你的 React 状态正在管理任何与网络相关的事情——例如来自 loader 的数据、待处理的表单提交或导航状态——那么你很可能正在管理 React Router 已经管理的状态。
- useNavigation：此钩子让你能够访问 navigation.state、navigation.formData、navigation.location 等。
- useFetcher：这有助于与 fetcher.state、fetcher.formData、fetcher.data 等进行交互。
- loaderData：访问路由的数据。
- actionData：访问最新 action 的数据。
在 React Router 中存储数据： 许多开发人员可能倾向于存储在 React 状态中的数据，在 React Router 中有更自然的位置，例如：
- URL 搜索参数： URL 中用于保存状态的参数。
- Cookies： 存储在用户设备上的小块数据。
- 服务器会话： 服务器管理的用户会话。
- 服务器缓存： 服务器端缓存的数据，以便更快地检索。
性能考虑： 有时，利用客户端状态来避免多余的数据获取。使用 React Router，你可以在 loader 中使用 Cache-Control 标头，从而利用浏览器的原生缓存。然而，这种方法有其局限性，应谨慎使用。优化后端查询或实现服务器缓存通常更有益。这是因为这样的更改对所有用户都有好处，并且消除了对单个浏览器缓存的需求。

作为一名过渡到 React Router 的开发人员，认识并拥抱其固有的效率至关重要，而不是应用传统的 React 模式。React Router 提供了一种简化的状态管理解决方案，从而减少了代码量，保证了数据的新鲜度，并且没有状态同步的 bug。

示例

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

URL 搜索参数

考虑一个允许用户自定义列表视图或详细视图的 UI。你的本能可能是使用 React state：

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。我们有三种方法来处理这个状态：

React state
浏览器本地存储
Cookies

在这次讨论中，我们将分解与每种方法相关的权衡。

React State

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

优点:

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

缺点:

短暂：在页面刷新、稍后返回页面或组件卸载和重新挂载后无法保留。

实现:

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 组件必须与本地存储同步以初始化和保存当前状态。
服务器渲染限制：在服务器端渲染期间无法访问 window 和 localStorage 对象，因此状态必须在浏览器中使用 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 state 会导致错误，因为 window.localStorage 在服务器渲染期间不可用。

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

  // ...
}

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

Cookies

Cookies 为此用例提供了一个全面的解决方案。然而，这种方法在使状态在组件内可访问之前，引入了额外的初步设置。

优点:

服务器渲染：状态在服务器上可用于渲染，甚至可用于服务器操作。
单一事实来源：消除了状态同步的麻烦。
持久性：在页面加载和组件挂载/卸载时保持状态。如果切换到数据库支持的会话，状态甚至可以在设备之间持久化。
渐进增强：甚至在 JavaScript 加载之前就能工作。

缺点:

样板代码：由于网络原因，需要更多代码。
暴露：状态没有封装到单个组件中，应用程序的其他部分必须知道 cookie 的存在。

实现:

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

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

接下来我们设置服务器 action 和 loader 来读写 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>
  );
}

虽然这无疑是更多的代码，涉及到应用程序的更多部分来处理网络请求和响应，但用户体验得到了极大的改善。此外，状态来自单一事实来源，无需任何状态同步。

总而言之，所讨论的每种方法都提供了一系列独特的优点和挑战：

React state：提供简单但短暂的状态管理。
本地存储：提供持久性，但有同步要求和 UI 闪烁问题。
Cookies：以增加样板代码为代价，提供强大、持久的状态管理。

这些方法都没有错，但如果你想在多次访问之间持久化状态，cookies 提供了最佳的用户体验。

表单验证和操作数据

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

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

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 state、change 事件监听器、submit 处理程序和状态管理库的需求。

通过 actionData 可以直接访问服务器状态，通过 useNavigation（或 useFetcher）可以访问网络状态。

作为一个额外的彩蛋，表单甚至在 JavaScript 加载之前就可以工作（参见渐进增强）。取代 React Router 管理网络操作的是默认的浏览器行为。

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