SVG-Lader: Eine andere Art, mit externem SVG zu arbeiten

SVGs sind fantastisch: Sie sind klein, sehen auf jeder Skala scharf aus und können angepasst werden, ohne eine separate Datei zu erstellen. Es gibt jedoch etwas, was ich heute in Webstandards fehlt: eine Möglichkeit, sie als externe Datei einzubeziehen, die auch die Anpassungskräfte des Formats beibehält.

Angenommen, Sie möchten das Logo Ihrer Website als Web-logo.svg verwenden. Sie können:

 <img  src="/images/logo.svg" alt="SVG-Lader: Eine andere Art, mit externem SVG zu arbeiten" >

Das ist in Ordnung, wenn Ihr Logo überall gleich aussehen wird. In vielen Fällen haben Sie jedoch 2-3 Variationen desselben Logos. Slack hat zum Beispiel zwei Versionen.

Wenn wir eine Möglichkeit hätten, die Füllfarbe unseres Logos oben anzupassen, könnten wir jede willkürliche Farbe übergeben, um alle Variationen zu rendern.

Nehmen Sie auch den Fall von Ikonen. Du würdest so etwas nicht tun wollen, oder?

 <img  src="/icons/heart-blue.svg" alt="SVG-Lader: Eine andere Art, mit externem SVG zu arbeiten" >
<img  src="/icons/Heart-Red.svg" alt="SVG-Lader: Eine andere Art, mit externem SVG zu arbeiten" >

Laden Sie externe SVGs als Inline -Elemente

Um dies anzusprechen, habe ich eine Bibliothek namens SVG-Lader erstellt. Einfach ausgedrückt, es holt die SVG -Dateien über XHR ab und lädt sie als Inline -Elemente, sodass Sie die Eigenschaften wie Füllung und Schlaganfall anpassen können, genau wie Inline -SVGs.

Zum Beispiel habe ich ein Logo auf meinem Seitenprojekt, SVGBox. Anstatt für jede Variation eine andere Datei zu erstellen, kann ich eine Datei haben und die Füllfarbe anpassen:

Ich habe Daten-SRC verwendet, um die URL der SVG-Datei festzulegen. Das Füllattribut überschreibt die Füllung der ursprünglichen SVG -Datei.

Um die Bibliothek zu verwenden, muss ich nur sicherstellen, dass die Services geeignete CORS -Header für XHRs haben, um erfolgreich zu sein. Die Bibliothek zwischen den Dateien recherchiert vor Ort und macht den nachfolgenden viel schneller. Auch für die erste Last ist die Leistung vergleichbar mit der Verwendung von -Tags.

Dieses Konzept ist nicht neu. SVG-Injekt tut etwas Ähnliches. SVG-Loader ist jedoch einfacher zu verwenden, da wir die Bibliothek nur irgendwo in Ihren Code einbeziehen müssen (entweder über ein <script> -Tag oder in das JavaScript-Bundle). Es ist kein zusätzlicher Code erforderlich.</script>

Dynamisch addierte Elemente und Änderungen der Attribute werden ebenfalls automatisch behandelt, wodurch sie mit allen Web-Frameworks funktioniert. Hier ist ein Beispiel in React:

Aber warum?

Dieser Ansatz fühlt sich möglicherweise unorthodox an, da er eine JavaScript -Abhängigkeit einführt und es bereits mehrere Möglichkeiten gibt, SVGs zu verwenden, einschließlich Inline und aus externen Quellen. Aber es gibt einen guten Fall, SVGs auf diese Weise zu verwenden. Lassen Sie uns sie untersuchen, indem wir die gemeinsamen Fragen beantworten.

Können wir nicht nur SVG selbst einbeziehen?

Das Inlining ist der einfachste Weg, SVGs zu verwenden. Kopieren Sie einfach den SVG -Code in die HTML. Das macht SVG-Lader letztendlich. Warum also die zusätzlichen Schritte zum Laden einer SVG -Datei von einem anderen Ort hinzufügen? Es gibt zwei Hauptgründe:

1. Inline -SVGs machen den Code ausführlich: SVGs können von ein paar Zeilen bis zu einigen hundert liegen. Inline -SVGs können gut funktionieren, wenn das, was Sie brauchen, nur ein paar Ikonen sind und sie alle winzig sind. Aber es wird zu einem großen Schmerz, wenn sie beträchtlich oder viele sind, denn dann werden sie zu langen Textketten in Code, die nicht „Geschäftslogik“ sind. Der Code wird schwer zu analysieren.
   
   Es ist dasselbe wie die Bevorzugung eines externen Stylesheets gegenüber einem

