手写逻辑：实现一个 `useConcurrentEffect`，它支持在渲染被中断时自动撤销已执行的部分操作 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

React 并发模式下的副作用管理：构建 `useConcurrentEffect`

欢迎各位来到本次关于React高级副作用管理的讲座。今天，我们将深入探讨在React的并发模式下，如何实现一个能够自动撤销未完成操作的自定义Hook——useConcurrentEffect。随着React并发特性（Concurrent Features）的普及，我们编写组件的方式正在发生深刻的变化。传统的useEffect虽然强大，但在处理可能被中断的异步操作时，其局限性也日益凸显。理解并克服这些局限性，是构建响应更快、更健壮应用程序的关键。

1. 并发模式与副作用管理的挑战

React的并发模式旨在让应用在处理复杂更新时保持UI的响应性。它允许React在后台准备多个版本的UI，甚至在渲染过程中暂停、恢复或放弃工作，以便优先处理用户交互或更高优先级的更新。这种灵活性带来了巨大的性能优势，但也对副作用管理提出了新的挑战。

传统的 useEffect 存在的问题：

考虑一个常见的场景：数据获取。我们通常在useEffect中发起网络请求。

import React, { useState, useEffect } from 'react';

function MyComponent({ userId }) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    setError(null);
    setData(null);

    let ignore = false; // Flag to ignore stale results

    fetch(`https://api.example.com/users/${userId}`)
      .then(response => {
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        return response.json();
      })
      .then(json => {
        if (!ignore) { // Check flag before updating state
          setData(json);
        }
      })
      .catch(err => {
        if (!ignore) {
          setError(err);
        }
      })
      .finally(() => {
        if (!ignore) {
          setLoading(false);
        }
      });

    return () => {
      ignore = true; // Set flag to ignore results if component unmounts or deps change
    };
  }, [userId]);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  return <p>User data: {JSON.stringify(data)}</p>;
}

这段代码已经包含了一个常见的模式：使用ignore标志来避免在组件卸载或userId快速变化时更新陈旧的状态。这解决了“竞态条件”（Race Condition）问题，即旧的请求结果可能在新的请求之后才返回，导致UI显示错误的数据。

然而，这种方法仅仅是“忽略”了陈旧的结果，并没有真正“取消”正在进行的网络请求。如果fetch操作是一个耗时且资源密集型的任务，那么即使结果被忽略，后台的请求仍然会完成，浪费了带宽和CPU周期。在并发模式下，当React可能频繁地中断和重新启动渲染时，这种浪费会变得更加显著。一个渲染可能被中断，一个新的渲染开始，又被中断，如此反复，导致大量无用的后台工作。

我们需要一种机制，不仅能阻止陈旧的状态更新，还能在渲染被中断或依赖项改变时，自动撤销那些已经开始但尚未完成的副作用操作。这就是useConcurrentEffect要解决的核心问题。

2. `useEffect`的局限性与 `AbortController`

在深入useConcurrentEffect的实现之前，我们先回顾一下useEffect的生命周期和AbortController这个强大的Web API。

2.1 `useEffect`的生命周期

useEffect是一个在React组件渲染提交（commit）到DOM之后运行的Hook。它的典型签名是 useEffect(setup, dependencies)。

首次渲染（Mount）: setup函数被调用。
后续渲染（Update）:
- 如果dependencies数组中的任何值与上次渲染相比发生变化，则上一次setup函数返回的清理函数（cleanup function）会被调用。
- 然后，当前的setup函数被调用。
组件卸载（Unmount）: 上次setup函数返回的清理函数会被调用。

useEffect的清理机制非常适合处理订阅、计时器、事件监听器等需要在组件生命周期内创建和销毁的资源。然而，它的清理逻辑是“滞后”的：它只在“旧的”副作用已经被完全设置并运行了一段时间后，或者组件即将卸载时才触发。对于正在进行中的异步操作，useEffect本身无法在它们开始执行之后，但在它们完成之前提供一个中断信号。

2.2 `AbortController`：异步操作的取消利器

AbortController是一个Web API，它提供了一种统一的方式来取消异步操作，如fetch请求、FileReader操作、Promise链等。

一个AbortController实例包含两个主要部分：

controller.signal: 一个AbortSignal对象，可以传递给支持取消的异步API。当异步操作收到这个信号时，它可以检查信号的状态（signal.aborted）或监听abort事件。
controller.abort(): 调用此方法会触发signal上的abort事件，并将signal.aborted设置为true。

