1. Start
  2. Praxis
  3. Ein Sprite-Sheet migrieren

Geschichte — Frontend-Entwicklung

Ein altes Sprite-Sheet migrieren, das niemand neu bauen konnte

„Wir stiegen auf einzelne Icon-Komponenten um. Der Haken: Die bisherigen Icons waren ein einziges SVG-Sprite, überall per <use> referenziert, und der Build-Schritt, der es erzeugte, war zwei Refactorings zuvor gelöscht worden. Wir hatten das Sprite in Produktion und nichts, was es herstellte.“

Der Ausgangspunkt

Das Sprite lief einwandfrei — es ließ sich nur nicht zerlegen

Wer
Priya, Frontend-Entwicklerin, die eine Komponentenmigration in einer langlebigen Webanwendung leitet.
Stack
React + TypeScript, Vite, eine SVGR-Pipeline für neue Icons. Die alten Icons lagen in einer einzigen sprite.svg mit <symbol>-Definitionen.
Die Aufgabe
Rund 30 Sprite-Symbole in einzelne .svg-Dateien verwandeln, um sie durch SVGR zu schicken und als typisierte Komponenten auszuliefern.
Die Wand
Jedes Icon auf dem Bildschirm war ein <use href="#icon-x">-Zeiger. Den Zeiger zu speichern bringt nichts. Der Generator war weg.

Was nicht funktionierte

„Die Sprite-Datei selbst herunterzuladen gibt dir ein großes Dokument voller <symbol>-Elemente, außen ohne viewBox und ohne Möglichkeit, eines davon allein zu zeichnen. Ich habe angefangen, es im Editor von Hand zu teilen — ein Symbol kopieren, in ein frisches <svg> wickeln, den viewBox vom symbol übertragen, hoffen, das richtige erwischt zu haben. Das ist mühsam und genau die Art Sache, bei der man einen stillen Fehler macht.“

Die <use>-Indirektion ist genau das, was Sprites im Browser effizient und beim Extrahieren schmerzhaft macht. Das gezeichnete Icon ist echt; was du greifen kannst, ist eine Referenz auf ein Fragment.

Der Wechsel

Priya ließ SVG Downloader auf einer Seite laufen, die die Icons nutzte. Statt die <use>-Zeiger zu übergeben, löste es jede Sprite-Referenz im selben Dokument zurück zur Geometrie des zugrunde liegenden <symbol> auf und baute daraus ein eigenständiges, zeichenbares SVG — viewBox intakt, Namensraum repariert.

erkennen → ZIP
Der komplette Durchlauf: den Satz erkennen, durchblättern, um zu bestätigen, dass jedes Symbol korrekt aufgelöst wurde, dann Alle als ZIP laden — dublettenfrei und nummeriert.

„Die Vorschauen waren die Vertrauensprobe. Ich blätterte durch, und jedes Symbol war da und zeichnete für sich — keine kaputte Referenz, das echte Icon. Dann gab mir Alle als ZIP laden den ganzen Satz, dublettenfrei, sodass Icons, die fünfmal auf der Seite vorkamen, nicht fünfmal herunterkamen. Ich habe direkt nach src/icons/ entpackt und SVGR über den Ordner laufen lassen.“

„Das Sprite war das eine Asset der ganzen Migration, von dem wir dachten, es bräuchte einen manuellen Neubau. Es wurde ein Import-Schritt. Der Rest des Tages ging in die eigentliche React-Arbeit.“

Priya Nandakumar, Frontend-Entwicklerin

Das Ergebnis

  • ~30 Symbolevon <use> in eigenständiges SVG aufgelöst, in einem ZIP
  • DublettenfreiIcons, die vielfach auf der Seite vorkamen, kamen einmal herunter
  • SVGR-bereitkorrekter viewBox und xmlns, direkt in die Pipeline
Was die Arbeit gemacht hat
Der Sprite-/<use>-Extraktor, um die Referenzen aufzulösen, dann Alle als ZIP laden für den ganzen Satz auf einmal.
Warum das rohe Sprite versagt
Eine heruntergeladene sprite.svg ist ein Sack voller <symbol>-Definitionen ohne eigenständige Darstellung — sie von Hand zu teilen verliert viewBoxes und lädt zu Abschreibfehlern ein. Siehe alle als ZIP laden.
Reichweite
Löst Sprite-Referenzen im selben Dokument auf. Externe Sprite-Dateien, die die Seite nie ins DOM lädt, sind nicht erreichbar — öffne eine Seite, die die Icons tatsächlich nutzt.

Zusammengesetzte Geschichte — ein illustrativer, aber typischer Ablauf. Person und Team sind fiktiv; das hier beschriebene Verhalten der Erweiterung ist echt. Mehr Geschichten →


Löse das Sprite auf, spar dir den Neubau

Verwandle <use>-Referenzen zurück in eigenständiges, zeichenbares SVG — den ganzen Satz als ZIP.