剛剛平靜怎麼了？
JavaScript 的提案
Array.prototype.flatten 後，語言功能
與網路不相容。由於 Firefox 夜間版本提供這項功能，導致至少一個熱門網站
。因為有問題的程式碼是大多數 MooTools 的一部分
可能是因為更多網站受到影響。(雖然 MooTools
但 2018 年仍未用於新網站，但過去相當受歡迎，
仍會出現在許多生產網站上)。
提案作者開玩笑，建議您將「flatten」重新命名為「smoosh」
避免發生相容性問題大家都不太清楚這個笑話
有人開始誤以為新名稱已經有人使用
讓事情迅速發展
「Array.prototype.flatten」有哪些功能？
Array.prototype.flat，最初提議為「Array.prototype.flatten」，
以遞迴方式將陣列合併至指定的 depth (預設值)
至 1。
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
相同提案包含「Array.prototype.flatMap」，如下所示
Array.prototype.map，但它會將結果整併至新陣列。
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
造成這個問題的 MooTools 執行什麼動作？
MooTools 定義了自己的 Array.prototype.flatten 非標準版本：
Array.prototype.flatten = /* non-standard implementation */;
MooTools 的 flatten 實作與提議的標準不同。
不過，這並不是問題！瀏覽器出貨後
Array.prototype.flatten 的原生功能，MooTools 就會覆寫原生設定
。這可確保採用 MooTools 行為的程式碼
無論是否可使用原生 flatten，都能正常運作。
目前為止還不錯！
但很抱歉，會發生其他狀況。MooTools 完整複製
新增至 Elements.prototype 的自訂陣列方法 (其中 Elements 是
MooTools 特定 API)：
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for-in 會疊代處理不包含的「列舉」屬性
例如 Array.prototype.sort 這類原生方法
經常指派的屬性，例如 Array.prototype.foo = whatever。不過...
來談談當您覆寫不可列舉的屬性時，可以派上用場，例如
Array.prototype.sort = whatever，仍為不可列舉。
目前 Array.prototype.flatten = mooToolsFlattenImplementation 會建立
列舉的 flatten 屬性，所以稍後會複製到 Elements。但
瀏覽器提供 flatten 的原生版本，使其無法列舉，且
「未」複製到「Elements」。任何依賴 MooTools 的程式碼」
「Elements.prototype.flatten」現已毀損。
雖然看起來將原生 Array.prototype.flatten 變更為
列舉項目可解決問題，否則可能會造成
相容性問題。每個網站都會使用 for 至 in 疊代
陣列 (這是不好做法，但會發生的情況) 隨後突然
flatten 屬性的額外迴圈疊代。
這裡最大的問題是修改內建物件。延長中 原生原型現在通常採納不當做法 不會與其他程式庫和第三方程式碼妥善編寫。不要修改 非你擁有的物件！
為什麼我們不只要保留現有名稱，打破網路的藩籬？
CSS 在 1996 年開始廣泛發展，當時「HTML5」成為 Space Jam 網站正式上線。目前網站仍可正常運作 跟 22 年前一樣
怎麼了？是否有人在多年來維護該網站？ ？
結果是，「不要破壞網路」是最重要的設計原則 ，以及 HTML、CSS、JavaScript 以及其他廣泛用於 網頁。如果提交新的瀏覽器功能會導致現有網站停止 這對所有人來說都是壞事：
- 受影響網站的訪客突然遭遇異常毀損
- 網站擁有者從一個運作正常的網站開始 但沒有變更任何項目；
- 瀏覽器供應商提供新功能，因為使用者導致失去市佔率 看到「它可在瀏覽器 X 中運作」後切換瀏覽器；
- 一旦有相容性問題，其他瀏覽器廠商就會拒絕 基礎架構特徵規格與現實不符 (「無內容，只是小說作品」)。 對標準化程序而言是不好的
當然，Retrospect MooTools 的操作有誤，但會破壞網路 也不會懲罰使用者，還會懲罰使用者。這些使用者不知道他們是什麼樣子 工具。或者，我們會找出其他解決方案，讓使用者繼續 使用網站選擇很簡單，
這表示不可能從 Web Platform 中移除有問題的 API 嗎？
視情況而定。在極少數的情況下，系統可能會移除網頁中的無效功能。即使是只是 瞭解是否「可能」移除某項功能並不容易 需要大量遙測來量化分析有多少網頁 行為改變然而，若這項功能充分不安全，會對 或極少使用的情況，這種做法適用。
<applet>、<keygen>和
showModalDialog() 全部
成功從網路平台移除的不良 API 範例。
為什麼我們不直接修復 MooTools？
修補 MooTools 使其不再擴充內建物件 可有效 構思點子但無法解決目前問題。即使 MooTools 之前 發布修補版本後，所有使用這個版本的現有網站都必須 ，以便解決相容性問題。
光是更新 MooTools 嗎？
在這個完美的世界裡，MooTools 會釋出修補程式，而每個網站 使用 MooTools 就會在隔天報表資料神奇地更新解決問題 對吧？
但這不切實際。即使有人試圖辨識自己的身分 完整的受影響網站清單，並找出 然後成功聯繫所有的網站擁有者 並說服他們執行更新 (這可能表示需重構 整個程式碼集完成，最好是花上數年的時間。
請注意，這些網站很多都是舊網站，可能未經維護。 即使維護人員仍在移動，他們可能並非 我們不希望每個人都會前往 任職於 8 年時，因網路相容性問題而變更網站。
TC39 程序如何運作？
TC39 負責透過 符合 ECMAScript 標準的
因為 #SmooshGate 導致某些人認為「TC39 將 flatten 重新命名為」
smoosh」的內容，但這是彼此的笑話，但整體來說欠缺妥善溝通。
我們並不慎重考慮重新命名提案等重大決策
且即便只使用單一人物，也不保證會在夜間
GitHub 註解。
TC39 針對功能提案製定了明確的預備流程。
ECMAScript 提案及任何重大異動 (包括方法)
(重新命名) 在 TC39 會議期間有討論，且經過
讓所有委員會在正式擔任委員會前如果選擇
Array.prototype.flatten，提案已經過數項程序
到第 3 階段，這表示功能
立即使用一般而言，其他規格是
會出現一些問題在本例中
在嘗試提交功能「之後」收到的意見回饋：功能處於目前狀態
破壞網路。這類難以預測的問題是原因之一
瀏覽器推出功能時， TC39 程序不會只此結束。
TC39 是在共識運作，也就是說，委員會必須針對任何新的
並輸入變更內容即使smoosh是你的批評指控，也有可能是
委員會成員會反對其反對，改用更常見的姓名，例如
compact 或 chain。
將「flatten」更名為「smoosh」(即使您不是笑話)
從未在 TC39 會議中討論過因此，TC39 針對
目前無法查看這個主題。沒有人可以代表
所有資訊公開和同意聲明架構，直到下一場會議達到共識為止。
TC39 會議通常由背景各異的人參加 背景：有些具備多年的程式設計語言設計經驗 這是因為一些項目都在瀏覽器或 JavaScript 引擎上運作，而隨著 代表 JavaScript 開發人員社群。
SmooshGate 是如何解決的？
在 2018 年 5 月 TC39 會議期間，#SmooshGate
將 flatten 重新命名為 flat，正式解決了。
Array.prototype.flat 和 Array.prototype.flatMap 已於 V8 v6.9 與
Chrome 69。