使用 AbortController 改进数据获取：

import React, { useState, useEffect } from 'react';

function MyCancellableComponent({ userId }) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController(); // Create a new controller
    const signal = controller.signal;

    setLoading(true);
    setError(null);
    setData(null);

    fetch(`https://api.example.com/users/${userId}`, { signal }) // Pass the signal
      .then(response => {
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        return response.json();
      })
      .then(json => {
        setData(json);
      })
      .catch(err => {
        if (err.name === 'AbortError') { // Check if it was an intentional abort
          console.log('Fetch aborted');
          return;
        }
        setError(err);
      })
      .finally(() => {
        setLoading(false);
      });

    return () => {
      controller.abort(); // Abort the fetch when dependencies change or component unmounts
    };
  }, [userId]);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  return <p>User data: {JSON.stringify(data)}</p>;
}

这个改进后的组件利用AbortController真正地取消了正在进行的fetch请求。当userId改变或组件卸载时，useEffect的清理函数会调用controller.abort()，导致fetch Promise被拒绝并抛出AbortError，从而停止网络请求，节省资源。

这已经非常接近我们useConcurrentEffect的目标了，但还缺少对渲染被中断的更精细控制。

3. `useConcurrentEffect` 的核心理念与 API 设计

我们的目标是创建一个 useConcurrentEffect Hook，它不仅能像上述useEffect示例那样取消已提交的副作用，还能处理React并发模式下渲染被中断（abandoned render）的情况。当一个渲染被中断时，它所关联的副作用操作（即使尚未完全启动，但可能已准备好其取消信号）也应该被及时取消。

3.1 核心理念

即时取消（Immediate Cancellation）: 当组件的依赖项发生变化，或者React决定放弃当前正在进行的渲染（转而处理更高优先级的更新）时，任何与旧渲染或被放弃渲染相关的未完成副作用都应立即被取消。
信号驱动（Signal-Driven）: 采用AbortSignal作为标准的取消机制，使其能与现代Web API无缝集成，并为自定义异步操作提供统一的取消接口。
生命周期管理（Lifecycle Management）: useConcurrentEffect需要管理AbortController的整个生命周期，确保在正确的时间创建、传递信号和调用abort()。

3.2 API 设计

useConcurrentEffect的API应该与useEffect相似，但在回调函数中额外提供一个AbortSignal：

type EffectCallbackWithSignal = (signal: AbortSignal) => (() => void) | void;

function useConcurrentEffect(
  effect: EffectCallbackWithSignal,
  deps: React.DependencyList | undefined
): void;

effect: 这是一个回调函数，它接收一个AbortSignal作为参数。用户在这个函数内部启动他们的副作用操作，并确保这些操作能响应signal的取消事件。这个函数可以选择返回一个清理函数，用于清理effect内部的同步资源（例如，setTimeout的ID）。
deps: 依赖项数组，与useEffect的deps相同。当依赖项变化时，useConcurrentEffect会重新执行。

4. `useConcurrentEffect` 的实现策略

为了实现useConcurrentEffect，我们需要巧妙地结合useRef、useLayoutEffect和AbortController。

useRef: 用于在组件的多次渲染之间持久化AbortController实例和相关的清理函数。我们需要两个useRef：
- currentEffectRef: 存储当前已提交（committed）的副作用的AbortController和其清理函数。
- nextEffectRef: 存储当前正在渲染（pending）的副作用的AbortController。这个Ref是实现“渲染中断时自动撤销”的关键。
useLayoutEffect: 这是一个在DOM更新后同步执行的Hook，但在浏览器绘制之前。它的清理函数在每次依赖项变化时，在新副作用设置之前运行。这使得useLayoutEffect非常适合管理副作用的精确生命周期，尤其是在需要防止视觉跳动或确保DOM同步更新的场景。在我们的useConcurrentEffect中，它将负责：
- 清理上一个已提交的副作用。
- 执行当前副作用的回调函数。
- 返回一个清理函数，用于在依赖项再次变化或组件卸载时清理当前的副作用。

4.1 逐步构建 `useConcurrentEffect`

让我们逐步构建useConcurrentEffect的实现。

import { useRef, useLayoutEffect } from 'react';

