Kunstwerk: https://code-art.pictures/
Es mag heutzutage überraschend sein, aber der Internetverkehr ist in vielen Szenarien immer noch ein Problem. Mobilfunknetze verfügen oft über begrenzte Datentarife, die Akkus der Geräte sind nicht unbegrenzt und vor allem ist die Aufmerksamkeit des Benutzers beim Warten auf das Laden Ihrer Website begrenzt. Deshalb ist die Paketgröße immer noch wichtig. Hier sind sieben Tipps, die Sie berücksichtigen sollten.
Im Jahr 2020 pflegte ich eine Werbe-App für ein lokales soziales Netzwerk. Es handelte sich um eine typische React TypeScript-Webpack-Anwendung für ES5. Als Webpack 5 veröffentlicht wurde, entschied ich mich für ein Upgrade. Alles verlief reibungslos; Ich habe die Fehleranalyse und das Benutzerfeedback überwacht und es gab nichts Unerwartetes. Erst nach einer Woche entdeckte ich zufällig, dass mein Bundle Pfeilfunktionen enthielt – es war eine neue Webpack-Funktion.
Hier ist ein ausgezeichneter Artikel über den Zustand von ES5. Wichtige Erkenntnisse:
Hier sind einige Funktionen, mit denen Sie besseren und kompakteren Code schreiben können.
Generatoren sind eine effiziente Möglichkeit, verschachtelte Strukturen zu durchqueren:
type TreeNode<T> = { left?: TreeNode<T> value: T right?: TreeNode<T> }; function* traverse<T>(root: TreeNode<T>): Generator<T> { if (root.left) yield* traverse(root.left) yield root.value if (root.right) yield* traverse(root.right) }
Minifizierer wissen mit Sicherheit, dass diese Felder keine externe Verwendung haben können, auch nicht in exportierten Objekten, und es steht ihnen frei, ihre Namen zu kürzen.
Quelle
export class A { #myFancyStateObject }
Paket
export class A{#t}
Das funktioniert natürlich nicht mit privaten TypeScript-Feldern, da das Wissen, dass sie privat sind, verschwindet, sobald tsc seine Arbeit erledigt hat.
Haben Sie schon von Promise.withResolvers() oder Map.groupBy() gehört? Diese APIs sind zum Zeitpunkt des Verfassens dieses Artikels noch nicht allgemein verfügbar, werden es aber bald sein. Nehmen Sie sich jetzt einen Moment Zeit, um sich mit ihnen vertraut zu machen, und seien Sie bereit, sie in ein paar Jahren zu übernehmen.
Es gibt unzählige Blogs und Podcasts, aber ich finde, dass die besten „Newsletter“ neue .d.ts-Dateien im TypeScript-Repository sind. Öffnen Sie einfach zum Beispiel es2024.collection.d.ts und genießen Sie ?
Bemerken Sie das sich wiederholende Muster?
type TreeNode<T> = { left?: TreeNode<T> value: T right?: TreeNode<T> }; function* traverse<T>(root: TreeNode<T>): Generator<T> { if (root.left) yield* traverse(root.left) yield root.value if (root.right) yield* traverse(root.right) }
Wiederholter Code erhöht nicht nur die Paketgröße, sondern macht es auch schwieriger zu verstehen, was die einzelnen Teile bewirken. Dies führt häufig dazu, dass Entwickler neuen Code schreiben, anstatt vorhandene Dienstprogrammfunktionen zu identifizieren und wiederzuverwenden, was das Paket weiter aufbläht.
Es gibt bereits eine Fülle exzellenten Materials zu diesem Thema, daher empfehle ich, anstatt es noch einmal zu erzählen, einen Klassiker: Refactoring von Martin Fowler. Es deckt nicht nur einfache Beispiele wie das obige ab, sondern auch komplexe Fälle wie gekoppelte Hierarchien und wiederholte Designs.
Jetzt verbessern wir unser kleines Beispiel. Es scheint, dass die Klammer häufig verwendet wird, um Parameter auf Array-Indexbereiche zu beschränken, sodass wir eine Verknüpfung erstellen können:
export class A { #myFancyStateObject }
Diese Änderung macht deutlich, dass n wahrscheinlich eine Ganzzahl sein soll, die derzeit nicht überprüft wird. Außerdem wird ein nicht behandelter Randfall hervorgehoben: leere Arrays. Durch diese kleine Deduplizierung haben wir auch zwei potenzielle Fehler entdeckt ?
Ich erinnere mich nicht an die genaue Quelle dieses Sprichworts, aber ich denke, es ist genau richtig:
Overengineering bedeutet, ein Problem zu lösen, das Sie nicht haben.
In der Welt der Webentwicklung habe ich zwei Haupttypen von Overengineering beobachtet.
Bedenken Sie diesen Code. Die Auffüllungen sind Vielfache von 4 Pixeln und die Hintergrundfarben sind Blautöne. Dies ist wahrscheinlich kein Zufall, und wenn ja, könnte dies auf eine mögliche Duplizierung hinweisen. Aber verfügen wir wirklich über genügend Informationen, um die generische Button-Komponente zu extrahieren, oder überdimensionieren wir?
CSS
export class A{#t}
JSX
const clamp = (min, val, max) => Math.max(min, Math.min(val, max)) const x = clamp(0, v1, a.length - 1) const y = clamp(0, v2, b.length - 1) const z = clamp(0, v3, c.length - 1)
Dieser Rat steht etwas im Widerspruch zu „Vermeiden Sie Doppelarbeit.“ Eine übermäßige Deduplizierung von Code kann zu Overengineering führen. Wo ziehen Sie also die Grenze? Persönlich verwende ich die magische Zahl „3“: Sobald ich drei Stellen mit einem ähnlichen Muster sehe, ist es möglicherweise an der Zeit, die generische Komponente zu extrahieren.
Im Fall unserer blauen Schaltflächen wäre es meiner Meinung nach die beste Lösung, zumindest zum Auffüllen CSS-Variablen zu verwenden, anstatt eine neue Komponente zu erstellen.
Ja, ich spreche von dem, was wir lieben – Next.js, React, Vue und so weiter. Wenn Ihre App nicht viel Interaktivität auf der Ebene der DOM-Elemente beinhaltet, nicht dynamisch oder sehr einfach ist, ziehen Sie andere Optionen in Betracht:
Das aktuelle Ziel von TypeScript ist hauptsächlich die Typprüfung von JavaScript, aber das war nicht immer so. In den Tagen vor ES6 gab es viele Versuche, „besseres JavaScript“ zu entwickeln, und TypeScript bildete da keine Ausnahme. Einige Funktionen stammen aus diesen frühen Tagen.
Sie sind nicht nur schwierig richtig zu verwenden, sondern sie führen auch zu ziemlich ausführlichen Strukturen:
TypeScript
type TreeNode<T> = { left?: TreeNode<T> value: T right?: TreeNode<T> }; function* traverse<T>(root: TreeNode<T>): Generator<T> { if (root.left) yield* traverse(root.left) yield root.value if (root.right) yield* traverse(root.right) }
JavaScript
export class A { #myFancyStateObject }
Das offizielle TypeScript-Handbuch empfiehlt die Verwendung einfacher Objekte anstelle von Aufzählungen. Sie können auch Gewerkschaftstypen in Betracht ziehen.
Namespaces waren eine Modullösung vor ESM. Sie erhöhen nicht nur die Bundle-Größe, sondern da Namespaces global sein sollen, wird es auch wirklich schwierig, Namenskonflikte in großen Projekten zu vermeiden.
TypeScript
export class A{#t}
JavaScript
const clamp = (min, val, max) => Math.max(min, Math.min(val, max)) const x = clamp(0, v1, a.length - 1) const y = clamp(0, v2, b.length - 1) const z = clamp(0, v3, c.length - 1)
Verwenden Sie anstelle von Namespaces ES-Module.
Hinweis: Namespaces sind jedoch immer noch nützlich, um Typdefinitionen für globale Bibliotheken zu schreiben.
Mit jedem dieser kleinen Tricks können Sie mehrere bis Dutzende Bytes im Paket einsparen. Bei konsequenter Anwendung können sie ein sichtbares Ergebnis bringen.
Zum Beispiel ist eine leere Zeichenfolge falsch. Um zu überprüfen, ob es definiert und nicht leer ist, können Sie einfach Folgendes schreiben:
const clampToRange = (n, {length}) => clamp(0, n, length - 1) const x = clampToRange(v1, a) // ...
Ich glaube, dass die Verwendung von ==, um null in undefiniert umzuwandeln oder umgekehrt, völlig gerechtfertigt ist.
.btn-a { background-color: skyblue; padding: 4px; } .btn-b { background-color: deepskyblue; padding: 8px; }
<button className='btn-a' onClick={handleClick}> Show </button> // ... <button className='btn-b' onClick={handleSubmit}> Submit </button>
Stattdessen:
enum A { x, y }
Schreiben Sie dies:
var A; (function (A) { A[A["x"] = 0] = "x"; A[A["y"] = 1] = "y"; })(A || (A = {}));
Stattdessen:
namespace A { export let x = 1 }
Schreiben Sie dies:
var A; (function (A) { A.x = 1; })(A || (A = {}));
Sie können das Objekt auch einfrieren, um seine Eigenschaften vor Änderungen zu schützen.
Für jeden Bundler gibt es Tools zur Visualisierung seines Inhalts, z. B. Webpack-Bundle-Analyzer für Webpack und Vite-Bundle-Analyzer für Vite. Tools wie diese helfen Ihnen, häufige Probleme mit Ihrem Bundle zu identifizieren:
Zusätzlich zu diesen Tools ist es eine gute Idee, die Pakete gelegentlich manuell durchzulesen, um Unregelmäßigkeiten zu erkennen. Aufgrund einer TypeScript-Fehlkonfiguration finden Sie beispielsweise ES5-Helfer in einem ES6-Bundle oder CJS-Helfer in einem ESM-Projekt. Diese Probleme werden von automatisierten Tools möglicherweise nicht erkannt, können aber dennoch die Ladezeit verlängern und Sie möglicherweise Ihr wertvollstes Gut kosten – die Aufmerksamkeit des Benutzers.
Vielen Dank fürs Lesen. Viel Spaß beim Codieren!
Das obige ist der detaillierte Inhalt vonPraktische Tipps zur Minimierung Ihrer JavaScript-Bundle-Größe. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!