Was ist mit dem Lämpchen passiert?!
Ein Angebot für ein JavaScript
der Sprachfunktion Array.prototype.flatten
Nicht mit dem Web kompatibel. Der Versand der Funktion in Firefox Nightly verursachte mindestens eine beliebte Website.
zu brechen. Da der problematische Code Teil des weitverbreiteten MooTools ist,
sind wahrscheinlich viel mehr Websites betroffen. (Trotzdem MooTools
wird 2018 nicht mehr häufig für neue Websites verwendet. Sie war früher sehr beliebt und
noch auf vielen Produktionswebsites vorhanden ist.)
Der Angebotsautor hat scherzhaft vorgeschlagen, "flatten" in "smoosh" umzubenennen in
um Kompatibilitätsprobleme zu vermeiden. Dieser Witz war nicht für alle klar, manche
glaubten sie fälschlicherweise, der neue Name sei bereits
und die Sache eskalierte schnell.
Was macht Array.prototype.flatten?
Array.prototype.flat, ursprünglich vorgeschlagen als Array.prototype.flatten,
Vereinfacht Arrays rekursiv bis zum angegebenen depth, der als Standardeinstellung festgelegt ist.
an 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]
Dieses Angebot enthält Array.prototype.flatMap, was
Array.prototype.map mit dem Unterschied, dass das Ergebnis in einem neuen Array vereinfacht wird.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
Wodurch wird dieses Problem von MooTools verursacht?
MooTools definiert eine eigene, nicht standardmäßige Version von Array.prototype.flatten:
Array.prototype.flatten = /* non-standard implementation */;
Die flatten-Implementierung von MooTools weicht vom vorgeschlagenen Standard ab.
Das ist jedoch nicht das Problem. Verfügbarkeit von Browsern
Array.prototype.flatten nativ überschreibt, überschreibt MooTools die
Implementierung. Dadurch wird Code, der auf dem MooTools-Verhalten basiert,
funktioniert wie vorgesehen, unabhängig davon, ob die native flatten verfügbar ist.
So weit, so gut!
Leider passiert dann etwas anderes. MooTools kopiert alle seine
benutzerdefinierten Array-Methoden an Elements.prototype senden (wobei Elements ein
MooTools-spezifische API):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for–in iteriert über „auflistenbare“ Properties, die keine
native Methoden wie Array.prototype.sort, enthält aber
regelmäßig zugewiesenen Properties wie Array.prototype.foo = whatever. Aber –
Das ist der Punkt, an dem Sie eine nicht aufzählbare Eigenschaft überschreiben, z.B.
Array.prototype.sort = whatever ist, bleibt er nicht aufzählbar.
Derzeit erstellt Array.prototype.flatten = mooToolsFlattenImplementation
Eine aufzählbare flatten-Eigenschaft, die später nach Elements kopiert wird. Wenn aber
eine native Version von flatten ausliefern, wird diese nicht mehr aufzählbar und
wird nicht nach Elements kopiert. Jeder Code, der auf den MooTools-
Elements.prototype.flatten ist jetzt nicht erreichbar.
Es sieht zwar so aus, als würde die native Array.prototype.flatten in
würde das Problem durch aufzählbare Elemente behoben werden,
Kompatibilitätsprobleme. Jede Website, die auf for-in iteriert,
ein Array (was nicht gut ist, aber passiert), dann plötzlich
eine zusätzliche Schleifeniteration für das Attribut flatten.
Das größere zugrunde liegende Problem hier sind die Änderung integrierter Objekte. Wird verlängert werden native Prototypen heutzutage generell nicht akzeptiert, lässt sich nicht gut mit anderen Bibliotheken und Drittanbietercode kombinieren. Nicht ändern Objekte, die Ihnen nicht gehören!
Warum behalten wir nicht einfach den bisherigen Namen bei und zerstören das Web?
1996, bevor CSS verbreitete wurde und „HTML5“ lange bevor die Space Jam-Website wurde veröffentlicht. Die Website funktioniert auch heute noch, so wie vor 22 Jahren.
Wie ist das passiert? Hat jemand die Website all die Jahre gepflegt, jedes Mal aktualisiert werden, wenn Browseranbieter eine neue Funktion veröffentlicht haben?
Wie sich herausstellt, ist „das Web nicht brechen“ das wichtigste Designprinzip. für HTML, CSS, JavaScript und alle anderen Standards, die im Web Wenn die Lieferung einer neuen Browserfunktion dazu führt, dass bestehende Websites nicht mehr existieren funktioniert, schadet das für alle:
- Bei Besuchern der betroffenen Websites ist die Nutzererfahrung plötzlich beeinträchtigt.
- von einer perfekt funktionierenden Website zu einer ohne dass sie etwas verändern.
- dass Browser-Anbieter, die die neue Funktion liefern, Marktanteile verlieren, da die Nutzenden den Browser wechseln, nachdem Sie bemerkt haben, „dass es mit Browser X funktioniert“;
- Sobald das Kompatibilitätsproblem bekannt ist, verweigern andere Browseranbieter den Versand . Die Funktionsspezifikation entspricht nicht der Realität („nichts als eine Fiktion“). was für den Standardisierungsprozess schlecht ist.
Im Nachhinein hat MooTools das Falsche getan, aber das Web kaputt. nicht für sie, sondern für die Nutzenden. Diese Nutzer wissen nicht, ist. Alternativ können wir eine andere Lösung finden und die Nutzer können fortfahren. um das Web zu nutzen. Die Entscheidung ist einfach.
Bedeutet das, dass fehlerhafte APIs nie von der Webplattform entfernt werden können?
Das ist unterschiedlich. In seltenen Fällen können schlechte Funktionen aus dem Web entfernt werden. Es reicht nicht aus, herauszufinden, ob es möglich ist, eine Funktion zu entfernen, erfordert umfangreiche Telemetriedaten, um zu quantifizieren, wie viele Webseiten geändert hat. Ist die Funktion jedoch nicht sicher, schadet es dem Nutzer, oder sehr selten verwendet wird, ist das möglich.
<applet>, <keygen> und
showModalDialog() sind alle
Beispiele für fehlerhafte APIs, die erfolgreich von der Webplattform entfernt wurden.
Warum beheben wir nicht einfach MooTools?
Es ist sinnvoll, MooTools so zu patchen, dass integrierte Objekte nicht mehr erweitert werden. Idee. Das vorliegende Problem wird dadurch jedoch nicht gelöst. Selbst wenn MooTools um eine Patchversion zu veröffentlichen, müssten alle bestehenden Websites, die diese Version nutzen, zum Beheben des Kompatibilitätsproblems.
Können Nutzer nicht einfach ihre Kopie von MooTools aktualisieren?
In einer perfekten Welt veröffentlichte MooTools einen Patch und jede einzelne Website mit MooTools am nächsten Tag aktualisiert. Problem gelöst, oder?!
Das ist leider unrealistisch. Selbst wenn jemand irgendwie identifizierte, alle betroffenen Websites enthält, finden Sie Kontaktinformationen für Sie wenden sich erfolgreich an alle Websiteinhaber, und sie alle davon zu überzeugen, die Aktualisierung durchzuführen (was eine Refaktorierung gesamte Codebasis), würde der gesamte Prozess bestenfalls Jahre in Anspruch nehmen.
Beachten Sie, dass viele dieser Websites veraltet sind und wahrscheinlich nicht mehr verwaltet werden. Auch wenn der Pfleger noch da ist, ist es möglich, dass er kein versierten Webentwickler wie Sie. Wir können nicht erwarten, dass alle und seine acht Jahre alte Website aufgrund eines Webkompatibilitätsproblems ändern.
Wie funktioniert der TC39-Prozess?
TC39 ist der Ausschuss, der die Entwicklung der JavaScript-Sprache durch dem ECMAScript-Standard.
#SmooshGate brachte einige auf die Idee, dass „TC39 möchte flatten umbenennen in
smoosh“, aber es war ein Scherz, der extern nicht gut kommuniziert wurde.
Wichtige Entscheidungen wie die Umbenennung eines Angebots werden nicht leichtfertig getroffen,
von einer einzigen Person durchgeführt
und auf keinen Fall über Nacht eingenommen werden,
GitHub-Kommentar.
TC39 nutzt für Funktionsvorschläge einen klaren Staging-Prozess.
ECMAScript-Vorschläge und alle größeren Änderungen daran (einschließlich Methoden
Umbenennung) werden bei TC39-Meetings besprochen und müssen vom
bevor sie offiziell werden. Im Fall von
Array.prototype.flatten, das Angebot wurde bereits mehrere Male überprüft
bis hin zu Phase 3, in der angegeben wird, dass das Element
und kann in Webbrowsern implementiert werden. Häufig sind zusätzliche Spezifikationen
bei der Implementierung auftreten. In diesem Fall ist die wichtigste
Feedback kam nach dem Versuch, die Funktion zu versenden: In ihrem aktuellen Zustand
bricht das Web. Schwierige Probleme wie diese sind unter anderem der Grund dafür,
Der TC39-Prozess endet nicht nur mit der Bereitstellung einer Funktion durch den Browser.
TC39 basiert auf dem Konsens, d. h. der Ausschuss muss sich auf alle neuen
Änderungen. Auch wenn smoosh ein ernster Vorschlag gewesen wäre, scheint es, dass
würde ein Ausschussmitglied dagegen Einspruch erheben und stattdessen einen gebräuchlicheren Namen wie
compact oder chain.
Die Umbenennung von flatten in smoosh erfolgt
nie bei einem TC39-Meeting diskutiert wurden. Daher gilt die offizielle Haltung von TC39
Dieses Thema ist derzeit unbekannt. Keine Einzelperson kann im Namen von
alle TC39-Mitglieder, bis beim nächsten Meeting
ein Konsens erreicht wird.
TC39-Meetings werden in der Regel von Menschen mit sehr unterschiedlichem Einige haben jahrelange Erfahrung im Design von Programmiersprachen, andere arbeiten an einem Browser oder einer JavaScript-Engine. Immer mehr Assistenten dienen dazu, die JavaScript-Entwickler-Community zu repräsentieren.
Wie wurde SmooshGate schließlich gelöst?
Während der TC39-Konferenz im Mai 2018 hat #SmooshGate
wurde offiziell geklärt, indem flatten in flat umbenannt wurde.
Array.prototype.flat und Array.prototype.flatMap in V8, Version 6.9, und
Chrome 69.