发布于 由admin

解析 React 的“合成事件（SyntheticEvent）”：为什么 React 17 之后将事件监听挂载到了 Root 而非 Document？

React 的合成事件系统（SyntheticEvent）是其核心机制之一，它为开发者提供了一套统一、跨浏览器且高性能的事件处理方案。而从 React 17 版本开始，事件监听的挂载策略从 document 节点迁移到了 React 应用的根 DOM 节点（Root）。这一看似微小的改动，实则解决了 React 在多应用共存、与其他框架交互以及事件隔离方面面临的深层问题。

合成事件的诞生：为何需要它？

在深入探讨 React 17 的事件委托变化之前，我们首先需要理解 React 为何要构建自己的事件系统，即“合成事件（SyntheticEvent）”。

浏览器原生事件系统存在一些固有的挑战：

  1. 跨浏览器兼容性问题： 不同的浏览器对事件对象的实现、事件名称（例如 IE 中的 onmouseenter vs. 标准的 onmouseover）以及事件行为（如事件冒泡和捕获的细节）存在差异。
  2. 性能优化： 直接在大量 DOM 元素上绑定事件监听器会导致内存开销增加，尤其是在列表或表格等动态内容中。
  3. React 内部机制的整合： React 需要一个机制来更好地与自己的虚拟 DOM、调度器和状态更新生命周期协同工作。

为了解决这些问题，React 引入了 SyntheticEvent。它不是对原生事件的简单封装，而是一个独立的事件系统，它拦截浏览器原生事件，并将其封装成符合 W3C 标准的 SyntheticEvent 对象。

SyntheticEvent 的核心特性（React 16 及以前）

在 React 17 之前的版本中，SyntheticEvent 系统的设计理念主要体现在以下几个方面：

  1. 事件标准化： SyntheticEvent 对象统一了不同浏览器之间的事件属性和方法。无论底层是 IE 的 attachEvent 还是现代浏览器的 addEventListener，开发者接触到的都是一个标准化的事件对象。
    例如，event.target、event.preventDefault()、event.stopPropagation() 等在 SyntheticEvent 中行为一致。

  2. 事件委托（Event Delegation）： 这是 SyntheticEvent 性能优化的关键。React 不会将事件监听器直接绑定到 JSX 元素对应的真实 DOM 节点上。相反，它会在一个更高层级的 DOM 节点上（历史版本中是 document）统一监听所有事件类型。当一个原生事件冒泡到这个高层级节点时，React 的事件系统会捕获它，然后根据虚拟 DOM 树的结构，模拟出事件从触发元素到该高层级节点的冒泡路径，并调用相应的 React 事件处理函数。

    这种机制的优势在于：

    • 内存优化： 只需要少量（通常是每种事件类型一个）事件监听器，而非每个交互元素一个。
    • 动态元素支持： 对于通过列表渲染或条件渲染动态添加/移除的元素，无需手动绑定/解绑事件，事件委托机制会自动处理。

  3. 事件池（Event Pooling）： 为了进一步提高性能，React 在 17 版本之前引入了事件池机制。这意味着 SyntheticEvent 对象在事件处理函数执行完毕后并不会被销毁，而是会被重置并放回一个池中，以供后续事件复用。
    这种机制旨在减少垃圾回收的压力，但在某些情况下也带来了困惑：

    • 异步访问问题： 由于事件对象会被复用，如果在事件处理函数中异步访问 event 对象（例如在 setTimeout 或 Promise 回调中），那么 event 对象的属性可能已经被重置，导致获取到的是 null 或旧值。
    • 开发者需要显式地调用 event.persist() 来阻止事件对象被放回池中，以便在异步代码中安全访问。

  4. 事件调度与传播： React 的事件系统会模拟浏览器事件的捕获和冒泡阶段。当一个原生事件被委托节点捕获后，React 会从根部开始向下遍历虚拟 DOM 树（模拟捕获阶段），查找注册了捕获阶段事件处理器的组件，然后从实际触发的组件开始向上遍历虚拟 DOM 树（模拟冒泡阶段），查找注册了冒泡阶段事件处理器的组件。

    // 示例：React 事件处理
