1. Accueil
  2. Histoires
  3. Migrer une planche de sprites

Histoire — ingénierie frontend

Migrer une vieille planche de sprites que personne ne pouvait reconstruire

« Nous passions à des composants d'icône individuels. Le hic : les icônes actuelles étaient un seul sprite SVG, référencé partout par <use>, et l'étape de build qui le générait avait été supprimée deux refactorisations plus tôt. Nous avions le sprite en production et rien qui le fabriquait. »

Le contexte

Le sprite fonctionnait très bien — il ne pouvait simplement pas être démonté

Qui
Priya, ingénieure frontend qui pilote une migration de composants sur une application web ancienne.
Stack
React + TypeScript, Vite, un pipeline SVGR pour les nouvelles icônes. Les anciennes icônes vivaient dans un unique sprite.svg avec des défs <symbol>.
La mission
Transformer une trentaine de symboles de sprite en fichiers .svg individuels à passer dans SVGR et livrer en composants typés.
Le mur
Chaque icône à l'écran était un pointeur <use href="#icon-x">. Enregistrer le pointeur ne donne rien. Le générateur avait disparu.

Ce qui ne marchait pas

« Télécharger le fichier de sprite lui-même donne un gros document plein d'éléments <symbol> sans viewBox à l'extérieur et sans moyen d'en afficher un seul isolément. J'ai commencé à le découper à la main dans un éditeur — copier un symbole, l'envelopper dans un <svg> neuf, reporter le viewBox depuis le symbol, espérer avoir pris le bon. C'est fastidieux et c'est exactement le genre de chose où l'on fait une erreur silencieuse. »

L'indirection <use> est précisément ce qui rend les sprites efficaces dans le navigateur et pénibles à extraire. L'icône affichée est réelle ; ce que vous pouvez attraper est une référence à un fragment.

Le changement

Priya a lancé SVG Downloader sur une page qui utilisait les icônes. Au lieu de remettre les pointeurs <use>, il a résolu chaque référence de sprite du même document jusqu'à la géométrie du <symbol> sous-jacent et l'a reconstruite en SVG autonome et affichable — viewBox intact, espace de noms réparé.

détection → zip
La passe complète : détecter le jeu, feuilleter pour confirmer que chaque symbole s'est bien résolu, puis Tout télécharger en ZIP — dédoublonné et numéroté.

« Les aperçus ont été la vérification de confiance. J'ai feuilleté et chaque symbole était là, s'affichant seul — pas une référence cassée, la vraie icône. Puis Tout télécharger en ZIP m'a donné tout le jeu, dédoublonné, si bien que les icônes présentes cinq fois sur la page ne sont pas descendues cinq fois. J'ai décompressé directement dans src/icons/ et lancé SVGR sur le dossier. »

« Le sprite était le seul actif de toute la migration dont nous pensions qu'il faudrait le reconstruire à la main. C'est devenu une étape d'import. Le reste de la journée est parti dans le vrai travail React. »

Priya Nandakumar, ingénieure frontend

Le résultat

  • ~30 symbolesrésolus de <use> en SVG autonome dans un seul ZIP
  • Dédoublonnéles icônes utilisées de nombreuses fois sur la page sont descendues une fois
  • Prêt pour SVGRviewBox correct et xmlns, directement dans le pipeline
Ce qui a fait le travail
L'extracteur de sprites / <use> pour résoudre les références, puis Tout télécharger en ZIP pour tout le jeu d'un coup.
Pourquoi le sprite brut échoue
Un sprite.svg téléchargé est un sac de défs <symbol> sans rendu autonome — le découper à la main perd les viewBox et invite les erreurs de recopie. Voir tout télécharger en ZIP.
Portée
Résout les références de sprite du même document. Les fichiers de sprite externes que la page ne charge jamais dans le DOM sont hors d'atteinte — ouvrez une page qui utilise réellement les icônes.

Histoire composite — un déroulé illustratif mais représentatif. La personne et l'équipe sont fictives ; le comportement de l'extension décrit ici est réel. Plus d'histoires →


Résolvez le sprite, sautez la reconstruction

Transformez les références <use> en SVG autonome et affichable — tout le jeu en un ZIP.