为什么引入 `ResizeObserver` 来监听调整大小的变化而不是更简单的 Element.prototype.addEventListener('resize', callback)

Question

我有点惊讶，为了监听元素尺寸（不是窗口对象）的变化，我们必须使用一个名为ResizeObserver的新接口。 虽然它似乎很好地完成了这项工作； 它似乎与其他元素相关的事件有点不同，只需添加一个监听器就可以使用这些事件。

以添加一个事件监听器来监听鼠标悬停事件为例

document.querySelector('#ele').addEventListener('mouseover', callback);

为什么不简单地为元素上的 resize 事件添加一个新的侦听器？

document.querySelector('#ele').addEventListener('resize', callback);

是为了避免与窗口resize事件发生冲突吗？ 如果是这样，为什么不换个称呼呢

document.querySelector('#ele').addEventListener('elementResize', callback);

我知道创建一个辅助方法来简化ResizeObserver的使用很容易。 这样的东西可以像原始的addEventListener方法一样简单易用

export const getResizeObserver = ( ele, onResize ) => {
  let obs;

  const observerInterface = {
    stop: () => { obs.unobserve( ele ); obs.disconnect() },
  };

  obs = new ResizeObserver( entries => {
    for ( const entry of entries ) {
      onResize && onResize( entry.contentRect );
    }
  } );

  obs.observe( ele );

  return observerInterface;
};

// usage to add the listener
const obs = getResizeObserver(document.querySelector('#ele'), callback);
// later to remove the listener
obs.stop();

在任何情况下，除了 api 首选项和多个元素可以共享观察者实例这一事实之外，是否有任何理由使ResizeObserver方法比addEventListener方法更好？

Answer 1

在这个 PR中有一个讨论，其中 W3C 技术架构组试图定义何时在EventTarget上使用观察者模式。 此讨论的输出记录在此处，我引用了第一条语句：

通常，使用 EventTarget 和通知事件，而不是观察者模式，除非 EventTarget 不能很好地适用于您的功能。

与EventTarget相比，使用观察者模式的优点如下：

1. 可以在观察时或创建时自定义实例。 Observer 的构造函数或其observe()方法可以采用允许作者自定义每个回调观察到的内容的选项。 这对于addEventListener()是不可能的。

2. 使用 Observer 对象上的disconnect()或unobserve()方法很容易停止监听多个回调。

3. 您可以选择提供像takeRecords()这样的方法，它会立即获取相关数据，而不是等待事件触发。

4. 因为观察者是单一用途的，所以您不需要指定事件类型。

在我看来，专门谈论ResizeObserver ：

• 第 2 点和第 4 点不太相关。 它没有添加或采用任何重要的东西，我认为resize事件在这里会更好地匹配。

• 它仍然没有实现takeRecords()方法，所以 3d 点无关紧要

它使我们能够在创建和观察时对其进行自定义，并允许稍后更改这些自定义 API，而无需更改事件模型。

此外，可能存在性能问题或不可避免的递归，但我没有找到有关它们的任何度量或解释。

Answer 2

这是提议的（并且问题仍然存在），但 Chrome 决定使用观察者模型发布它，似乎主要是因为它比基于事件的实现快 10 倍https://groups.google.com/a/chromium。 org/forum/#!topic/blink-dev/z6ienONUb5A

现在为什么这是真的，我不知道。