In de spritesheet zitten 176 iconen, het lijkt erop alsof we er ongeveer 50 voor de di mixins nodig hebben. We gaam een tweede spritesheet maken waar alleen die iconen inzitten. Deze tweede spritesheet wordt geen onderdeel van de public API van de DSO Toolkit. Alles wat met de DI mixins te maken heeft is een interne aangelegenheid en daarmee geen breaking change.
We moeten hier het buildproces en de Sass mixins voor aanpassen.
De hoofdinput zijn alle iconen (de SVG's). Die krijgen een eigen stylesheet, en elke <svg> wordt een <symbol>. Zoals ook de huidige spritesheet is opgebouwd.
In een andere spritesheet komen alleen maar <view> elementen. Dit is een subset van alle componenten. Voorstel is om de SCSS files naast de iconen als subset filter te laten zijn.
Aandachtspunt: Elk icon krijgt nu een <symbol> EN een <view>: Als de SCSS files leidend worden voor het genereren van een <view> voor een icoon, dan moet goed gekeken worden of alle iconen wel beschikbaar zijn.
Tevens onderzoeken of alle iconen die worden gestijld als variant in een SCSS "icon stylesheet" ook daadwerkelijk worden gebruikt.
Voetnoot
Ondanks dat het een optie is die niet schaalt. De toolkit levert al nieuwe HTML/CSS componenten meer. Web Componenten maken geen gebruik van de di mixins, maar van <dso-icon>. Ik verwacht daarom niet dat het gebruik van de di spritesheet noemenswaardig zal toenemen, ik houd er eerder rekening mee dat deze stylesheet gaat afbouwen.
Aanleiding
In #2813 is geconstateerd dat de DI mixins (
@include di.base()
en@include di.variant()
) constante CPU usage veroorzaken.Zie deze comment in #2813 voor de onderbouwing en conclusie.
Oplossing
In de spritesheet zitten 176 iconen, het lijkt erop alsof we er ongeveer 50 voor de
di
mixins nodig hebben. We gaam een tweede spritesheet maken waar alleen die iconen inzitten. Deze tweede spritesheet wordt geen onderdeel van de public API van de DSO Toolkit. Alles wat met de DI mixins te maken heeft is een interne aangelegenheid en daarmee geen breaking change.We moeten hier het buildproces en de Sass mixins voor aanpassen.
De hoofdinput zijn alle iconen (de SVG's). Die krijgen een eigen stylesheet, en elke
<svg>
wordt een<symbol>
. Zoals ook de huidige spritesheet is opgebouwd.In een andere spritesheet komen alleen maar
<view>
elementen. Dit is een subset van alle componenten. Voorstel is om de SCSS files naast de iconen als subset filter te laten zijn.Aandachtspunt: Elk icon krijgt nu een
<symbol>
EN een<view>
: Als de SCSS files leidend worden voor het genereren van een<view>
voor een icoon, dan moet goed gekeken worden of alle iconen wel beschikbaar zijn.Tevens onderzoeken of alle iconen die worden gestijld als variant in een SCSS "icon stylesheet" ook daadwerkelijk worden gebruikt.
Voetnoot
Ondanks dat het een optie is die niet schaalt. De toolkit levert al nieuwe HTML/CSS componenten meer. Web Componenten maken geen gebruik van de
di
mixins, maar van<dso-icon>
. Ik verwacht daarom niet dat het gebruik van dedi
spritesheet noemenswaardig zal toenemen, ik houd er eerder rekening mee dat deze stylesheet gaat afbouwen.