Javascript 为什么使用自定义事件/事件总线？

我使用一个复杂的Javascript软件，试图了解它是如何构建的。它是pdf.js，但对于这个问题，它并不重要。这是一个更倾向于软件设计方向的问题，而不是它在这种特定情况下如何工作（我可以自己阅读）。我想知道他们为什么使用事件，例如在简单的点击按钮的情况下

例如：

appConfig.toolbar.openFile.addEventListener('click', function (e) {
  PDFViewerApplication.eventBus.dispatch('openfile');
});

appConfig.toolbar.openFile是一个Dom元素，正是单击按钮。因此，click事件将分派一个事件openfile

此事件触发一个函数

function webViewerOpenFile() {
    ...do stuff
}

在某些情况下，但不是所有的情况下，中间有一个步骤，我现在不明白：EnvivBUS创建了一个新的克隆事件。

eventBus.on('pagemode', function (e) {
  var event = document.createEvent('CustomEvent');
  event.initCustomEvent('pagemode', true, true, {
    mode: e.mode,
  });
  e.source.pdfViewer.container.dispatchEvent(event);
});

我实在看不出这种复杂的做法有什么好处。为什么不像往常一样将函数绑定到Dom元素呢

appConfig.toolbar.openFile.addEventListener('click', webViewerOpenFile);

---

也许有人可以启发我？

这样做可能是为了添加另一层重定向。单击按钮时应打开一个文件，但它没有指定如何打开文件，以便您可以在将来轻松地修改所有openfile事件，只需更改一行代码即可以不同方式处理。测试抽象比测试原始基于dom的事件更容易。另请参阅解释，了解为什么在Oh为pdf.js引入它，实际上有一个解释。我以前应该找的，谢谢。我知道这大大减少了依赖项的数量，但是单击处理程序是如何不一致的，我仍然需要找出…这可能是为了添加另一层重定向。单击按钮时应打开一个文件，但它没有指定如何打开文件，以便您可以在将来轻松地修改所有openfile事件，只需更改一行代码即可以不同方式处理。测试抽象比测试原始基于dom的事件更容易。另请参阅解释，了解为什么在Oh为pdf.js引入它，实际上有一个解释。我以前应该找的，谢谢。我知道这大大减少了依赖项的数量，但是单击处理程序是如何不一致的，我仍然需要找出。。。

appConfig.toolbar.openFile.addEventListener('click', webViewerOpenFile);