Created a new package containing all icons

[caxco93]

Description

[IN PROGRESS] [NEEDS FEEDBACK]

Creates a new package called @wordpress/icons containing all new svg icons for reusability and maintainability.
This will help close #9642 and others in the future more easily

Fixes #9647

How has this been tested?

Check if the blocks show the correct icon

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ZebulanStanphill]

Nice! Notably, there are currently some icons missing from the embed block. (The generic ones for brands without a unique icon and the brand-specific ones.)

Should brand icons be included in this package or in a separate package?

[caxco93]

I was thinking on placing those at the bottom as well. Separated with a comment indicating they are used by the embed block.

[chrisvanpatten]

Thanks for the PR @caxco93!

I get the theory and reasoning here, but I'm not sure this is the best solution. This would effectively be forking and maintaining our own copy of Material Design Icons (albeit a small subset), which seems potentially complicated.

If the ultimate goal is that the icons inside block placeholders reflect the block icons, perhaps there's a way that blocks could access their own properties — including the icon — from inside the block? That would allow you to reference something like blockProperties.icon.

[ZebulanStanphill]

@chrisvanpatten I did something like that in #9646.

[caxco93]

This package would let other users reuse these icons, just like they are already used to reusing Dashicons.

Also it would be very easy to, in the future, add a custom SVG icon and have it be reusable everywhere else in Gutenberg.

@chrisvanpatten

I'd like more opinions on this

[ZebulanStanphill]

You could probably do this a bit differently:

import { video as icon } from '@wordpress/icons';

and then later in the file be able to use icon, instead of icon: videoIcon.

[chrisvanpatten]

@caxco93 just as some background, the switch to raw SVGs was deliberate. The approach with Dashicons is considered a fallback at this point. There's some more info about the change in #8916.

To be clear I'm not the final arbiter on whether this is a good or bad approach, just want to provide some context on why raw SVGs were chosen over an icon library approach.

I also think that if this type of approach is preferred (pulling in the SVG component from a library), it may make long term maintenance easier to use an existing Material Design component library (like this one or this one) rather than maintaining our own fork of the icons.

That said it's not up to me, and I'm very interested to hear other feedback :)

[gziolo]

Related discussions:

• https://make.wordpress.org/design/2019/02/12/whats-next-for-dashicons/
• https://wordpress.slack.com/archives/C5UNMSU4R/p1549981547059600 (Core JS weekly chat, link requires registration at https://make.wordpress.org/chat/)

[aduth]

Discussed in this week's #core-js meeting (link requires registration):

https://wordpress.slack.com/archives/C5UNMSU4R/p1549981547059600

[gziolo]

As mentioned by @paaljoachim, @senadir is working on the same task in #17055. It looks like he got to the more advanced stage but there is still a lot of concerns in his proposal. I suggest we focus on the more up to date proposal and close this PR to ensure we have one place to continue the discussion.

[gziolo]

@caxco93, many thanks for your initial work. It looks like @senadir is taking a very similar approach but as you can read in the linked PR this is a quite complex issue to solve.