type EffectCallbackWithSignal = (signal: AbortSignal) => (() => void) | void;

interface CurrentEffectState {
  controller: AbortController;
  cleanup: (() => void) | void;
}

export function useConcurrentEffect(
  effect: EffectCallbackWithSignal,
  deps: React.DependencyList | undefined
) {
  // currentEffectRef: 存储当前“已提交”的副作用的状态（AbortController和用户提供的清理函数）。
  // 这个Ref在每次useLayoutEffect执行并成功设置新副作用后更新。
  const currentEffectRef = useRef<CurrentEffectState | null>(null);

  // nextEffectRef: 存储当前“正在渲染”的副作用的AbortController。
  // 这个Ref在组件每次渲染时更新，但在useLayoutEffect执行之前。
  // 它的目的是捕获因渲染被中断而未提交的AbortController，并在下一次渲染时对其进行清理。
  const nextEffectRef = useRef<AbortController | null>(null);

  // 1. 在组件的**渲染阶段**创建一个新的 AbortController。
  // 每次组件渲染时，都会为潜在的新副作用创建一个新的取消信号。
  const newController = new AbortController();
  const newSignal = newController.signal;

  // 2. 处理“渲染被中断”的场景：
  // 如果 nextEffectRef.current 存在，意味着上一次渲染创建了一个 AbortController
  // 但该渲染最终被中断（未提交），因此其 useLayoutEffect 未执行。
  // 在当前渲染继续之前，我们立即中止上一个未提交的 AbortController。
  if (nextEffectRef.current) {
    nextEffectRef.current.abort();
    // 注意：这里我们只中止 AbortController。用户副作用的回调函数并未执行，
    // 因此没有需要执行的同步清理函数。
  }
  // 将当前渲染的 newController 存储为“下一个待处理”的控制器。
  nextEffectRef.current = newController;

  // 3. useLayoutEffect 在 DOM 更新后同步执行，但浏览器绘制之前。
  // 这是我们执行用户副作用回调并管理其生命周期的理想位置。
  useLayoutEffect(() => {
    // 关键检查：确保当前 useLayoutEffect 对应的是最新一次成功的渲染。
    // 在并发模式下，一个组件的渲染函数可能执行多次，但只有一次会最终提交。
    // 如果 nextEffectRef.current 已经不是 newController，说明有更高优先级的渲染
    // 已经接管，或者当前这个渲染已经被废弃。在这种情况下，我们不应该继续设置副作用。
    if (nextEffectRef.current !== newController) {
      // 这里的 newController 已经不是最新的了，它可能已经被上一次渲染的 nextEffectRef.current.abort() 终止。
      // 或者它属于一个已被废弃的渲染路径。
      // 因此，我们直接返回，不执行任何副作用设置。
      return;
    }

    // 如果代码执行到这里，说明 newController 确实是当前成功提交的渲染所对应的控制器。
    // 将 nextEffectRef.current 清空，因为它已经从“待处理”变为“已提交”。
    nextEffectRef.current = null;

    // 首先，清理上一个“已提交”的副作用。
    // 这对应于 useEffect 的清理逻辑：在依赖项变化时，先清理旧的，再设置新的。
    if (currentEffectRef.current) {
      currentEffectRef.current.controller.abort(); // 中止上一个副作用的 AbortController
      if (currentEffectRef.current.cleanup) {
        currentEffectRef.current.cleanup(); // 执行用户提供的同步清理函数
      }
      currentEffectRef.current = null; // 清空引用，准备存储新的副作用
    }

    // 现在，执行用户提供的副作用回调函数，并传入当前渲染的 AbortSignal。
    const cleanup = effect(newSignal);

    // 将当前副作用的状态存储到 currentEffectRef 中，标记为“已提交”。
    currentEffectRef.current = { controller: newController, cleanup };

    // useLayoutEffect 的清理函数。
    // 它会在组件卸载时，或在依赖项再次变化、当前 useLayoutEffect 再次执行前被调用。
    return () => {
      // 再次检查，确保要清理的是当前 active 的副作用。
      // 这可以防止在快速连续的更新中，清理函数被错误地调用。
      if (currentEffectRef.current?.controller === newController) {
        currentEffectRef.current.controller.abort(); // 中止当前副作用的 AbortController
        if (currentEffectRef.current.cleanup) {
          currentEffectRef.current.cleanup(); // 执行用户提供的同步清理函数
        }
        currentEffectRef.current = null; // 清空引用
      }
    };
  }, deps); // 依赖项数组，控制 useLayoutEffect 的重新执行时机
}

