-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the Dashicon component to rely on the font that ships with WordPress #20003
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, this makes sense and helps keep the bundle-size down. However for back-compat usage consuming code must ensure any styles list dashicons
as a dependency for the style registration. This likely is already taken care of in most cases in the wp-admin, but outside of wp-admin it won't be the case.
Along with the CHANGELOG.md
mention of the breaking change, this might be worth a dev-note for whatever version of WP this lands in as well?
Also, is there any potential risk of validation errors for usage of <DashIcon/>
that might be saved to post content?
So for people who would want to use these icons outside of WordPress, is the suggested alternative that they use the
Shouldn't we be making |
When are blocks going to be used outsiide fo wp-admin, I mean even if they have frontend styles, I don't expect blocks to use Dashicon component in the frontend or can they? |
I was hoping I can avoid that because it's true that it's possible but probably very rare. that said, we can still do it. |
When we're saying "taken care of in wp-admin", are we talking about assuming the Dashicons font will already have been loaded by relying on it being some dependency of another stylesheet? |
Thanks for bringing us in the loop!
Ok 👍Should we create the branch, or do you plan to tackle it? |
For me it's less about blocks being used more outside the admin and more about the Dashicons component being used outside the admin (as a part of a frontend client side rendering). We could treat this as similar to "package" use but if
Ya, it's a dependency of a number of styles loaded in the wp-admin context so I'm not aware of (without completely verifying explicitly) of any Even with my comments here, I'd still like to see this work done. My comments are just more of awareness of potential impact. So to summarize, should we go ahead with this change, these are the things from my perspective I think we'll want to cover:
|
@ntwb Do you think you can help with this? Update the dashicon font in Core with all the icons including the ones created for Gutenberg? |
It should be "enough" to move all the SVGs from the |
3f23814
to
36568bb
Compare
Size Change: -34.3 kB (2%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
Helps fix WordPress/gutenberg#20003. Back in the day when we moved from a manual process, to a build script for Dashicons, we put Gutenberg icons in a separate folder that was not included in the icon font. The context for that started in a meeting here: https://wordpress.slack.com/archives/C03EESJAW/p1498836928887730 — this meeting outlined the process of creating a trac ticket for every icon created and approved separately. Some of that process is outlined in https://wordpress.slack.com/archives/C03EESJAW/p1498838219357464. In order to stay nimble and allow us to move fast with creating Gutenberg icons, it was suggested (https://wordpress.slack.com/archives/C03EESJAW/p1498838530476355) to put Gutenberg icons in a separte folder that is not included in the icon font, landing only in the React component. But the icons have been there for a bit now, and in effort to fix #20003, these icons now need to graduate. Because of their time in the editor, it feels fair to review them all in a single ticket.
I created WordPress/dashicons#402 to graduate the Gutenberg icons. |
Helps fix WordPress/gutenberg#20003. Back in the day when we moved from a manual process, to a build script for Dashicons, we put Gutenberg icons in a separate folder that was not included in the icon font. The context for that started in a meeting here: https://wordpress.slack.com/archives/C03EESJAW/p1498836928887730 — this meeting outlined the process of creating a trac ticket for every icon created and approved separately. Some of that process is outlined in https://wordpress.slack.com/archives/C03EESJAW/p1498838219357464. In order to stay nimble and allow us to move fast with creating Gutenberg icons, it was suggested (https://wordpress.slack.com/archives/C03EESJAW/p1498838530476355) to put Gutenberg icons in a separte folder that is not included in the icon font, landing only in the React component. But the icons have been there for a bit now, and in effort to fix #20003, these icons now need to graduate. Because of their time in the editor, it feels fair to review them all in a single ticket.
I can see it's still being imported in |
7b7e2bf
to
428b0a3
Compare
Now that the Dashicon font is updated on Core and frozen, I think it's time to revisit this PR. It seems ready for me. |
👋 @youknowriad , I wonder if you could add some testing instructions to help verify what icons are expected to work off the font? @Tug or @ceyhun , can you have a new look on this PR? I haven't looked deeper but, I wonder if the mobile app will also need to embed the font that holds the icons and break if the font is not there? |
Do you have any ideas on mind. What would this test look like?
At this point, I expect that our usage of Dashicons on Gutenberg Core to be pretty small. It's still not entirely replaced with SVGs but if you find things that are still relying on Dashicons we can replace them with SVGs to make it work cross platform. |
I'm not sure if this is the optimal way but what I did was searching for gutenberg/packages/components/src/icon/index.js Lines 21 to 29 in 8053ebc
Than I searched for gutenberg/packages/block-library/src/gallery/gallery-image.native.js Lines 230 to 233 in 7532a48
There were also other places where the |
8053ebc
to
32e3b8e
Compare
@ceyhun I replaced these with svg usage, I also replaced a few other places. Let me know if you find any place I missed where dashicons are still being used. I also noticed that on master, folks are continuing to use Dashicons for new code, so I'd like to move with this forward in order to officially deprecate the component and encourage folks to use the SVGs instead. |
Anyone to approve this :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests well for me, let's get this in.
Thanks for finding and fixing the other places @youknowriad! There still could be other places we missed but it looks good for now. |
@@ -9,6 +9,7 @@ | |||
### Breaking Change | |||
|
|||
- `NumberControl` no longer automatically transforms values when rendering `value` into a `<input />` HTML element. | |||
- `Dashicon` component no longer renders SVGs. If you rely on this component, make sure to load the dashicon font. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this have gone under Unreleased
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, mistake 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, I bumped the major version in last week's release 😄
closes #25230
With the new @wordpress/icons package, the Dashicon component usage should be deprecated but even if it's deprecated, its code will have to remain on the project for Backward compatibility reasons. This is not a problem for any random component but it's a problem for the Dashicon because that component is huge (it includes all the SVGs) and it can't be tree-shaken for third-party usage (I know for example that Woo are struggling with this).
In this PR, I update the implementation of the component to rely on the font and styles that already ship with WordPress. This has some advantages:
This is a breaking change though for the npm package itself because it means that component is basically useless outside of WordPress but breaking changes in npm are ok.
Notes
If you test the PR, you'll notice that some dashicons are not appearing, that's because the component here and the Dashicons version that ships with WordPress are not in sync. To solve this, we need to update WordPress Core Dashicons font to the last version with all the latest icons.
This also can't be merged now, we need to refactor all the mobile usage of the component and rely on the icons package instead. cc @Tug @hypest
Thoughts?