function MyButton() {
  const handleClick = (event) => {
    console.log('SyntheticEvent:', event);
    console.log('event.target:', event.target); // 触发事件的 DOM 元素
    console.log('event.currentTarget:', event.currentTarget); // 绑定事件的 DOM 元素（在 React 中通常是虚拟 DOM 元素）
    event.stopPropagation(); // 阻止 SyntheticEvent 冒泡
    // event.nativeEvent.stopPropagation(); // 阻止原生事件冒泡
  };

  return <button onClick={handleClick}>点击我</button>;
}

    event.target 和 event.currentTarget 的区别在 SyntheticEvent 中同样重要。event.target 始终指向触发事件的实际 DOM 元素，而 event.currentTarget 指向当前事件处理器所绑定的元素（在 React 的虚拟 DOM 层次中）。由于事件委托，event.currentTarget 在原生事件中通常是 document，但在 React 的逻辑中，它会被模拟为实际绑定 onClick 的组件对应的 DOM 元素。

React 17 之前的事件委托：挂载到 document

在 React 17 之前，所有的事件监听器（无论是捕获阶段还是冒泡阶段的）都会被统一挂载到 document 对象上。

// 概念性代码，非 React 内部真实实现，用于说明委托原理
// 假设 React 内部会执行类似这样的操作
document.addEventListener('click', reactGlobalClickHandler, true);  // 捕获阶段
document.addEventListener('click', reactGlobalClickHandler, false); // 冒泡阶段
// ... 对于其他所有事件类型也是如此

当用户点击一个 React 元素时，例如一个 <button>：

  1. 浏览器捕获到原生 click 事件。
  2. 这个原生 click 事件会从 window 冒泡到 document。
  3. document 上的 reactGlobalClickHandler 捕获到这个原生事件。
  4. reactGlobalClickHandler 会将原生事件封装成 SyntheticEvent。
  5. 然后，React 的事件调度器会根据虚拟 DOM 树，模拟事件从根部到 <button> 再到 document 的传播路径，依次调用沿途所有注册的 React 事件处理函数。

这种设计在大多数情况下工作良好，但在一些特定场景下，它会引入复杂性和不一致性。

document 委托模式带来的挑战

将所有事件监听器挂载到 document 上，在现代前端开发实践中，尤其是在复杂应用和多框架混合的环境下，暴露出了一些问题：

1. 多 React 应用共存时的冲突

在一个页面上可能存在多个独立的 React 应用。例如，一个遗留系统可能部分使用 React 重构，或者通过微前端架构在同一页面加载多个独立的 React 应用。

<!-- index.html -->
<div id="root1"></div>
<div id="root2"></div>

<script>
  // App1 (可能是React 16)
  ReactDOM.render(<App1 />, document.getElementById('root1'));

  // App2 (可能是React 16)
  ReactDOM.render(<App2 />, document.getElementById('root2'));
</script>

在这种情况下，两个 React 应用都会尝试在 document 上注册自己的事件监听器。当一个事件在 App1 内部被触发时，例如一个 click 事件，它会冒泡到 document。此时，document 上的 两个 React 全局事件监听器都会捕获到这个事件。

这会导致一个严重的问题：事件的 stopPropagation() 行为变得不可预测且容易出错。

  • 如果 App1 中的一个组件调用 event.stopPropagation()，它会阻止 SyntheticEvent 在 App1 内部的进一步冒泡。但由于原生事件已经到达 document，并且 App2 的事件系统也在 document 上监听，App2 依然会捕获到这个原生事件，并可能执行其自身的事件处理逻辑。
  • 这违反了直觉：开发者通常期望 stopPropagation() 能够阻止事件的 所有 进一步传播，而不仅仅是当前 React 实例内的传播。

2. React 与其他 JavaScript 框架/库的交互问题

同样的问题也发生在 React 应用与非 React 代码（如 jQuery、Vue、Angular 或原生 JavaScript）混合使用时。

假设一个页面有一个全局的非 React 弹窗组件，它在 document 上监听 click 事件以在点击弹窗外部时关闭自身。

// 非 React 的全局弹窗关闭逻辑
document.addEventListener('click', function(e) {
  if (!myModal.contains(e.target)) {
    myModal.close();
  }
});

如果 React 应用内部的一个元素触发了一个 click 事件，并且其内部调用了 event.stopPropagation()，按照 React 16 的行为，它只会阻止 SyntheticEvent 在 React 内部的冒泡。原生事件仍然会冒泡到 document，并被非 React 的全局监听器捕获，导致弹窗被意外关闭。

开发者被迫使用 event.nativeEvent.stopPropagation() 来阻止原生事件的传播，但这破坏了 SyntheticEvent 提供的抽象，并增加了开发者的心智负担。

3. 难以升级和维护

当整个应用需要在不同 React 版本之间升级时，如果页面上同时存在不同版本的 React 实例，它们的事件系统可能会相互干扰。例如，一个旧版 React 模块和新版 React 模块同时在 document 上监听事件，这会使得升级过程变得异常复杂和危险。

