Bundle the icons package instead of using it as an external

[youknowriad]

The design team plan to add hundreds/thousands of icons to this package for third-party users. That makes it impossible to load it as its own script (bundle size). Instead we should encourage its usage via npm and tree-shaking.

This PR avoid creating a WordPress script entirely for this package and bundle it when used. The advantage also is that we can iterate on the package without making it a public API (so all breaking changes allowed) until we're certain of the result.

[sirreal]

👍 I reviewed the webpack changes and they make sense (with one correction). I have not manually tested.

If you'd like to test this, you could add an import of @wordpress/icons to the tests, maybe here:

gutenberg/packages/dependency-extraction-webpack-plugin/test/fixtures/with-externs/index.js

Lines 4 to 5 in 1f3ea11

	import { isBlobURL } from '@wordpress/blob';
	import { isURL } from '@wordpress/url';

[sirreal]

I think you meant to use an array of packages here:

Suggested change

	const BUNDLED_PACKAGES = '@wordpress/icons';
	const BUNDLED_PACKAGES = [ '@wordpress/icons' ];

---

This seems to only be relevant for packages in the @wordpress namespace (if we want to bundle other packages, they wouldn't be included below). We might lest those and handle them as needed:

Suggested change

	const BUNDLED_PACKAGES = '@wordpress/icons';
	const BUNDLED_PACKAGES = [ 'icons' ];

and changes below would become:

	if ( request.startsWith( WORDPRESS_NAMESPACE ) ) {
		const packageName = request.substring( WORDPRESS_NAMESPACE.length );
		if ( BUNDLED_PACKAGES.includes( packageName ) ) {
			return undefined;
		}
		return [ 'wp', camelCaseDash( packageName ) ];
	}

[senadir]

This might trip any package that has the word icons in it.

[sgomes]

Hey folks!

Is there any chance we could move away from SVG-in-JS for the icons, and instead adopt an SVG spritemap approach, like what is currently being done in Calypso for (at least; maybe there are others) gridicons and material-icons?

Tree-shaken JS is obviously better than including a full bundle of icons, but it's still SVG data encoded as JS. JS bytes are much more work for the browser than image bytes, as the latter go through fewer steps, and easier ones at that. Besides the image decoding and rendering (which needs to happen in both cases), a JS-encoded image still has to go through JS parsing, JS compilation, and JS execution.

In addition, unless care is specifically taken, this JS will end up being critical to the bundle it's included in. That is, the rest of the code will not execute until the image data JS is parsed, compiled, and executed as well. When using an external image resource, the browser will continue execution as normal and fill in the blank space when the resource finishes loading.

In general, browsers have a number of heuristics and hardcoded optimisations around resource prioritisation, but when an image is encoded in JS and treated as other code, they cannot be made use of.

An SVG spritemap approach is a good middle ground between using individual SVG files for everything (harder to maintain, potentially too many connections, but extremely cacheable) and embedding SVGs directly (no cacheability, but no extra connections either). It's a single SVG file containing all icons, and they are referenced through a <use> directive that references this external resource. It maintains full styleability, is supported by all modern browsers, and support can be polyfilled in older browsers with the svg4everyone polyfill.

SVG spritemaps are easy to generate, and could easily be kept up to date in clients with a build-time cache-busting mechanism that hashes the file and includes the hash in the filename, as we currently do with all static external resources in Calypso.

I'm happy to help everyone with implementing this approach if that helps!

[sgomes]

Here's an example of what making use of an external spritemap in a React component looks like:

return (
  <svg
    xmlns="http://www.w3.org/2000/svg"
    viewBox="0 0 24 24"
    className={ iconClass }
    height={ size }
    width={ size }
    onClick={ onClick }
    { ...otherProps }
  >
    <use xlinkHref={ `/public/the-sprite-map.svg#${ iconName }` } />
  </svg>
);

[youknowriad]

@sgomes Right now in Gutenberg, we're in a very bad state where icons are all over the place and that icons package move us to a better solution.

An SVG sprite sounds like an interesting solution for the most commonly used icons in WordPress but one of the goals as well is to be able to provide thousands of consistent icons to third-party block authors. Unless, I'm mistaken we don't want third-party block authors to load the entire set when they use just a custom icon for their block, so a tree-shaking based approach is needed any way I think.

[sgomes]

@youknowriad Thank you for the explanation! I'm not sure I follow, however.

Presumably, these third-party blocks will run in the Gutenberg environment, so if the full set of icons were already being loaded as an external resource by Gutenberg itself, that would actually be a great saving for third-party blocks, as they wouldn't incur any extra costs. Perhaps I'm missing some context?

[youknowriad]

Presumably, these third-party blocks will run in the Gutenberg environment, so if the full set of icons were already being loaded as an external resource by Gutenberg itself, that would actually be a great saving for third-party blocks, as they wouldn't incur any extra costs. Perhaps I'm missing some context?

Do you think loading the whole sprite of say 2000 of icons is reasonable while only 100 are used? Third party blocks will pick one or two icons and Core will use a hundred (random numbers)

[jasmussen]

One of the ideas is to make available the entirety of the Material icon set for developers to use any or multiple of the icons there: https://material.io/resources/icons/?style=outline (that's 4200+ icons, and while will probably not include all of them, the point is to provide a set that is so vast that no developer should have to look elsewhere, or need to reuse an existing icon because no alternative exists)

In that hypothetical, a subset of those icons would then be redrawn in the style explored in #18667, those are likely the ones that would be included.

Note also that as of writing, we are still supporting IE11, which I believe is not able to use spritesheets and recolor the icons also.

[gziolo]

@sgomes, thanks for sharing this very interesting idea. I have two questions:

• How complex it would be to create and expose those SVG maps in the Gutenberg plugin and later in WordPress core. How other web projects would use it? I anticipate that it might be a bit of work to set it all up properly unless there is some tooling which I don't know about.
• How about native mobile apps that probably can't use those SVG sprites but rather they have to load each icon one by one, see https://github.com/react-native-community/react-native-svg.

[sgomes]

Do you think loading the whole sprite of say 2000 of icons is reasonable while only 100 are used? Third party blocks will pick one or two icons and Core will use a hundred (random numbers)

I'm not able to estimate that very easily based on number of icons, I'm afraid, as the key thing would be file size and compressibility. I would expect a large spritemap to compress very well (lots of repeated textual data), which may well be an improvement over the tree-shaken SVG-in-JS approach by itself.

Beyond that, we need to look at cacheability and the compound effect in bytes over time that it produces. In a project like Calypso, JS changes much more frequently than image resources, with JS bundles being deployed multiple times a day. I don't know how things are on the Gutenberg side of things in that regard, but every time a new JS bundle is deployed, you're essentially causing all users to redownload all of the image resources in that bundle, since the whole bundle gets invalidated.

I'm happy to collaborate in getting some actual estimates if you're interested!

[jasmussen]

I just edited in my comment, but should have probably commented instead. Looking at https://github.com/google/material-design-icons there are more than 4200 SVG icons. While downloading a zip file of that repository is in no way an accurate representation of cacheability and resulting filesize, but for what it's worth the zip file is 64mb.

[sgomes]

Note also that as of writing, we are still supporting IE11, which I believe is not able to use spritesheets and recolor the icons also.

It is, through the svg4everyone polyfill. We make use of it in Calypso, which also supports IE11 as of writing.

[youknowriad]

every time a new JS bundle is deployed, you're essentially causing all users to redownload all of the image resources in that bundle, since the whole bundle gets invalidated.

I think we should think of this in WP scale. Basically on each WordPress release, I expect the JS to change, but I also expect at least one icon to be added or changed.

That said, I agree that it's better addressed with actual numbers but I don't want to start with a sprite because it's a public API we won't be able to change later, while a bundled module is something we can break and change at any moment. So I'm thinking we should start with a bundled module, add as much icons as we want and we start evaluating. how's that sound?

[sgomes]

@sgomes, thanks for sharing this very interesting idea. I have two questions:

• How complex it would be to create and expose those SVG maps in the Gutenberg plugin and later in WordPress core. How other web projects would use it? I anticipate that it might be a bit of work to set it all up properly unless there is some tooling which I don't know about.

Using an SVG spritemap is a simple as referencing it externally. You create an SVG in your site (in vanilla HTML, React, or whatever you're using) that includes a <use> directive pointing to that external resource, and an icon inside of it (<use xlinkHref="/public/the-sprite-map.svg#theIconIwant" />). Think of it as an import.

The resulting SVG can be styled normally, as long as you're styling the whole thing, and not styling specific elements inside the icon (in that case, you can't do it with an external resource). That said, I don't think that use-case comes up very often in an icon library, as it's sort of a violation of abstraction, and would require you to know the internals of icons.

• How about native mobile apps that probably can't use those SVG sprites but rather they have to load each icon one by one, see https://github.com/react-native-community/react-native-svg.

What most icon projects tend to do is to ship both the individual SVGs and a generated spritemap, and sometimes other formats too, like pre-rendered PNGs. Consumers can then make use of what works best for them. The icon project can set up a build process that does this automatically as part of deploying a new version, for example. Gridicons is a good example.

[sgomes]

I just edited in my comment, but should have probably commented instead. Looking at https://github.com/google/material-design-icons there are more than 4200 SVG icons. While downloading a zip file of that repository is in no way an accurate representation of cacheability and resulting filesize, but for what it's worth the zip file is 64mb.

The material icons documentation states:

If multiple icons are in use on a web site, creating spritesheets out of the images is recommended. For more information, refer to the documentation in the sprites directory of the git repository.

This is for the use-case where a known subset of icons is being used, and can be optimised by the consumer.

In cases where the subset of icons to be used is unknown, and the consumer may want all of them, they have prepared per-category spritemaps in https://github.com/google/material-design-icons/tree/master/sprites/svg-sprite

Those files come to a total of around 160KB when gzipped. This would be a perfectly reasonable size for an external image resource. And of course, the same approach of doing it per-category could be maintained for greater granularity and an overall smaller download.

[senadir]

@sgomes I like the initiative but I think we need to shift the way we’re looking at this, while you’re trying to handle this as a project using icons, that is, all the icons you’re bundling will be used, we should shift it to a library (think FontAwesome, Material Icons...) kind of problem, 160kb of gizipped icons is still a lot, Icons use cases are not limited to inside the editor, some projects share icons between the frontend and the editor, a great motivator for this package is to enable people to insert icons and use them on the frontend.

4000 might compress, but what if we want to offer 8000, or 16000 icon.

Granted, your solution can somehow be placed on top of this package, as in, a plugin developer can select all the icons he needs from this package and implement a sprint to be used in his plugin, but I don’t see a way for this package to be presented that way.

[sgomes]

I think we should think of this in WP scale. Basically on each WordPress release, I expect the JS to change, but I also expect at least one icon to be added or changed.

That said, I agree that it's better addressed with actual numbers but I don't want to start with a sprite because it's a public API we won't be able to change later, while a bundled module is something we can break and change at any moment. So I'm thinking we should start with a bundled module, add as much icons as we want and we start evaluating. how's that sound?

Ah, sorry, I didn't realise this was in its early stages. I assumed you were looking at tree-shaking as a way of moving closer to being production-ready, not as part of a more experimental stage.

Yes, please consider my advice only in the context of making a production-ready project 🙂

[sgomes]

@sgomes I like the initiative but I think we need to shift the way we’re looking at this, while you’re trying to handle this as a project using icons, that is, all the icons you’re bundling will be used, we should shift it to a library (think FontAwesome, Material Icons...) kind of problem, 160kb of gizipped icons is still a lot, Icons use cases are not limited to inside the editor, some projects share icons between the frontend and the editor, a great motivator for this package is to enable people to insert icons and use them on the frontend.

4000 might compress, but what if we want to offer 8000, or 16000 icon.

Granted, your solution can somehow be placed on top of this package, as in, a plugin developer can select all the icons he needs from this package and implement a sprint to be used in his plugin, but I don’t see a way for this package to be presented that way.

Once again, I may be misunderstanding the wider context and constraints you're working with, so yes, please do take any suggestions of mine with a grain of salt 🙂

As I see it, a library of icons is possible and compatible with multiple approaches. As is a generic React component that makes use of it.

A library can be split up in categories if it gets too large. This is the approach that material icons takes. It can be packaged as individual icons, pre-rendered images, svg spritemaps, or a combination of all of them. Which is also what material icons does. These resources can be distributed as npm packages, ZIP files, or hosted on a CDN depending on developer needs.

As for a generic icon component, it could have two props: one for the stylesheet location, and one for the icon name inside said stylesheet. This would make it easily extensible, with a developer being able to point to icons from library A, library B, or their own set.

These are just ideas, and I'm not sure how well they fit into the constraints of WordPress as a project, Gutenberg, and the community developing third party blocks. And I may be picking this PR as the wrong place to comment on this, and I apologise if that's the case. But in general, I don't see any fundamental issue with an SVG spritemap approach vs an SVG-in-JS one.

[gziolo]

Let's give it a try and iterate later.

[gziolo]

@sgomes - I like your proposal as the long term goal. First, we need to resolve existing issues with the current configuration and what Riad is working on addresses them. The issue is a lot of duplication of inlined SVG icons in code. The approach taken is moving code in one place which only makes it easier to work on further refinements. The idea of using an internal WordPress package leaves us space for further refactorings because it doesn't expose public API. Let's keep the discussion going as we want to have the best possible setup once it gets promoted into wp.icons global and thus enforced to keep backward compatibility for an indefinite future.