Heim > Artikel > Web-Frontend > Polyfills – ein Füller oder ein klaffendes Loch? (Teil-1)
Vor ein paar Tagen erhielten wir im Teams-Chat unserer Organisation eine Prioritätsnachricht mit der Aufschrift: Sicherheitslücke gefunden – Polyfill-JavaScript erkannt – HOCH.
Um einen Kontext zu geben: Ich arbeite für ein großes Bankunternehmen und wie Sie wissen, sind Bank- und Sicherheitslücken wie große Feinde. Also begannen wir, uns eingehend mit der Angelegenheit zu befassen, und konnten das Problem innerhalb weniger Stunden lösen, worauf ich im Folgenden eingehen werde. Aber das Gute (oder das Schlimmste?) daran ist, dass ich, als ich anfangs über das Problem gegoogelt habe, von den angezeigten Suchergebnissen für den Rest des Tages gefesselt war!
Lassen Sie uns eine Diskrepanz zwischen einem modernen und einem älteren Browser hervorheben. Hier ist ein Vergleich der neuesten Chrome-Version mit Internet Explorer (IE) 9. Moderne Browser unterstützen eine ganze Reihe von ES6-Funktionen und gleichzeitig unterstützen IE9 und auch IE11, die immer noch von vielen Unternehmen verwendet werden, kaum ES6-Funktionen .
Hier hilft das Konzept des Transpiling, das sich im Kontext von JavaScript auf die Konvertierung von in modernem JavaScript (ES6/ES2015 und höher) geschriebenem Quellcode in eine ältere Version wie ES5 bezieht , das von älteren Browsern weitgehend unterstützt wird. Ein sehr beliebter Transpiler ist Babel, der eine Reihe von Funktionen wie Syntaxtransformation, Code-Bündelung (zusammen mit Webpack) und Unterstützung für JSX (für unseren lieben Freund React!) bietet.
Mittlerweile ist der Einsatz von Transpilern an Orten mit viel moderner Syntax weit verbreitet und man muss die Kompatibilität zwischen verschiedenen Umgebungen sicherstellen. Beachten Sie, dass das Konvertieren einer gesamten Codebasis in eine andere Version sehr viel Zeit erfordert und auch das Einrichten eines Build-Prozesses und zusätzlicher Konfigurationen für Dinge wie Babel erfordert. Es versteht sich von selbst, dass neben der Konvertierung syntaktischer Funktionen auch die API-Funktionalität zur Erweiterung derselben Funktionsreplikation in alten Browsern abgedeckt ist.
Was die Referenz von Babel angeht: Es handelt sich um viele Pakete, die Plugins für verschiedene Arten von Funktionen bereitstellen, wie z. B. die Umwandlung von ES6-Klassen, Pfeilfunktionen usw. in äquivalenten JS-Code. Darunter bietet es auch ein eigenes „Polyfill“-Paket an.
Polyfills sind Codeteile, die es alten Browsern ermöglichen, dieselbe/fast dieselbe JS-Funktionalität bereitzustellen, die sie nicht nativ bereitstellen, die in neueren Browserversionen angezeigt wird. Hier ist ein kurzes Videobeispiel und eine sehr einfache Implementierung.
Nun könnte man denken: Was ist dann der Unterschied zwischen Transpilern und Polyfillern? Nun, Polyfills konzentrieren sich auf die Emulation spezifischer APIs, die fehlen, anstatt die gesamte Codebasis in eine alte, browserfreundliche Version zu ändern, die von Transpilern erstellt wird. Dies ermöglicht einen detaillierteren Ansatz und macht ihn natürlich effizienter und leistungsfähiger.
Das sollte uns genug Hintergrundwissen liefern, um zu verstehen, warum ich einen Tag lang süchtig danach war, bis ich dies über Polyfills schreibe.
Jetzt hat Babel ein Paket namens babel/polyfill, das aus zwei Bibliotheken besteht: core-js und regenerator-runtime. Der Import dieses Pakets würde zunächst alle Polyfills in Aktion setzen.
import '@babel/polyfill';
Aber wenn Sie alles einbeziehen, unabhängig davon, ob Ihr Projekt es verwenden würde oder nicht, erhöht sich die Paketgröße und das globale Einfügen von Polyfills kann zu Konflikten in Objekten führen.
Dies führte dazu, dass das Paket nicht mehr unterstützt wurde und Babel empfiehlt, die core-js-Bibliothek direkt von
zu verwenden
Schritt 1: Ändern der Babel-Konfiguration
{ "presets": [ ["@babel/preset-env", { "useBuiltIns": "usage", "corejs": 3 }] ] }
Schritt 2: Importieren Sie manuell die Polyfills, die Sie in Ihrem Projekt verwenden würden
import "core-js/es/array/includes"; import "core-js/es/promise";
Dadurch wird Speicherplatz gespart und unnötiger Code reduziert.
Dies ist nun das Ende eines Teils, der an sich nicht so besorgniserregend ist, aber im Hinblick auf ein Projekt auf jeden Fall wichtig ist, um über die Änderungen in den Abhängigkeiten auf dem Laufenden zu bleiben und seinen Kunden ein besseres Erlebnis zu bieten.
ABER. Das ist noch nicht alles.
Wir sprechen gerade über einen großen Angriff, der vor Kurzem stattfand und das gesamte Internet durcheinander brachte und dazu führte, dass die Codebasis durchsucht wurde.
Und dazu gehört auch das, was wir hier besprochen haben. Seien Sie also gespannt auf den zweiten Teil!
Das obige ist der detaillierte Inhalt vonPolyfills – ein Füller oder ein klaffendes Loch? (Teil-1). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!