Events.filter() 函式
合併重複事件、移除空值事件，並重新記錄 BlockChange 事件，藉此篩選佇列中的事件。
這個函式的歷史記錄：
這個函式最初是在 cf257ea5 版本中新增，目的是大幅減少分派事件的總數。一開始，這項問題只影響 BlockMove 事件，但後來其他事件也受到影響。
我們新增程式碼，以便重新排序在 5578458 次版本中新增的 BlockChange 事件，但原因不明，但很可能是在嘗試修正區塊變異期間事件排序問題時，只部分成功的結果。這個程式碼應該會在合併和移除空值之前，新增至函式的頂端，但基於現在已遺忘的原因，它被新增至底部。請參閱這些錯誤調查，進一步瞭解潛在問題，以及由於這個不完整/不正確的修正而發生的部分錯誤：
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 (請注意，事件會以相反順序與順序相加)。我們最初選擇的修正方式是新增程式碼 (在 PR #7069 中)，以便在 fireNow 後，為任何剛參與事件調度的作業空間，執行後置篩選的 .undoStack_ 和 .redoStack_。這個方法顯然解決了問題，但也增加了相當程度的額外複雜性，讓人難以推論如何處理撤銷/重做事件，因此我們移除了來自撤銷的呼叫和後置處理程式碼，並將 forward=true 設為預設值，同時淘汰了以 forward=false 呼叫函式的做法。
同時，我們也將用於重新排序 BlockChange 事件的錯誤程式碼，改用新函式 enqueueEvent 中的同功能但錯誤較少的版本，以便從 fireInternal 呼叫，確保在呼叫篩選器時，事件會以正確的順序排列。
此外，我們也修改了事件合併程式碼，只會合併緊鄰的事件。這麼做可簡化實作方式，同時確保合併事件不會導致事件順序重排。
Signature:
export declare function filter(queue: Abstract[]): Abstract[];
參數
| 參數 | 類型 | 說明 |
|---|---|---|
| 佇列 | 抽象[] | 事件陣列。 |
退貨：
抽象[]
已篩選的事件陣列。