Decorative images in f-vue-icons

[ashleynolan]

We've had a few discussions around how we could potentially include decorative images so that they can be served via cdn rather than inlining them in the bundle of a component.

During a conversation on a separate PR, I remembered that all of our icons in f-icons automatically get published to unpkg (which pushes all dist assets up to cloudflare) – so I was thinking a similar solution should be:

1. Decorative SVG's could be added to f-vue-icons
2. Either
a) we use unpkg (probably not recommended as we probably shouldn't rely on a hobby project for serving our images) or
b) we link our own CDN to grab latest distribution files from the f-icons package (guessing this should be possible as that's effectively what unpkg does)
3. We then modify f-vue-icons to accept a bit of config when asking for an icon so that instead of outputting an inline SVG icon as the result, it instead outputs an image such as:

<!-- Example with unpkg link – could just be our own cdn path -->
<img src="https://unpkg.com/@justeat/f-icons/dist/icons/alert.svg" alt="{ALT_TEXT}">

The above would mean non critical SVGs are then served via CDN, and not bundled inline inside our components, making the bundle size smaller.

Thoughts? If anyone has any idea how easy part 2. b) would be, that would be awesome, as that's the only part I'm unsure about really. Not sure if it would just be some CDN config somewhere that we could point at NPM (or something we could add into the build of f-icons to push the dist folder up to CDN?)

[SachaZvetelman]

Re 2.b), I guess what we should do is to basically upload whatever is on f-icons to a specific S3 bucket, which is then exposed via a CloudFront distribution. In a way, it's not very different from what we do with some of our static assets.
If we do something like that, we can also use different buckets depending on the environment, so that we can do gradual rollouts of a specific image (or we can use a single bucket and do some versioning on the files).

Regarding the following:

The above would mean non critical SVGs are then served via CDN, and not bundled inline inside our components, making the bundle size smaller.

Maybe a stupid question, but is there any reason not to do this with every single image, rather than just non-critical SVGs?

[DamianMullins]

One downside is that you are no longer able to version the assets and so if, for example, sizes change then your CSS will also need to be updated separately.

[minrwhite]

Unless you make the package version part of the path? E.g.

https://some.je-cdn-endpoint/@justeat/f-icons/(x.y.z|latest)/dist/icons/alert.svg

[ashleynolan]

Couple of tradeoffs to including SVGs like this (as an img tag vs inline):

• Inlining an SVG means it'll be loaded as part of a pages first render – so if it's a critical icon for UX I'd say we should still load those icons inline
• You can't use CSS to change the fill colour of the icon if it's loaded as an img tag (only if it's inlined), so it loses some flexibility for icons that need to change colour on hover etc, or that are sometimes blue because of link styling.

Most critical icons we use are small enough to be inlined and not really affect the bundle size too much. I think the issues we've seen so far have come from icons like in the footer (lots of flag icons or social icons that don't need to be included in the first render of a page) or for more complex SVGs like on registration or Checkout, which we definitely shouldn't be inlining.

[kevinrodrigues]

Just a few things I tried in my spare time that's worth looking into. I also asked around in the webpack and Vue community as the below wouldn't quite work for me (in the consuming app side, step 4)

We could set babel to allow esmodules, setting this to true allows for selective imports. That way we could just bundle what we want in f-vue-icons but then in our components e.g footer or header we can mark it as the following:

1. In webpack: externals: [ 'f-vue-icons'] (Won't bundle it)
2. Components mark f-vue-icons as a peer dep.
3. In babel turn on esmodules: true (i think this is the key part for exposing the builds as modules but for some reason webpack wasn't resolving it properly)
4. The consuming app can then add it as a dependency and then whatever they use icon wise gets pulled in.

Main advantage of the above means there's not much extra effort config wise.