React 17 的解决方案：委托到 Root DOM 节点

为了解决上述问题，React 团队在 React 17 中做出了一个根本性的改变：不再将事件监听器挂载到 document 上，而是挂载到 ReactDOM.render() 或 createRoot() 函数所指定的 DOM 容器节点上。

这个容器节点通常就是你的 React 应用的根 DOM 元素，例如 <div id="root"></div>。

// React 17+ 概念性代码
const rootElement = document.getElementById('root');
// ReactDOM.render(<App />, rootElement); // 旧 API
const root = ReactDOM.createRoot(rootElement); // 新 API
root.render(<App />);

// 此时，React 的事件监听器会绑定到 rootElement 上
rootElement.addEventListener('click', reactGlobalClickHandler, true);
rootElement.addEventListener('click', reactGlobalClickHandler, false);
// ... 等等

1. 解决了多 React 应用共存的冲突

现在，每个 React 实例都会将其事件监听器绑定到它自己的根 DOM 节点上。

<!-- index.html -->
<div id="root1"></div>
<div id="root2"></div>

<script>
  // App1 (React 17+)
  ReactDOM.createRoot(document.getElementById('root1')).render(<App1 />);

  // App2 (React 17+)
  ReactDOM.createRoot(document.getElementById('root2')).render(<App2 />);
</script>

当 App1 中的一个元素触发 click 事件时，原生事件会从触发元素开始冒泡，直到它到达 root1。此时，root1 上的 React 事件监听器会捕获并处理它。如果 App1 内部调用了 event.stopPropagation()，它会阻止 SyntheticEvent 在 App1 内部的冒泡。更重要的是，它也阻止了原生事件继续冒泡到 root1 之外。

这意味着，App2 的事件系统将不会收到这个事件，因为它是在 root2 上监听的。每个 React 实例的事件系统都变得相互隔离，互不干扰。

2. 改善了与非 React 代码的交互

同样地，当一个 React 17+ 应用与非 React 代码交互时，event.stopPropagation() 的行为也变得更加符合直觉。

如果一个 React 组件调用 event.stopPropagation()，它不仅会阻止 SyntheticEvent 在当前 React 根内的传播，还会阻止原生事件继续冒泡到该 React 根元素之外。这意味着，那些在 document 上监听的非 React 全局事件监听器将不会捕获到这个被阻止的事件。

// 非 React 的全局弹窗关闭逻辑
document.addEventListener('click', function(e) {
  console.log('Native document click listener triggered');
  // ...
});

// React 17+ 应用
function MyComponent() {
  const handleClick = (e) => {
    console.log('React component click');
    e.stopPropagation(); // 阻止 SyntheticEvent 冒泡，同时也阻止原生事件冒泡出 #root
  };
  return <div onClick={handleClick}>Click me (inside React root)</div>;
}

ReactDOM.createRoot(document.getElementById('root')).render(<MyComponent />);

点击 MyComponent 中的 div 时，只会输出 React component click。Native document click listener triggered 将不会被打印，因为原生事件在到达 document 之前就被 root 元素阻止了。

这使得 React 应用能够更好地嵌入到复杂的现有系统中，并与其他库进行更可靠的集成。

3. 简化了升级路径

由于事件系统现在是自包含的，不同版本的 React 可以更容易地在同一个页面上共存。例如，你可以逐步将一个大型应用的不同部分升级到 React 17，而无需担心事件系统冲突。这对于大型项目的渐进式升级至关重要。

React 17 事件系统行为变化的细节

这次事件委托策略的改变，对开发者的日常编码习惯和对事件传播的理解产生了一些微妙但重要的影响。

stopPropagation() 的新行为

这是最值得关注的变化。

特性 React 16 及以前 (委托到 document) React 17 及以后 (委托到 Root)
event.stopPropagation() 仅阻止 SyntheticEvent 在当前 React 实例内部的冒泡。原生事件会继续冒泡到 document，可能被其他 React 实例或非 React 代码捕获。 阻止 SyntheticEvent 在当前 React 实例内部的冒泡。同时，也会阻止原生事件冒泡到当前 React Root 元素之外。
event.nativeEvent.stopPropagation() 阻止原生事件的传播。这通常是你在需要完全隔离事件时不得不使用的方法。 行为不变，但通常不再需要，因为 event.stopPropagation() 已经包含了阻止原生事件冒泡出 Root 的能力。

