As per the Google Doc report, I created, I wrote this at that time -
We’re having SVG icons and a convertor function which is converting .svg icons into .js icon components.
Both of them are having the same cumulative size of 48KB.
The problem with this is that, in some places we are importing .js icons and in some places .svg files which is not consistent at all.
A better solution would be to -
Categorize the icons.
We are having icons starting with Category and others with Nettest. We can categorize them as per these two.
Use an icon generator like Icomoon to generate a font file of category icons and nettest icons.
At last, with the help of CSS and HTML provided by them, we can create a reusable component.
Total size of font files - CategoryIcons.woff and NettestIcons.woff - (13+6) KB
The use case of this is that we can create as many component files like CategoryIcons following the same method in the @ooni/fonts package and export/import as per our use-case.
Sarath's reply -
1. On Icomoon
It appears that Icomoon is a proprietary product. We usually prefer integrating free and open source products/services to use in OONI's projects. We can probably look around for alternatives if needed.
2. No. of increasing font files
It seems like every page will have the entire library of icons loaded as a font file. I wonder if this is effective in terms of scalability. Doesn't the size of the loaded file grow as the number of icons increases? Is there some way to do tree-shaking with this?
So, I went through his points and came to some conclusions that -
Icomoon process is all manual, we cannot go with the manual process of uploading the new icon along with the older ones to the Icomoon app and download a new font file. So, this is a no no.
Yes, instead of creating separate font files for every page, we will be better off with one file.
As per the Google Doc report, I created, I wrote this at that time -
We’re having SVG icons and a convertor function which is converting .svg icons into .js icon components. Both of them are having the same cumulative size of 48KB. The problem with this is that, in some places we are importing .js icons and in some places .svg files which is not consistent at all.
A better solution would be to -
Total size of font files - CategoryIcons.woff and NettestIcons.woff - (13+6) KB
The use case of this is that we can create as many component files like CategoryIcons following the same method in the @ooni/fonts package and export/import as per our use-case.
Sarath's reply -
1. On Icomoon It appears that Icomoon is a proprietary product. We usually prefer integrating free and open source products/services to use in OONI's projects. We can probably look around for alternatives if needed.
2. No. of increasing font files It seems like every page will have the entire library of icons loaded as a font file. I wonder if this is effective in terms of scalability. Doesn't the size of the loaded file grow as the number of icons increases? Is there some way to do tree-shaking with this?
So, I went through his points and came to some conclusions that -
Google Material Icons follow the process of one font file, which can be found on this link - https://fonts.googleapis.com/icon?family=Material+Icons. And they got a npm package for icons which is open source - https://github.com/google/material-design-icons
We can follow the same process of generating the icons and creating a separate directory of ooni icons.