4.2 逻辑分析与并发行为

为了更好地理解useConcurrentEffect如何处理并发行为，我们来分析几个关键场景：

场景 1: 组件首次挂载

渲染阶段: MyComponent首次渲染，useConcurrentEffect被调用。
- newController (AC1) 被创建。
- nextEffectRef.current 为 null。
- nextEffectRef.current 被设置为 AC1。
提交阶段 (useLayoutEffect 执行):
- nextEffectRef.current === newController (AC1 === AC1) 为 true。nextEffectRef.current 被设为 null。
- currentEffectRef.current 为 null。
- effect(AC1.signal) 被调用，返回用户提供的清理函数 cleanupA。
- currentEffectRef.current 被设为 { controller: AC1, cleanup: cleanupA }。
- useLayoutEffect 返回其自身的清理函数 () => { AC1.abort(); cleanupA(); }。
- 结果: AC1 成为活跃控制器，用户副作用开始执行。

场景 2: 依赖项改变（正常重新渲染）

MyComponent 因依赖项 deps 改变而重新渲染。
渲染阶段: useConcurrentEffect 再次被调用。
- newController (AC2) 被创建。
- nextEffectRef.current 为 null（因为上次提交后已清空）。
- nextEffectRef.current 被设置为 AC2。
提交阶段 (useLayoutEffect 执行):
- 上一个 useLayoutEffect 的清理函数被调用: AC1.abort() 被调用，cleanupA() 被执行。currentEffectRef.current 被设为 null。这确保了旧的副作用被及时取消和清理。
- 当前 useLayoutEffect 的设置函数被调用:
  - nextEffectRef.current === newController (AC2 === AC2) 为 true。nextEffectRef.current 被设为 null。
  - currentEffectRef.current 为 null。
  - effect(AC2.signal) 被调用，返回 cleanupB。
  - currentEffectRef.current 被设为 { controller: AC2, cleanup: cleanupB }。
  - useLayoutEffect 返回其自身的清理函数 () => { AC2.abort(); cleanupB(); }。
- 结果: AC1 的副作用被取消，AC2 的副作用开始执行。

场景 3: 渲染被中断（并发模式下的核心优势）

MyComponent 渲染，useConcurrentEffect 被调用。
- newController (AC1) 被创建。
- nextEffectRef.current 被设置为 AC1。
React 开始处理此渲染。在此渲染提交之前，一个更高优先级的更新触发了 MyComponent 的另一次渲染（例如，用户快速输入或父组件状态更新）。React 决定放弃正在进行的 AC1 渲染，转而处理新的渲染。
MyComponent 因新的高优先级更新而再次渲染。
渲染阶段 (新渲染): useConcurrentEffect 再次被调用。
- newController (AC2) 被创建。
- nextEffectRef.current 此时是 AC1（来自被放弃的渲染）。
- nextEffectRef.current.abort() 被调用，即 AC1.abort() 被执行。 这是实现“渲染中断时自动撤销”的关键点。
- nextEffectRef.current 被设置为 AC2。
React 提交了新的、高优先级的渲染。
提交阶段 (useLayoutEffect 执行，对应 AC2 的渲染):
- nextEffectRef.current === newController (AC2 === AC2) 为 true。nextEffectRef.current 被设为 null。
- currentEffectRef.current 为 null（因为 AC1 所在的渲染从未提交，所以它从未成为 currentEffectRef）。
- effect(AC2.signal) 被调用，返回 cleanupB。
- currentEffectRef.current 被设为 { controller: AC2, cleanup: cleanupB }。
- useLayoutEffect 返回其自身的清理函数 () => { AC2.abort(); cleanupB(); }。
- 结果: AC1（虽然其副作用函数从未被调用）的AbortSignal被激活，任何监听该信号的外部操作（如果存在）都会被取消。AC2 的副作用开始执行。

这个机制确保了即使一个渲染被React在提交前放弃，其关联的取消信号也会被触发，从而有效地清理了与该被放弃渲染相关的任何“悬而未决”的操作。

5. `useConcurrentEffect` 的应用场景与最佳实践

useConcurrentEffect在处理需要及时取消的异步操作时特别有用。

5.1 数据获取