这意味着：

  • 在 React 17 中，当你调用 event.stopPropagation() 时，你可以更自信地认为这个事件将“停留在”你的 React 应用边界内，不会意外地触发页面上其他无关的全局监听器。
  • 如果你 确实 需要让一个事件继续冒泡到 document 级别，即使它在 React 内部被处理过，你将需要更谨慎地设计你的事件处理逻辑，或者使用原生事件监听器（addEventListener）来捕获。

事件池的移除

虽然不是直接与委托策略相关，但值得一提的是，React 17 彻底移除了事件池机制。这意味着 SyntheticEvent 对象不再被复用，而是每次都重新创建。

  • 好处： 开发者不再需要调用 event.persist() 来在异步代码中访问事件对象。event 对象在事件处理函数结束后，其属性值会保持不变。
  • 影响： 理论上可能略微增加垃圾回收的压力，但现代 JavaScript 引擎的优化使得这种影响微乎其微，相比于带来的开发便利性，这是一个值得的权衡。

捕获阶段事件监听器的行为

React 17 同样将捕获阶段的事件监听器从 document 迁移到了 Root 节点。这意味着，如果一个原生事件在你的 React Root 内部触发，并且在 Root 节点上有一个原生的捕获阶段监听器，那么 React 的捕获阶段 SyntheticEvent 处理器将会在原生捕获阶段监听器之后被调用（如果原生监听器没有阻止事件传播）。

<div id="root"></div>

<script>
  const rootElement = document.getElementById('root');

  // 原生捕获阶段监听器，在 React Root 上
  rootElement.addEventListener('click', (e) => {
    console.log('Native capture on rootElement');
  }, true); // true 表示在捕获阶段监听

  function App() {
    const handleClickCapture = (e) => {
      console.log('React SyntheticEvent capture');
    };
    const handleClick = (e) => {
      console.log('React SyntheticEvent bubble');
    };
    return (
      <div onClickCapture={handleClickCapture} onClick={handleClick}>
        <button>Click Me</button>
      </div>
    );
  }

  ReactDOM.createRoot(rootElement).render(<App />);
</script>

点击 <button> 时的输出顺序：

  1. Native capture on rootElement
  2. React SyntheticEvent capture (来自 div 上的 onClickCapture)
  3. React SyntheticEvent bubble (来自 div 上的 onClick)

如果 Native capture on rootElement 中调用了 e.stopPropagation()，那么后续的 React 事件监听器将不会被触发。这使得 React 内部的事件传播与外部的原生事件传播更加一致。

实际开发中的影响与最佳实践

  1. 明确事件边界： React 17 之后，你的 React 应用的事件系统被有效地“沙箱化”在其根 DOM 节点内部。这带来了更强的隔离性和可预测性。
  2. 重新审视 stopPropagation() 的使用： 如果你之前依赖 event.nativeEvent.stopPropagation() 来阻止原生事件在 document 级别传播，那么在 React 17+ 中，event.stopPropagation() 通常就足够了。
  3. 与非 React 代码的协作： 当你在一个混合项目中工作时，现在你可以更放心地使用 React 的事件系统，因为它不会意外地影响到其他框架或原生 JavaScript 的全局事件监听器。反之亦然，外部代码的 document 级监听器也不会轻易干扰到 React 应用的内部事件流。
  4. 谨慎添加 document 级监听器： 除非你明确需要监听整个页面的事件（例如，全局键盘快捷键、点击外部关闭所有弹窗），否则尽量在 React 组件内部处理事件，或者将原生监听器绑定到更具体的 DOM 元素上。
  5. 关于 Portals： React Portals 允许你将子节点渲染到父组件 DOM 层次之外的 DOM 节点。React 17 的事件委托变化并不会改变 Portals 的事件传播行为。即使 Portal 的子节点在 DOM 树中处于 Root 节点之外，其事件仍然会通过 React 的内部机制，像在常规组件中一样冒泡到距离其最近的 React 祖先 组件，然后继续冒泡到最初渲染 Portal 的组件所在的 React Root 节点。这意味着，事件仍然会在逻辑上遵循 React 组件树的结构，最终到达其所属的 React Root 节点。

总结

React 17 将事件委托点从 document 迁移到每个 React 应用的 Root DOM 节点，是 React 团队为了解决在复杂应用场景下，特别是多 React 实例共存和与其他框架交互时的事件隔离和行为一致性问题而做出的重大改进。这一变化使得 React 的事件系统更加独立、可预测和健壮，显著提升了开发体验和应用的稳定性，并为未来的 React 发展奠定了更坚实的基础。开发者现在可以更自信地编写事件处理逻辑，无需过多担心跨框架或多实例间的意外交互。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注