Blocks: icon can be passed as name (Dashicon) or SVG (file, raw)

[folletto]

Referring to how blocks are currently declared:

registerBlockType( 'core/list', {
	title: __( 'A Custom Block' ),
	icon: 'editor-ul',
	category: 'common',
	...

Would be nice to allow a higher reusability to have the icon field to be more flexible. We could do basic detection and allow different sources, thus avoiding to limit the icons to Dashicons and/or bloating Dashicons for one-off uses.

Brainstorming a possible approach:

1. If the first char is a letter, it looks up as name in Dashicons (i.e. icon: 'editor-ui').
2. If it ends with .svg, it looks up a SVG file relative to the JS file (i.e. `icon: 'custom-icon.svg').
3. If it starts with < (ends with >?), it uses the content as pure SVG: (i.e. icon: '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20"><rect x="0" fill="none" width="20" height="20"/><g><path d="M10 2.16c4.33 0 7.84 3.51 7.84 7.84s-3.51 7.84-7.84 7.84S2.16 14.33 2.16 10 5.71 2.16 10 2.16zm2 11.72V6.12L6.18 9.97z"/></g></svg>').

Note: we don't need both 2 and 3, we can chose to do only one of the two. Just, we can do both if we thing both can be useful.

Initially discussed on WordPress/dashicons#203

[aduth]

Noting that the documentation describes additional supported values for icon, though these have not yet been implemented:

icon: string | WPElement | Function - Slug of the Dashicon to be shown in the control's button, or an element (or function returning an element) if you choose to render your own SVG.

https://github.com/WordPress/gutenberg/tree/master/blocks#wpblocksregisterblocktype-name-string-typedefinition-object-

Related to your third suggestion, instead of returning a string, one could return a WPElement (React element).

Detecting file extension could be interesting. One downside is the additional network request could cause a delay in the icon being shown in the UI.

[folletto]

I was sure this discussion happened already in some form ;)

Related to your third suggestion, instead of returning a string, one could return a WPElement (React element).

What would be the use case for this?

Also: why not both?
(I was thinking more in terms of ease and intuitiveness of the solution)

Detecting file extension could be interesting. One downside is the additional network request could cause a delay in the icon being shown in the UI.

True. It's what led me to the solution of inlining it directly.

[aduth]

What would be the use case for this?

Consistency in approaches for providing DOM structure; edit and save both expect an element as a return value. Minor advantages in syntax highlighting (if editor supports), better support for dynamically generating SVG from variables, readability by splitting across multiple lines (possible also with ` string templates). We could even treat icon as a component / function returning an element as pass as props details about the block, so the icon could be truly dynamic. Element provides better protection against XSS if icon would otherwise be provided as string from untrusted / unreliable source.

Also: why not both?

I don't find more API options to be necessarily better, as it can cause confusion in disjointedness of approaches ("which should I use?"). To flip this on its head, what's the use case for an HTML string as icon?

[folletto]

Makes sense. 👍

And I agree on more API options, especially if they cover the same problem.

To flip this on its head, what's the use case for an HTML string as icon?

As I mentioned I was coming from the intuitiveness angle, so yes: it's because seeing the SVG right there seem more intuitive for me.

As you said, it's a balance between too many options and intuitiveness of the ones available. I wanted to start by listing them, so we can choose knowing which ones we are not choosing. :)