这是最常见的场景。使用fetch或axios等库时，将AbortSignal传递给请求配置。

import React, { useState } from 'react';
import { useConcurrentEffect } from './useConcurrentEffect'; // 假设useConcurrentEffect在同级目录

interface User {
  id: number;
  name: string;
  email: string;
}

function UserProfile({ userId }: { userId: number }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useConcurrentEffect((signal) => {
    if (!userId) { // Handle case where userId might be null/0
      setUser(null);
      setLoading(false);
      setError(null);
      return;
    }

    setLoading(true);
    setError(null);
    setUser(null);

    const fetchUser = async () => {
      try {
        const response = await fetch(`https://jsonplaceholder.typicode.com/users/${userId}`, { signal });
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const data: User = await response.json();
        if (!signal.aborted) { // Double check if signal was aborted during await
          setUser(data);
        }
      } catch (err: any) {
        if (err.name === 'AbortError') {
          console.log(`Fetch for user ${userId} aborted.`);
          // Do not set error state if it was an intentional abort
        } else {
          if (!signal.aborted) { // Only set error if not aborted
            setError(err.message || 'An unknown error occurred');
          }
        }
      } finally {
        if (!signal.aborted) { // Only set loading to false if not aborted
          setLoading(false);
        }
      }
    };

    fetchUser();

    // 不需要返回额外的清理函数，因为 AbortController 会处理取消
    // 如果有其他同步资源（如 setTimeout），可以在这里返回清理函数。
  }, [userId]);

  if (loading) return <p>Loading user...</p>;
  if (error) return <p className="error">Error: {error}</p>;
  if (!user) return <p>No user selected or found.</p>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>Email: {user.email}</p>
      <p>ID: {user.id}</p>
    </div>
  );
}

// 示例用法
function App() {
  const [currentUserId, setCurrentUserId] = useState(1);

  return (
    <div>
      <h1>User Profiles</h1>
      <button onClick={() => setCurrentUserId(prev => Math.max(1, prev - 1))}>Previous User</button>
      <button onClick={() => setCurrentUserId(prev => prev + 1)}>Next User</button>
      <p>Current User ID: {currentUserId}</p>
      <UserProfile userId={currentUserId} />
    </div>
  );
}

在上述示例中，当userId快速变化时，旧的fetch请求会在新请求开始前被取消。如果用户点击“Next User”按钮的速度很快，React可能在UserProfile组件的某个渲染提交之前就触发了另一个更新。useConcurrentEffect会确保为被放弃的渲染创建的AbortController也会被中止。

5.2 长运行计算与Web Workers

对于耗时的计算，可以将其卸载到Web Worker中。AbortSignal也可以用来终止Web Worker中的任务。

// worker.js
self.onmessage = async (e) => {
  const { signal, data } = e.data; // signal will be a MessagePort, not AbortSignal directly

  // To truly cancel worker tasks, you'd need a more complex setup
  // where the main thread controls the worker's execution.
  // For simplicity, let's assume 'data' is a number to calculate factorial.

  let result = 1;
  for (let i = 2; i <= data; i++) {
    // Simulate long running task and check for cancellation
    if (signal && signal.aborted) { // This part needs to be adapted for worker context
      self.postMessage({ status: 'aborted' });
      return;
    }
    result *= i;
    // Potentially yield to event loop or check signal periodically
    await new Promise(resolve => setTimeout(resolve, 1)); // Simulate async work
  }
  self.postMessage({ status: 'completed', result });
};

