既然我们刚刚谈到了事件,现在是时候提一下自定义事件了。到目前为止,我们讨论的所有事件都是“真实”事件,可以这么说。这些事件起源于 DOM,基于发生的真实事情,例如点击或按键。这些事件可以在 jQuery 中“人工触发”。例如,要“模拟”点击一个按钮,你可以这样做
$("#some-button").trigger("click");
然后绑定到该按钮的任何点击处理程序都会像用户真正点击该按钮一样触发。但如果我们这样做呢
$("#some-button").trigger("dance");
然后会发生什么?“dance”不是“真实”事件。但不会抛出错误。碰巧可能没有“dance”处理程序绑定到该按钮。但可能会有,这本质上就是自定义事件。一个你随意命名的事件。
为什么要这样做?主要是出于组织原因。也许你喜欢将处理事件和操作的 JavaScript 与处理数据和管理事务的 JavaScript 分开。这是非常合理的。如果这个按钮可能是一个“保存设置”按钮,你可以简单地触发一个名为“save-settings”的自定义事件,并在其他地方有一个处理程序等待该事件触发并执行实际的数据保存操作。这本质上就是我们在视频中的示例中所做的。
自定义事件的另一个用例是创作通用 UI 组件。我在这篇博文中讨论了这一点。
也许你正在创建一个手风琴效果作为 UI 组件。手风琴执行所有手风琴的功能,在点击/轻触时打开和关闭面板。你的 UI 组件可以很好地做到这一点。现在,使用该手风琴的开发人员可能希望对其执行一些特殊且独特的操作。假设他们正在使用手风琴进行帐户设置,并且当用户关闭一个面板时,他们希望保存该面板中表单元素的数据。传统模型可能是手风琴 UI 组件的作者在该操作发生时提供回调函数。当你初始化手风琴时,你传入希望在这些事情发生时调用的回调函数。这是一条路。另一条路是让手风琴自动为其执行的所有相关操作触发自定义事件。当该面板关闭时,它可以在手风琴元素本身触发一个panelClosed
事件。然后使用它的开发人员只需绑定到这些事件即可。这只是为了组织原因而可以采用的另一条路径,它可以非常优雅。