Split sprites in individual svg files

[hbruch]

Currently, svg icons are provides as a theme dependent sprites (default and hsl in this repo, addtional ones in downstream repositories). They are hard to maintain and contain much duplication.

For the embark-okc fork, we split them into indiviual svg files, and recreate the sprites in the static build step.

I suggest to do this upstream as well, as these individual svgs are easier to update, easier to override by inheriting themes, and could make of use includes to reduce duplication.

Should I provide a PR for this or do you have other plan?

Another question is what the long term strategy for icons is. digitransit-component-icon also duplicates many icons, but it is not evident, when to use this in contrast to the sprites approach, and how to support different themes.

[hbruch]

@vesameskanen any thoughts on this?

[vesameskanen]

We don't have any plans yet. I feel that we should have some sort of brainstorming session to figure out what to do.

[vesameskanen]

I had a quick look. Current problems:

• Sprite sheets are so large that they are hard to manage
• Names are cryptic and unfriedly, no conventions to help
• Some svg 's are messy, apparently straight from some drawing software
• We use two parallel icon solutions, one sheet based and another from digitransit components
• Styling is somewhat complicated - e.g. it is hard to see which colors come from css and which from props.

Anyway, the interface which digitransit-component-icon library exposes is simple: <Icon img="arrow" width=2 heigth=2 color="#888888" />

It might make sense to move all icons directly to component-icon library, and expand its api to include all features that app/component/Icon.js has.

Any thoughts?

[hbruch]

I'v got some reservations moving the icons to the digitransit-component-icon library. IMHO the developer experience with these components is not the best and I wonder how an extension mechanism for external instances would look like. Would HSL accept and integrate third-party icons in this component?

Treating icons as components is presumably the mid-term /long-term goal to achieve. The idea has been around for a while but apparently seemed to overwhelming until now.

The proposed splitting and reassembly during build could be an easy first step as it allows to address you bullet points 1-3.

Another advantage would be that this way, icons could be moved step by step to the digitransit-componen-icon library. Especially rebuilding the map-icon handling could be postponed until perhaps a switch to another map library would make it unneeded anyway.