// Main thread component
function HeavyComputationComponent({ inputNumber }: { inputNumber: number }) {
  const [result, setResult] = useState<number | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useConcurrentEffect((signal) => {
    if (!inputNumber) {
      setResult(null);
      setLoading(false);
      setError(null);
      return;
    }

    setLoading(true);
    setResult(null);
    setError(null);

    const worker = new Worker('worker.js'); // Create worker

    // How to pass AbortSignal to Worker: It's not directly serializable.
    // A common pattern is to create a MessageChannel and pass one port to the worker.
    // The main thread can then call port.postMessage('abort') to signal cancellation.
    const { port1, port2 } = new MessageChannel();
    port1.onmessage = (event) => {
      // Worker can send messages back to main thread
      if (event.data.status === 'completed') {
        if (!signal.aborted) {
          setResult(event.data.result);
        }
      } else if (event.data.status === 'aborted') {
        console.log("Worker task aborted from within worker.");
      }
      if (!signal.aborted) {
        setLoading(false);
      }
    };

    // When the AbortSignal is aborted, send a message to the worker to cancel.
    signal.addEventListener('abort', () => {
      console.log('Main thread signal aborted, telling worker to abort.');
      port2.postMessage('abort'); // Send abort signal to worker
      if (!signal.aborted) { // Cleanup if not already handled by worker response
        setLoading(false);
      }
    });

    worker.postMessage({ data: inputNumber, signalPort: port2 }, [port2]); // Pass port2 to worker

    return () => {
      // When the effect cleans up, terminate the worker if it's still running
      worker.terminate();
      port1.close();
      port2.close();
      console.log('Worker terminated on cleanup.');
    };
  }, [inputNumber]);

  if (loading) return <p>Calculating...</p>;
  if (error) return <p className="error">Error: {error}</p>;
  if (result === null) return <p>Enter a number to calculate factorial.</p>;

  return <p>Factorial of {inputNumber} is: {result}</p>;
}

注意： 上述Web Worker示例中的AbortSignal传递给Worker是需要特殊处理的。AbortSignal对象不能直接通过postMessage序列化。通常的做法是创建一个MessageChannel，将一个端口传递给Worker，然后主线程通过该端口发送取消消息。Worker接收到消息后，再自行判断是否中止任务。这个示例仅为演示概念，实际实现需要更复杂的Worker内部取消逻辑。

5.3 订阅管理

对于需要手动订阅和取消订阅的场景，useConcurrentEffect同样适用。虽然AbortSignal本身不直接取消订阅，但它可以在依赖项变化时触发清理逻辑，从而解绑旧的订阅。

import React, { useState } from 'react';
import { useConcurrentEffect } from './useConcurrentEffect';

// 模拟一个可订阅的API
class MyEventBus {
  private listeners: Map<string, Set<(data: any) => void>> = new Map();

  subscribe(eventName: string, callback: (data: any) => void) {
    if (!this.listeners.has(eventName)) {
      this.listeners.set(eventName, new Set());
    }
    this.listeners.get(eventName)?.add(callback);
    console.log(`Subscribed to ${eventName}`);
    return () => {
      this.listeners.get(eventName)?.delete(callback);
      console.log(`Unsubscribed from ${eventName}`);
    };
  }

  publish(eventName: string, data: any) {
    this.listeners.get(eventName)?.forEach(callback => callback(data));
  }
}

const eventBus = new MyEventBus(); // 全局事件总线实例

function EventSubscriber({ eventName }: { eventName: string }) {
  const [lastMessage, setLastMessage] = useState<string | null>(null);

  useConcurrentEffect((signal) => {
    if (!eventName) {
      setLastMessage(null);
      return;
    }

    const handleMessage = (data: any) => {
      if (!signal.aborted) {
        setLastMessage(`Received: ${JSON.stringify(data)} at ${new Date().toLocaleTimeString()}`);
      }
    };

    // 订阅事件
    const unsubscribe = eventBus.subscribe(eventName, handleMessage);

    // 返回清理函数
    return () => {
      unsubscribe(); // 取消订阅
      // 如果 signal 被 abort，则表示组件被快速更新或卸载，此时不再需要处理任何消息
    };
  }, [eventName]);

  return (
    <div>
      <h3>Listening to "{eventName}"</h3>
      <p>{lastMessage || 'Waiting for messages...'}</p>
    </div>
  );
}

// 示例用法
function AppWithEvents() {
  const [currentEvent, setCurrentEvent] = useState('userUpdate');

  // 模拟每隔一段时间发布事件
  useConcurrentEffect((signal) => {
    const interval = setInterval(() => {
      if (!signal.aborted) {
        eventBus.publish('userUpdate', { id: Math.random().toFixed(2), name: 'User ' + Math.floor(Math.random() * 100) });
        eventBus.publish('productUpdate', { id: Math.random().toFixed(2), item: 'Product ' + Math.floor(Math.random() * 50) });
      }
    }, 2000);

    return () => clearInterval(interval);
  }, []); // 仅在挂载时运行一次

  return (
    <div>
      <h1>Event Bus Demo</h1>
      <div>
        <button onClick={() => setCurrentEvent('userUpdate')}>Listen User Updates</button>
        <button onClick={() => setCurrentEvent('productUpdate')}>Listen Product Updates</button>
      </div>
      <EventSubscriber eventName={currentEvent} />
    </div>
  );
}