2. Externe SVGs sind viel bequemer: Das Kopieren und Einfügen von SVGs macht die Arbeit oft, aber externe SVGs können sehr bequem sein. Angenommen, Sie experimentieren mit welchem ​​Symbol in Ihrer App. Wenn Sie Inline -SVGs verwenden, bedeutet dies, dass Sie hin und her gehen, um den SVG -Code zu erhalten. Mit externen SVGs müssen Sie jedoch nur den Namen der Datei kennen.
   
   Schauen Sie sich dieses Beispiel an. Eines der umfangreichsten Icon -Repository für GitHub sind Materialdesign -Symbole. Mit SVG-Lader und UNPKG können wir sofort 5.000 Symbole verwenden.

Ist es nicht ineffizient, eine HTTP -Anforderung für jedes SVG auszulösen, anstatt ein Sprite zu machen?

Nicht wirklich. Mit HTTP2 sind die Kosten für die Erstellung einer HTTP -Anfrage weniger relevant geworden. Ja, es gibt immer noch Vorteile von Bündelung (z. B. bessere Komprimierung), aber für nicht blockierende Ressourcen und XHRs sind die Profis in realen Szenarien fast nicht vorhanden.

Hier ist ein Stift, der 50 Symbole auf ähnliche Weise wie oben lädt. (Im Inkognito -Modus öffnen, da die Dateien standardmäßig zwischengespeichert werden):

Was ist mit

SVG -Symbole trennen die Definition der SVG -Datei von ihrer Verwendung. Anstatt das SVG überall zu definieren, können wir so etwas haben:

 <svg>
  <verwenden sie xlink: href="#Heart-Icon"></verwenden>
</svg>

Das Problem ist, dass keiner der Browser die Verwendung von Symboldateien unterstützt, die auf einer Drittanbieterdomäne gehostet werden. Deshalb können wir so etwas nicht tun:

 <svg>
  <verwenden sie xlink: href="https://icons.com/symbols.svg#heart-icon"></verwenden>
</svg>

Safari unterstützt nicht einmal Symbole -Dateien, die auf derselben Domäne gehostet werden.

Können wir kein Build -Tool verwenden, das die SVGs einhält?

Ich konnte keinen offensichtlichen Weg finden, SVGs aus einer URL zu holen und sie in gemeinsamen Bundlern wie Webpack und Grunzen einzubeziehen, obwohl sie vorhanden sind, um SVG -Dateien zu integrieren, die lokal gespeichert sind. Auch wenn ein Plugin, das dies tut, vorhanden ist, ist es nicht gerade einfach, Bundesbundler einzurichten. Tatsächlich vermeide ich sie oft, sie zu verwenden, bis das Projekt eine Kennzahl der Komplexität erreicht hat. Wir müssen auch erkennen, dass ein Großteil des Internets Dingen wie Webpack und Reagieren fremd ist. Einfache Skripte können eine viel größere Anziehungskraft haben.

Was ist mit dem -Tag?

Das Tag> -Tag ist eine native Möglichkeit, externe SVG -Dateien aufzunehmen, die über alle Browser hinweg funktionieren.

 <objektdaten protected width="32" height="32"> </objektdaten>

Der Nachteil ist jedoch, dass wir die Attribute des SVG nicht anpassen können, es sei denn, sie werden auf derselben Domäne gehostet (und das -TAG respektiert die CORS -Headers nicht). Auch wenn die Datei auf derselben Domain gehostet wird, müssen JavaScript die Füllung wie folgt manipulieren:

 <objektdaten protected width="32" height="32" onload="this.contentDocument

Kurz gesagt, die Verwendung von externen SVG-Dateien auf diese Weise macht es extrem überzeugt, Symbole und andere SVG-Assets zu verwenden. Wie früher abgedeckt, können wir mit UNPKG jedes Symbol auf GitHub verwenden, ohne zusätzlichen Code zu benötigen. Wir können vermeiden, eine Pipeline in einem Bundler zu erstellen, um SVG -Dateien oder eine Komponente für jedes Symbol zu verarbeiten und die Symbole auf einem CDN zu hosten.

Das Laden von SVG -Dateien auf diese Weise bietet viele Vorteile mit sehr geringen Kosten.

">

Das obige ist der detaillierte Inhalt vonSVG-Lader: Eine andere Art, mit externem SVG zu arbeiten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!