Events.filter() 函数
通过合并重复项、移除 null 事件和重新记录 BlockChange 事件来过滤队列中的事件。
此函数的历史记录：
此函数最初是在提交版本 cf257ea5 中添加的，目的是大幅减少分派的事件总数。最初，此问题仅会影响 BlockMove 事件，但后来又影响了其他事件。
添加了代码来重新排列提交 5578458 中添加的 BlockChange 事件，原因不明，但很可能是在尝试解决块更新期间事件排序问题时，仅部分成功。此代码可能应在合并和移除 null 之前添加到函数顶部，但出于现在已忘记的原因，被添加到了底部。如需更详细地了解根本问题以及因此不完整/不正确的修复而导致的一些失败情况，请参阅以下 bug 调查：
https://github.com/google/blockly/issues/8225#issuecomment-2195751783 https://github.com/google/blockly/issues/2037#issuecomment-2209696351
后来，在 PR #1205 中，原始的 O(n^2) 实现被线性时间实现取代，但随后又进行了其他修复。
2024 年 8 月，我们对许多流程进行了重大简化：
此函数之前是从 Workspace.prototype.undo 调用的，但此函数对事件的更改是导致问题 7026 的原因（请注意，事件在反向顺序与正向顺序下会组合不同）。最初为此问题选择的解决方法是在 fireNow 中添加了代码（在 PR #7069 中），以对刚刚参与调度事件的任何工作区的 .undoStack_ 和 .redoStack_ 进行后续过滤；这显然解决了问题，但增加了相当多的额外复杂性，并且难以推理撤消/重做事件的处理方式，因此移除了从撤消调用和后处理代码，并将 forward=true 设为默认值，同时废弃了使用 forward=false 调用函数的做法。
同时，用于重新排列 BlockChange 事件的存在 bug 的代码已替换为通过 fireInternal 调用的 enqueueEvent 新函数中提供的功能的 bug 较少的版本，从而确保在调用过滤器时事件将按正确的顺序排列。
此外，我们修改了事件合并代码，以便仅合并紧挨的事件。这简化了实现，同时确保了事件合并不会导致事件重新排序。
Signature:
export declare function filter(queue: Abstract[]): Abstract[];
参数
| 参数 | 类型 | 说明 |
|---|---|---|
| 队列 | 抽象[] | 事件数组。 |
返回：
抽象[]
过滤后的事件数组。