在这个例子中，当eventName改变时，useConcurrentEffect会触发上一个订阅的清理函数（unsubscribe()），从而及时停止监听旧事件，并开始监听新事件。即使在并发渲染中，也能确保订阅的正确性。

5.4 最佳实践总结

尊重 signal: 你的副作用回调函数内部必须主动检查signal.aborted状态，或监听signal.onabort事件，并停止正在进行的异步工作。如果你的异步操作不支持AbortSignal（例如某些第三方库），你可能需要手动添加一个标志来忽略结果，但这会失去真正的取消能力。
同步清理: 如果effect回调中启动了同步资源（如setTimeout、setInterval、事件监听器等），确保返回一个清理函数来销毁它们。AbortController主要用于异步操作的取消。
避免在渲染中启动异步: 永远不要在组件的渲染函数（return (...) 之前）中直接启动异步操作。useConcurrentEffect的effect回调在useLayoutEffect中执行，这已经是提交阶段，符合React的规则。
谨慎使用 useLayoutEffect: 虽然我们在useConcurrentEffect内部使用了useLayoutEffect来确保精确的生命周期管理，但作为应用程序开发者，通常应优先使用useEffect。useLayoutEffect可能会阻塞浏览器绘制，应仅在需要同步读取或修改DOM，或需要精确的副作用时序时使用。在这里，它是为了实现并发模式下的精确取消时机而服务的。

6. `useEffect` 与 `useConcurrentEffect` 对比

为了更好地理解useConcurrentEffect的价值，我们将其与useEffect进行对比：

特性/方面	`useEffect`	`useConcurrentEffect`
执行时机	渲染提交后，浏览器绘制后。	渲染提交后，浏览器绘制后（用户`effect`回调）。
清理触发器	1. 组件卸载。 2. 依赖项改变（旧清理在新设置前）。	1. 组件卸载。 2. 依赖项改变（旧清理在新设置前）。 3. 渲染被中断（abandoned render）。
异步取消能力	仅通过返回的清理函数，被动取消已启动的异步任务。	主动且即时地取消： – 已提交的副作用。 – 因渲染被中断而未提交的副作用。
API 签名	`(callback: () => cleanup \| void, deps?)`	`(callback: (signal: AbortSignal) => cleanup \| void, deps?)`
并发模式优势	有限。依赖`ignore`标志或手动`AbortController`管理来避免竞态条件。	专门为并发模式设计，通过`AbortSignal`实现精确的资源管理，减少无用工作和竞态条件。
主要用例	简单的DOM操作、不涉及异步或可被忽略的副作用、不频繁的订阅。	耗时的异步操作（数据获取、文件处理）、Web Workers、需要精确取消的订阅。
性能/资源	可能会导致未取消的后台任务继续运行，浪费资源。	及时中止未完成任务，优化资源使用和性能。

总结：

useConcurrentEffect在useEffect的基础上，增加了对React并发模式下“渲染中断”这一特殊情况的处理能力。它通过在渲染阶段提前创建并管理AbortController，确保即使一个渲染被React放弃，其关联的取消信号也能被触发，从而实现对副作用的更精细、更及时的控制。这对于构建在复杂交互和数据流下依然保持高性能和响应性的React应用至关重要。

7. 对并发模式下副作用的深入思考

useConcurrentEffect的实现，实际上是React社区在并发模式下管理副作用的一种高级模式。它与React团队推荐的useTransition和useDeferredValue等Hooks相辅相成。

useTransition和useDeferredValue主要关注渲染本身的优先级和调度。它们允许我们标记某些状态更新为“低优先级”，让React可以在后台处理这些更新，同时保持UI对高优先级更新（如用户输入）的响应。
useConcurrentEffect则关注渲染所触发的副作用的优先级和取消。它确保当渲染因为优先级调整而被中断或废弃时，相关的副作用能够被及时清理，避免资源浪费和状态不一致。

将这三者结合起来，可以构建出极其强大的用户体验。例如，一个搜索框，用户输入时可以使用useTransition来延迟搜索结果的渲染，同时使用useConcurrentEffect来取消旧的搜索请求，只保留最新的有效请求。

import React, { useState, useTransition } from 'react';
import { useConcurrentEffect } from './useConcurrentEffect';

function SearchResults({ query }: { query: string }) {
  const [results, setResults] = useState<string[]>([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useConcurrentEffect((signal) => {
    if (!query) {
      setResults([]);
      setLoading(false);
      setError(null);
      return;
    }

    setLoading(true);
    setError(null);
    setResults([]);

    const fetchResults = async () => {
      try {
        // Simulate a network request
        const response = await new Promise<string[]>((resolve, reject) => {
          const timer = setTimeout(() => {
            if (query === 'error') {
              reject(new Error('Simulated fetch error'));
            } else {
              resolve([
                `Result for "${query}" - Item 1`,
                `Result for "${query}" - Item 2`,
                `Result for "${query}" - Item 3`,
              ]);
            }
          }, 500 + Math.random() * 500); // Simulate varying network latency

          signal.addEventListener('abort', () => {
            clearTimeout(timer);
            reject(new DOMException('Aborted', 'AbortError'));
          }, { once: true });
        });

        if (!signal.aborted) {
          setResults(response);
        }
      } catch (err: any) {
        if (err.name === 'AbortError') {
          console.log(`Search for "${query}" aborted.`);
        } else {
          if (!signal.aborted) {
            setError(err.message);
          }
        }
      } finally {
        if (!signal.aborted) {
          setLoading(false);
        }
      }
    };

    fetchResults();
  }, [query]);

  if (loading) return <p>Searching for "{query}"...</p>;
  if (error) return <p className="error">Error: {error}</p>;
  if (results.length === 0) return <p>No results for "{query}".</p>;

  return (
    <ul>
      {results.map((r, i) => (
        <li key={i}>{r}</li>
      ))}
    </ul>
  );
}

function SearchPage() {
  const [inputValue, setInputValue] = useState('');
  const [query, setQuery] = useState('');
  const [isPending, startTransition] = useTransition();

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setInputValue(e.target.value);
    // Use startTransition to defer the update of 'query' state
    // This allows the input to update immediately, while the search results
    // update in a non-blocking way.
    startTransition(() => {
      setQuery(e.target.value);
    });
  };

  return (
    <div>
      <h1>Concurrent Search</h1>
      <input
        type="text"
        value={inputValue}
        onChange={handleChange}
        placeholder="Type to search..."
        style={{ width: '300px', padding: '8px' }}
      />
      {isPending && <span style={{ marginLeft: '10px' }}>Loading...</span>}
      <div style={{ marginTop: '20px' }}>
        <SearchResults query={query} />
      </div>
    </div>
  );
}

在这个搜索示例中：

用户输入时，inputValue立即更新，保持输入框的响应性。
startTransition将query状态的更新标记为低优先级。这意味着SearchResults组件的重新渲染将作为并发转换的一部分进行调度。
如果用户快速输入，query状态会频繁更新，SearchResults组件会多次调用useConcurrentEffect。useConcurrentEffect能够确保：
- 旧的、尚未完成的搜索请求会被AbortController及时取消。
- 即使React放弃了某个中间状态的渲染，该渲染关联的AbortController也会被中止，进一步减少不必要的后台工作。
isPending状态用于在搜索结果加载时显示一个过渡指示器，提升用户体验。

通过这种组合，我们不仅让UI输入响应迅速，还确保了后台数据获取的效率，避免了因快速输入导致的请求堆积和资源浪费。

8. 总结与展望

useConcurrentEffect的实现，为我们在React并发模式下管理副作用提供了一个强大而灵活的工具。它通过巧妙地结合useRef和useLayoutEffect，并在渲染阶段预先管理AbortController，实现了对副作用的即时、主动取消，尤其是在渲染被中断的复杂场景下。

理解并应用这种模式，能够帮助开发者构建出更加高效、稳定和用户友好的React应用程序。随着React并发模式的持续发展，这种对副作用的精细控制将成为构建高性能Web应用不可或缺的一部分。掌握这些高级Hook和模式，将使我们能够更好地驾驭React的强大功能，创造出卓越的用户体验。

React 并发模式下的副作用管理：构建 useConcurrentEffect

1. 并发模式与副作用管理的挑战

2. useEffect的局限性与 AbortController

2.1 useEffect的生命周期

2.2 AbortController：异步操作的取消利器

3. useConcurrentEffect 的核心理念与 API 设计