-
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
Introduce Icons package #17055
Introduce Icons package #17055
Conversation
Thank you! Thank you very much for taking a stab at this. There has been such a desire for an easier way to use icons, both for users in the block editor, but for developers too. Additionally there have been discussions on ways to expand and refresh the Dashicons set, perhaps add additional sets.
I love the sound of that. It's definitely clear we need access to a ton of icons, but we also need to reduce the bottleneck it is to add new icons. Social logos for "sharing" blocks is another candidate that might benefit from this component. So in that vein: this PR feels necessary and appropriate. Some questions, though: 1. Will this component be able to work with multiple icon sets? For example it needs to work with Dashicons for the moment, but you could imagine it expanding to potentially include icons from other sets such as Material Icons, or FontAwesome, or yet another set, just as examples. 2. In relation to 1, how will a developer include an icon from a specific set? Based on your examples, I imagine it's this way:
Provided I understood the above right, it would output the Would it be possible to work towards the following syntax instead?
I'll defer to you, Riad, and others for the technical feasibility of the precise syntax. But the point I want to make is that if we can add some sort of system that better scales to multiple icon sets, that seems important. 3. Different icon sets have different dimensions. Icons from Dashicons are 20x20px, icons from the Material set are 24x24px. I assume that this component doesn't touch any of those dimensions, and simply outputs the SVG with the dimensions it's born with. This would be fine. What we want to avoid is outputting the same fixed dimensions on all icons, regardless of set. I know those are all big, complicated questions. We don't need to address all of those questions in this PR — but the questions are very important to think about before we move forward, because we have to address them in the future. So we have to build this component keeping those challenges in mind, so we don't paint ourselves into a corner. |
Some quick thoughts:
I do wonder whether we should treat this package as a special case in our packages. I don't think it makes sense to load this package entirely in its own WordPress script/style because it will be too big. The other approach is to bundle its usage in its consumers (editor, block-editor, block-library....) with tree-shaking enabled. That means each consumer will include the icons it uses in its own script, it also means that if an icon is used in two scripts, it's duplicated. We should measure but I think even with this potential duplication, we'll still end up with way smaller JS loaded in general. Now, there's a third use-case, it can be thought of as a follow-up but it's good to keep in mind too. How do we allow third-party usage of these icons if this package is not available as a WordPress script. We could encourage third-party plugins to use the npm package and bundling the same way Core does, which IMO is good enough even if it forces these plugins to have a "build tool". Finally, there's another approach we could think of. Have each icon be its own file/script in WordPress. This also solves the scalability issue but it is a lot of burden to setup and it also increases the size of WordPress itself especially if we include a lot of icon sets. For that particular reason, I'd still go with the approach outlined above personally. |
My Idea (which is not implemented in this PR yet) is to have it this way:
I do feel like the components names are a bit all over the place, with dashicon having 288 icon and material over a 1000+ we're bound to create a confusion, so maybe a prefix can help
however, the best solution is to use a single component like you said, but I have concerns regarding tree shaking for a single component that reference other components, a technical question for anyone who have any knowledge in tree shaking:
like @youknowriad said, duplicating components is still the best choice, currently we have 288 icons, in the future they could be 3000, I've seen sets with 4500 icon (material UI), and only less then 1% of them will be used on core, so including them would make sense |
The tree-shaking issue you mention is definitely the challenge to solve — I definitely understand this from a technical perspective. But it's also crucially important to solve this in a considerate way. I would definitely defer to technical observations for how to do this. But it would be good to think about creative solutions to this. Because if we go with a "component per icon" approach, we'll be stuck with it forever, and we'll have most literally thousands of components. What if we choose to deprecate a set? If we had I trust that the single
Any idea we might think of, that lets us avoid having a named component per icon would be great. Many of the icons created for Dashicons were created half a decade ago and were not named in a consistent or friendly manner. It feels like clutter to suddenly have a component called |
some questions for me to understand your approach correctly: 1- how is I'm still looking into other possible solutions, but I based this one on material UI solution, having each component as a file, Shopify Polaris also does the same Polaris use case is closely related to ours, since Polaris is used for both building shopify admin interface, and for third party developers to extend the UI with plugins, so might be able to see why was this a good choice. I would still investigate more to find the most appropriate way to do this. |
To be clear I think the full evaluation of which way to go should come from someone like Riad, as there are layers of technical aspects I may not fully grok. But to me the difference is in implementation. When building a component that references |
I haven't fully looked into this, but I also think we should have a single icon component. About module size, I see two solutions off the top of my head:
Now that I think about it, we should do both. Allow explicit preloading, but also load it for them dynamically if they don't preload it. |
The approach used by font awesome is the same one as Polaris, essentially a HOC named So this is how Polaris & FontAwesome does it, adapted to our situation: import { Icon } from '@wordpress/components';
// Our current workflow doesn't allow such imports but we can get around that later.
import { Post, Save } from '@wordpress/icons/dashicon';
import { Phone } from '@wordpress/icons/material';
// ...
<Icon src={ Post } />
<Icon src={ Save } />
<Icon src={ Phone } size={ 24 } /> This is still a bit of a hassle to include each component manually, another approach that uses dynamic imports could be like this: // index.js
import { Icon } from '@wordpress/components';
// ...
<Icon src="post" />
<Icon src="save" set="dashicon" />
<Icon src="phone" set="material" size={ 24 } /> // components/icon/index.js
import { Lazy } from '@wordpress/element';
import { SVG, Path } from '@wordpress/primitives';
// ...
// dashicon is used as a default for example only
export default function Icon( { src, set = "dashicon", ...props } ) {
const iconLocation = `@wordpress/icons/${set}/${src}`;
const path = Lazy( () => import( /* webpackMode: "eager" */ iconLocation ) );
return (
<SVG { ...props }><Path d={ path } /></SVG>
);
} However, there are many cons to this method:
Dynamically importing chunks is useful if we're talking a vendor library, a set of components, on anything that makes the extra HTTP request worth it. further reading: |
No, although that is supported, it is not their recommended usage for when you have lots of icons: https://github.com/FortAwesome/react-fontawesome#usage
It's OK, because we won't change icons frequently and the result is cached.
You would preload the icons like in FontAwesome to avoid that.
Why? Dynamic imports are super stable. |
Dynamic imports might not be that easy in the WordPress context. How do you configure the URL properly? How do configure your bundler to generate scripts that work across WordPress installations (we don't know the path or the relative path before hand...) I'd love for us to start using dynamic imports, not only for icons, but also for lazy loading things (say the syntax highlighter...). At the time of writing, we don't have a solution for it though. |
because when you're building your own app, you know exactly how many icons you're going to use, we're however, not looking at this from a developer perspective but from fontAwesome perspective, and with the recommended method, building a library, you still have to selectively load each component, so we need to selectively export each one. the explicit & library methods are just developer experience enhancements but under the cover they're the same.
fontAwesome doesn't preload the icons (in the sense of browser resource preloading) it just suggest that you use a library for easier development experience, but performance wise, it's both static importing. dynamic importing will be problematic because of the number of files generated, when you generate 300 file, even you preload, you will still have to do 600 trip (a trip to the chunk file & a trip to the actual file), if we go with eager, then it's 300 extra chunk in our main bundle, making all this dynamic importing useless. code splitting & dynamic importing makes a lot of sense when the chunk file size is big and the number is low, when you have 300 file that are 500byte in size, you end up wasting a lot of resources just to fetch them. I still stand with statically importing them, we can search more into using dynamic import for Gutenberg core packages thou |
fontAwesome doesn't preload the icons (in the sense of browser resource
preloading) it just suggest that you use a library for easier development
experience, but performance wise, it's both static importing.
Yes, I was referring to that. It still lets the consumers have a single
Icon component with a string prop, instead of having to import multiple
icons everywhere.
…On Fri, Aug 16, 2019 at 4:04 PM Seghir Nadir ***@***.***> wrote:
No, although that is supported, it is not their recommended usage for when
you have lots of icons
because when you're building your own app, you know exactly how many icons
you're going to use, we're however, not looking at this from a developer
perspective but from fontAwesome perspective, and with the recommended
method, building a library, you still have to selectively load each
component, so we need to selectively export each one.
the explicit & library methods are just developer experience enhancements
but under the cover they're the same.
You would preload the icons like in FontAwesome to avoid that
fontAwesome doesn't preload the icons (in the sense of browser resource
preloading) it just suggest that you use a library for easier development
experience, but performance wise, it's both static importing.
dynamic importing will be problematic because of the number of files
generated, when you generate 300 file, even you preload, you will still
have to do 600 trip (a trip to the chunk file & a trip to the actual file),
if we go with eager, then it's 300 extra chunk in our main bundle, making
all this dynamic importing useless.
code splitting & dynamic importing makes a lot of sense when the chunk
file size is big and the number is low, when you have 300 file that are
500byte in size, you end up wasting a lot of resources just to fetch them.
I still stand with statically importing them, we can search more into
using dynamic import for Gutenberg core packages thou
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17055?email_source=notifications&email_token=AESFA2FPKWNE24WQACL6RITQE4XANA5CNFSM4IL7MID2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4P4Q7Q#issuecomment-522176638>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AESFA2CQOCVYJST7QLSJ3VTQE4XANANCNFSM4IL7MIDQ>
.
|
but someone will still have to statically import them, and we can't import everything for them, and we can't import based on that string since it's dynamic importing and we're back at the main issue. unless developers build their own library, if this is what you're referring to then yes, it sounds like a good solution |
Yes, it’s still better than explicitly importing them everywhere.
…On Fri, Aug 16, 2019 at 4:15 PM Seghir Nadir ***@***.***> wrote:
but someone will still have to statically import them, and we can't import
everything for them, and we can't import based on that string since it's
dynamic reloading and we're back at the main issue.
unless developers build their own library, if this is what you're
referring to then yes, it sounds like a good solution
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17055?email_source=notifications&email_token=AESFA2GBLXA4SRIZE6WCBZTQE4YK5A5CNFSM4IL7MID2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4P5ABY#issuecomment-522178567>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AESFA2DVVOFTAT6P5TXVNMTQE4YK5ANCNFSM4IL7MIDQ>
.
|
one problem that just came to my mind, the goal of this PR was a preparation for the icon block, the problem is, somehow we need to load all the available icons in a set at once (for the user to select from). All the cases we looked at was from a developer point of view, were you know beforehand what icon you need to use and statically select it, but for an icon block and for normal users, they need a way to see and select icons, which renders this PR useless for that block case if we go with statically typing each one. I guess we will have to define a way to export a whole set at once as well individually exporting them and then dynamically import it for the user when he wants to select import( `@wordpress/icons/${set}` ); How does that solution sound? I know it's out of the scope but I think it falls in here |
Again deferring to the technical considerations, I would just state that what @epiqueras states here definitely seems to address all concerns I've noted on this ticket.
In that vein, would it make sense to wait until we do? While it would be very nice to have a better icon component, what we have today technically functions. If we go the path previously suggested with named components one for each icon, we potentially build up a slew of technical debt while awaiting a better solution. If the goal of this refactor is to enable an icon block, that does not seem like it should make this refactor be that much more urgent, and perhaps an approach such as that of coblocks might make more sense there. |
@jasmussen as we stated, dynamic importing as a concept doesn't fit with icons, since it create a single file for each icon, an additional request to each one, coblocks uses the same concept se use right now by directly including the icons as an object, it works since there is only 69 icon on coblocks, it's the same concept I used for the icon block (see this unpublished PR). For us, we're going to use an // some initial file
import { Library } from '@wordpress/icons';
// Our current workflow doesn't allow such imports but we can get around that later.
import { Post } from '@wordpress/icons/dashicon';
import { Phone, Save } from '@wordpress/icons/material';
// ...
Library.add( {
default: [ Post, Save ],
material: [ Phone ]
} ); // the place you're going to use the icons in
import { Icon } from '@wordpress/components';
// ...
<Icon name="post" />
<Icon name="phone" set="material" /> The current problem we're trying to tackle right now is not there yet. after much consideration, this PR will not help much in the icon block now, but should pave the way to include other icons, for developers and core contributors and an easier way to extend the icon block. By no mean I think this PR is urgent, there is a lot of talk that needs to happen, 2 work days already and we tackled a lot of technical & implementation details aIrealy. so @jasmussen from a developer point of view, how do you think about this approach and what kind of technical debt it may introduce? |
I think I should expand on this more Each icons is a component:
Dynamic importing icons:
|
I don't know that I'm the right person to suggest how much technical debt this solution might introduce. I may in fact be wrong entirely. So instead of talking too much about the specific implementation, I would rather suggest that the more we can abstract away from the developer, the better. The idea being that icons as used in WordPress as a whole are likely to change drastically over the coming years. If we abstract away as much as possible, it seems more feasible to refactor the underlying code without the developer having to do a thing. For example, and as referenced in the discussion here: #9647 (comment) — we might be looking at replacing Dashicons with a different set entirely in the future, for example Material icons. Whatever we can do to ease that transition if/when the time comes, the better. In that vein, I like the sound of this:
But again, I should not be the arbiter here, I would defer to @youknowriad or @mtias for final thoughts. |
Ignoring all of the React stuff, wouldn't an SVG sprite solve this issue? |
an SVG sprite will still need to be built for select icons, and you can't have a SVG sprite for all the icons (it will be in tens of mbs) |
Of course, but you could always pack icons in sprites of, let's say, a 100 icons. That would reduce the number of requests, downloads… and would even let you lazy load them since users wouls only see the firsts few icons until they've scrolled further or searched for an icon. Only mentioning it because there's some plugins on the ecosystem that already use svg sprites to allow devs to add icons to their plugins and it works fine although it's a different paradigm than Gutenberg's and React. |
if you're talking about the search & select process then yes, sprites makes a lot of sense, the idea I had is to paginate them somehow, showing like 30 each time or something similar, or going an advanced road & stream the file |
What about grouping dynamic imports for icons in the client, having the server build a single sprite-sheet for them, and shipping that 🤣 |
Similar to: #9648 |
Those latest changes are working fine for me, now that this has minimal effects, we can progressively update icons in Gutenberg while deprecating older ones. |
I'm wondering whether we should move all current Gutenberg icons there in this PR or in follow-up ones. I'm leaning towards just the latter. |
leaving it for other PRs will allow it to be done by multiple people without the fear of breaking this |
Thank you all for working on this. I'm super excited for a modern icon component to land, and what that will enable with regards to a vast library of icons available for developers, some of which we can polish and make just right for WordPress. For this PR specifically, the only apparent visual change is the Save icon: As for the individual icons, from what I can tell the story is now this:
That references
So once this PR lands, the only blocker to expanding that set beyond a "saved" icon, it seems, is to get to work and create a build system that outputs JS files from SVGs, of which we already have a good start. Nice work! Two quick action items before this PR lands, though:
|
You mentioned that we want to rename some icons. For example . "saved" here should be "check", correct? For this reason and for the fact that it's not just about Dashicons, I think we should avoid an automated script to generate these icons. |
This should be already taken care of for icon buttons, the fact that it's not applied in the "save indicator" is because it's not a button, it requires a specific fix I think. Global styles for svgs are not great. |
I do think we should have a new heuristic for naming icons. In the case of the check, it should be called "check", neither "saved" nor "yes". I do know it's called "yes" in Dashicons, but that's an ambiguous name, and unclear for developers seeking a checkmark icon for other aspects of their plugin. While I don't have any strong opinions about how we add icons, one goal is to add a BIG baseline set of icons so developers don't have to search far to find an icon that fits. For example we could import the entirety of the material set, which is up to 1000+ icons. We also want to honor the tradition of Dashicons by adding a WordPress visual flavor to the most visible icons in the interface, so while we might start with a big baseline set, we'd want to replace as many of them with our own style as we need to. Some of that icon work as been explored also in #18667. Each SVG file needs a little cleanup and minification, and to ensure that the SVG syntax is React Native compatible. Are there other methods of automating this, than a build script? I'm thinking something like when a new icon is created, its design and name needs some approval first, then it goes into a source folder, the script is run, and a new file is generated which can be added. |
noting that with the current package, we still rely on WordPress scripts which means all icons are loaded no matter if they're used or not. The package allows tree-shaking though so if the package is installed as an npm dependency, we can choose which icon to include in the bundle. So I believe ultimately this package will have two sets:
There's no technical way around that IMO. |
If all this is manual, the remaining part creating the file is very quick and only applies to a single icon (not in batch) which means for me, there's no need for automation. But again with flows, it's something we learn over time, so if we do find burden, it is possible to write code generators. |
So if we created that extra set of a thousand icons, that's a pretty big single component that would have to be downloaded for any plugin that needed to use even just one icon, correct? A lot of the benefit of doing an icon component like this in the first place is lost in that case. |
If you consume them through WordPress script yes, if you consume them through npm no. |
Thanks for your patience answering my questions!
So, say I have this plugin, and instead of providing my own icons for 1, 2, 3 or 4 columns, I wanted to provide icons provided by the expanded set, would I be using the WordPress script or NPM, or could I use either depending on my skill as a developer? |
You can use both but I think to avoid the bundle size problem, we'll limit the number of icons available in the WordPress script. So if it's an icon only available in the "extra set", you'll be forced to use npm and build your script. |
That makes sense, and using NPM is also the preferred way to build blocks/use icons, so that seems okay. I still think we'll want some automation if nothing else then one-off scripts for the initial creation of the two sets. But this remains a separate discussion. |
Ok, so let's move forward with this package and try to expand it in follow-up PRs. It's still marked as experimental, so we can still change the API, the bundling... |
@@ -0,0 +1,3 @@ | |||
## 1.0.0 (2019-08-15) |
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.
It should be ## Master
:)
|
||
const saved = ( | ||
<SVG | ||
aria-hidden |
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.
Aren't 3 first props covered by SVG
component wrapper?
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.
Confirmed:
gutenberg/packages/primitives/src/svg/index.js
Lines 21 to 23 in 46fcca7
role: 'img', | |
'aria-hidden': 'true', | |
focusable: 'false', |
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.
Thanks, I fixed your comments in #19809
* Use Select: Fix render queue. (#19286) * Use Select: Fix render queue issues. * Use Select: Make `isMounted` more informative. * Framework: Reset lockfile changes to dependencies Co-authored-by: Andrew Duthie <[email protected]> * Project Management: Run pull request automation on closed (#19742) * Try/group block custom text color (#19181) * Add text color selector to group block to allow setting a text colour that applies to all children of the group to avoid having to set text colour on every individual child * Block Editor: Handle LinkControl submission via form handler (#19651) * Block Editor: Handle LinkControl submission via form handler * E2E Tests: Unskip intermittent buttons test failure * Added conditions and new translation strings for BlockMover (#19757) * Added conditions and new translation strings for BlockMover * Moved translator comments into sprintf function * Storybook: Add Placeholder component story (#19734) * Add Placeholder story for storybook * Update storybook test snapshot * Project Management: Fix pull request merge automation errors (#19768) * Framework: Use fixed version of checkout action Avoid unintended breaking changes. To a lesser extent, helps clarify that this tag refers to the _version of the action_, not the branch being checked out. * Framework: Configure PR automation checkout to master branch * Add post requests documentation for apiFetch (#19759) * Multi-select: don't focus first selected block (#19762) * Multi-select: don't focus first selected block * Move CopyHandler outside WritingFlow * Fix click appender * Remove useless line * Update: Readme.txt Link to changelog instead of adding it inline(#19761) * Fix: Media & Text: "Crop image to fill entire column" reset on image change (#19765) * Build: Include JSON files in zip archive (#19772) * Build: Include JSON files * Zip build script: Include json files in `build/block-library/blocks/` Co-Authored-By: Jorge Bernal <[email protected]> Co-authored-by: Jorge Bernal <[email protected]> * Makes appenders visible only for the current selection (#19598) * makes appenders visible only for the current selection * adds smaller footprint to appenders in navigation, only shows them if item has descendants * align appender to level of the menu item, remove useless CSS * Core-data: do not publish outdated state to subscribers during updates (#19752) * Core-data: do not publish outdated state to subscribers during updates Calling `saveEntityRecord` with an update does the following: 1. Calls `getEntityRecord` to fetch the current persisted state of the entity record 2. Calls `receiveEntityRecords` with the new up-to-date state to render the updates 3. Sends an API fetch with the update patch to persist the update 4. Calls `receiveEntityRecords` again with the new up-to-date *persisted* state The issue here, is that point 1 (Calling `getEntityRecord`) not only fetches the persisted state, but it also internally calls `receiveEntityRecords` itself . This results in the persisted outdated server state to be rendered on the UI, causing a flickering effect, that jumps pack when point 2 takes turn. This commit removes the call to getEntityRecord, and instead, it just calls receiveEntityRecords with the local up-to-date state of the entity record. This fixes the flickering issue. * Core-data: update tests to match saveEntityRecord yeilded actions Given `saveEntityRecord` no longer selects `getEntityRecord`, which itself triggers a SELECT action, two SELECTs are no longer yielded. This commit removes the expectation of these two SELECTs. * Core-data: Introduce getEntityRecordNoResolver selector To allow saveEntityRecord access the latest local full version of an entity without issung an API request. This prevents propogating outdating states to subscribers when saveEntityRecord is called. See: #19752 (comment) * Address review comments at #19752: 1. Capitalize alll added comment messages 2. Alias getEntityRecord with getEntityRecordNoResolver instead of copying it 3. Use describe.each instaed of looping manually in selectors tests * Add WordPress primitives package (#19781) * navigation-link: set page id in the attrs (#18641) * Project management: Add step that updates CHANGELOG files before npm releases (#19764) * Navigation Block: Add submenu chevron w/ setting (#19601) * Initialize setting in the nav block settings panel * Add submenu icon * Register "showSubmenuIcon" attributes * Add submenu icon to front-end of the page * Update submenu icon setting description * Don't use <span> for RichText element * Isolate NavigationLink icons * Clean up a little * Use <span> for NavigationLink contents * Rename `$level_zero` to `$is_level_zero` * Add missing spaces * Update submenu icon selector in style.scss * Add comment about span-wrapping * Fix phpcs errors * Remove unused styles * Fix failing e2e tests * Update failing snapshots * Embed: Fix failure placeholder alignment/sizing (#19673) * Fix error message sizing + alignment in Embed Placeholder * Fix Table placeholder input vs button alignment * Adjust spacing between error message and buttons * Fix card component sub-component example code (#19802) * Introduce the Icons package (#17055) * Expose @wordpress/icons to react-native (#19810) * Block popover: allow scrolling over (#19769) * Block popover: allow scrolling over * Clean up * Fix overlapping inserter popover * Better comment * Multi select: keep selection after move (#19784) * Multi select: keep selection after move * Add e2e test * Change e2e test * Address feedback * Fix snapshots * Bump plugin version to 7.3.0 * Navigation: Select parent navigation block on handleCreateFromExistingPages() action (#19817) * Paragraph block: remove dead CSS (#19821) * Bundle the icons package instead of using it as an external (#19809) * Move a dozen of block icons to the icons package (#19808) * Chore: Improve package-lock.json configuration * Add mkevins and pinarol as code owners for gallery block (#19829) * Added shippedProposals (#19065) * Added shippedProposals * Setting shippedProposals during init * Rich text: remove is-selected class (#19822) * Rich text: prefix is-selected class * Adjust more cases * Remove the class * Move more block SVGs to the icons package (#19834) * Block: use context to provide selected element (#19782) * Block: use context to provide selected element * Include multi selection nodes * Add comment * Popover: clean up requestAnimationFrame (#19771) * Popover: clean up requestAnimationFrame * Cancel the last request before a new request * Update: Removed editor store usage from native mobile block ed… (#18794) * Navigation: Manage navigation link appender visibility based on current selection (#19846) Show the navigation link appender when the selected item has descendants and is selected, or if it's the parent of the selected block. * Remove editor dependency from the block library (#16160) * Add AnglePicker Component; Add useDragging hook (#19637) This commit adds a component to pick angles and a hook to make dragging things easier to implement. Some components will be refactored to use the new hook e.g: the custom gradient picker. * Testing: Use deterministic selectors for incremented IDs (#19844) * Innerblock Templates Docs Link Typo Issue Fixed (#19813) * Innerblock Templates Docs Link Typo Issue Fixed * Innerblock Templates Docs Link Typo Issue Fixed * Rich text: enable if multi selection is aborted (#19839) * Block Directory: Refactor the reducer by breaking out the block management actions into their own reducer. (#19330) * Block Directory: Refactory the reducer by break out the block management actions into their own reducer. * Moved hasPermission into its own reducer. * Also remove the 'items' list as it's not being used * Update the getInstalledBlockTypes selector to point to the new reducer that manages installs. * Update typo in test. * Remove the lodash dependency in the selectors. It isn\'t necessary. * Fix panel header styles (#19842) * Move more block icons to the icons package (#19838) * Bump @babel/preset-env to 7.8.3 (Optional Chaining!) (#19831) * Bump babel to 7.8.3 * Added test for optional chaining * Bump other babel packages. * Fix * Changelog Update CHANGELOG.md * Update package-lock.json Co-authored-by: Grzegorz (Greg) Ziółkowski <[email protected]> * Style improvements for template previews (#19763) * First scaffold for template previews (mobile only) * WIP: managed to make the preview show, saving as a checkpoint - BlockEditorProvider needs an update so it uses the subRegistry - We need a better way to only render the picker on the main block list - We need to make the bottom sheet full height, and adapt the block preview accordingly * Set a fixed height for the template preview * Move template picker to the toolbar * Read only block list * Lint fixes * Made scrolling sort of working with read only block list * A longer template to test scrolling * Replace BottomSheet with Modal for previews * Allow closing previews with back button on Android * Revert changes to BlockList that were required for bottom sheet integration * Revert changes to BottomSheet * Add usage example for ModalHeaderBar * Improve accessibility of template preview * Improve accessibility of ModalHeaderBar * Remove unused imports * Added missing web file * RNMobile - Page template picker: apply layout from the preview * RNMobile - Layout preview: apply action * RNMobile - Page templates - set layout action * Remove mobile action from docs * New components for modal header buttons * Fix alignment of modal header buttons * Fix metrics for iOS modal header * Add subtitle to preview header * Use named color for modal header button * Updated modal title color and weight * Make Apply button bolder on iOS * Make Apply button bolder on iOS * Fix vertical alignment for close button * Allow modal rotation on iOS * Fix modal background on dark mode * Fixed dark mode for template previews * Revert changes to editor store after bad merge * Add material close icon for modal header * Tweak modal title colors * Lint fixes Co-authored-by: Gerardo Pacheco <[email protected]> * [RNMobile] Release v1.21.0 to master (#19854) * Adding empty function to RichText children call. (#19818) This fixes a crash originated on this PR: #19536 ` * Disable gallery image size options on mobile (#19828) * Revert "Disable gallery image size options on mobile (#19828)" This reverts commit 47b74aa. Co-authored-by: Matthew Kevins <[email protected]> * Packages: New create-block package for block scaffolding (#19773) * Packages: New create-block package for block scaffolding * Promote action handler to async to make implementation simpler * Pass the prop for selection color. (#19635) * Do not use the deprecated package editor for InnerBlocks component (#19869) * Remove dead is-hovered selectors (#19870) * Move is-navigate-mode class to WritingFlow (#19868) * [RNmobile] Upgrade to RN 0.61.5 (#19369) * `focusable` replaced `clickable See facebook/react-native#25274 * Provide a native colors.native.scss * Upgrade React Native version in Gutenberg web repo * Jest doesn't have hasteImplModulePath anymore * Work around other regressions. Will revert when those fixed * Bump react-native version to 0.61.5 * Update babel-jest to try fixing babel-plugin-jest-hoist jest.mock issue * Update jest to try fixing babel-plugin-jest-hoist jest.mock issue * Pin xmldom to older version to bypass license file ambiguity With newer versions, the license check script doesn't recognise that the package is dual licenced and is reporting it as incompatible. This commit pins the package to an older version. There is no functional difference between the two versions, see xmldom/xmldom@v0.1.27...v0.1.30 * Revert "Provide a native colors.native.scss" This reverts commit b05f1e4. This shouldn't be needed anymore after wordpress-mobile/gutenberg-mobile#1683 * Revert "Pin xmldom to older version to bypass license file ambiguity" This reverts commit 7e3c2b5. * Cater for lowercase OR in licenses types Props to @pento for the solution #19369 (comment) * Update package-lock.json via npm v6.13.6 * Check for the same "or" format as we're splitting Otherwise, the 'or' in `GPL-2.0-or-later` causes an infinite recursion. See error in https://travis-ci.com/WordPress/gutenberg/jobs/278348885. * Update package-lock.json after running run check-local-changes * Fix package-lock.json conflicts by keeping Jest to 24.9.0, Babel to 7.8.3 * Update package-lock by running npm install * Update README.md (#19876) Fix typo * Multi selection: fix intermittent e2e failure (#19865) * Move more block icons to the icons library (#19862) * Paragraph block: remove min-height (#19835) * Paragraph block: remove min-height * Use lineheight to set drop cap min height * Framework: Fix server-registered fixtures script (#19884) * Env: Format run output only for terminal display * Framework: Fix server-registered fixtures script * Testing: Regenerate server-registered fixtures * Testing: Regenerate navigation block fixture * Env: Fix CHANGELOG typo "or" * Shortcode Design Review (#19852) * Update style of shortcode based on design review * Fix title colors * Update component to components in CONTRIBUTING.md (#19914) * Apply sentence case formatting to PanelBody titles (#19901) * Color Settings -> Color settings * Block PanelBody titles: Settings -> settings * Clarify when isEligible function is called (#19899) Added a note that isEligible is only used for valid blocks and is not called for invalid blocks. * Block Editor: Refactor ObserveTyping as function component (#19881) * Block Editor: Refactor ObserveTyping as function component * Block Editor: ObserveTyping: Avoid persisting event * Remove unnecessary import from playground (#19893) * Documentation: Organize Contributors Guide (#19853) * Simplify CONTRIBUTING.md to be just guidelines We don't need to include too much here because the real information for contributing is in the handbook. This page is a standard page for Github repos, so trimming it down to just a few links to sections in the handbook. Plus the policies for code of conduct and GPL. * Add design contribution from CONTRIBUTING.md to design page * Cleanup and organize Contributors Guide * Use consistent Contributors Guide title * Move Principles and catch-all docs to Project Overview section * Switch background to more relevant repository management * Apply suggestions from code review Thanks for the fixes 👍 Co-Authored-By: Chris Van Patten <[email protected]> * Fix extra newlines * Standardize on Contributor Guide, matches core handbook * Update manifest Co-authored-by: Chris Van Patten <[email protected]> * [RNMobile] Correct isMobile condition in nested Media&Text (#19778) * Correct isMobile condition in nested Media&Text * Do not export BREAKPOINTS * Blocks: Match blocks in the inserter using keywords from patterns (#19243) * Blocks: Match blocks in the inserter using keywords from patterns * Ensure that matched patterns with the search term are marked * Introduce scopes for block patterns * Make it possible to apply initial attributes and inner blocks directly from the inserter * Update block preview in the inserter to use attributes from the variation * Change the way patterns are handled in the inserter * Update packages/block-editor/src/components/block-types-list/index.js Co-Authored-By: Miguel Fonseca <[email protected]> * Improve the way patterns are added to the inserter * Rename pattern label to patter title to align with block types * Inserter: Don't auto-add block if it has variations Co-authored-by: Miguel Fonseca <[email protected]> * Block editor: Alt+F10 shouldn't scroll to top (#19896) * Add e2e test * Leave fixed position until position can be set * Multi-selection: fix clearing with side click (#19787) * Multi-selection: fix clearing with side click * Add e2e test * [RNMobile] fix show appender and separator in Group block (#19908) * fix appender to duplicate separator line * Add docs for LocalAutosaveMonitor and __experimentalUpdateLocalAutosaveInterval (#19915) * [RNMobile] Add media edit icon to image block (#19723) * Creates a MediaEdit component that shows a picker * Add Gridicon's customize icon * Show a button in images block that displays a picker * Fix lint issues * Fix no-shadow error * Fix the name of the params * When "Edit" is selected, request the Media Editor * Fix lint issues * Change media editor ID to a constant * When "Replace" is tapped, show all available media options * Fix lint issues * Avoid destructuring * Block Library: Handle Popover onClose for LinkControl (#19885) * Block Library: Handle Popover onClose for LinkControl * E2E Tests: Verify link popover Escape handling * Disable Autocomplete in shortcode block (#19848) * Disable Autocomplete in shortcode block * RichText API: Limit `prefix` transformations to Paragraph (#19727) … and any consumer of RichText that provides experimental prop `__unstableAllowPrefixTransformations.` * Block Editor: LinkControl: Resolve error when undefined value, "view" state (#19856) * Block Editor: LinkControl: Resolve error when undefined value, "view" state * Block Editor: LinkControl: Document only url, title, opensInNewTab value properties * Block Editor: LinkControl: Change documented example to reference known value property * [RNMobile] Revert change to fix Action Sheet (#19934) * Revert "Avoid destructuring" This reverts commit e113310. * Fix the var name * Add background color support to Columns block (#17813) * Add attributes * Update edit function * Update save function * Add .has-background style * Improve has-background and backgroundColor.class checks * Try passing the columns block e2e test * Refactor to use __experimentalUseColors * Normalize has-background padding with variables * Remove extra bit * Fix RTL styling for Media Text block (#18764) * Add proper !rtl ignore comments to maintain styling on RTL * Tweak comment * Add direction: ltr (not ignored) to the content container * change order of composing style in svg primitive (#19927) * Add Prettier formatting script (#18048) * Add Prettier NPM dependency to packages/scripts and top-level * Scripts: export the fromProjectRoot function from scripts/utils module * Scripts: Add Prettier formatting script * ESLint config: use default (linebreak before ternary op) config for operator-linebreak rule * ESLint: disable formatting rules in the recommended config Adds `eslint-config-prettier` to the recommended config and creates an alternative `recommended-with-formatting` config for project that want to keep ESLint formatting rules and opt-out of Prettier. * Scripts: the format-js script checks if Prettier is present and has top-level config Prettier presence in a `wp-scripts`-powered project is optional, and the `format-js` script checks if it's there and if it's indeed the fork (`wp-prettier`). Will report error otherwise. Also, require a top-level Prettier config to be present. We can't default to the one inside `wp-scripts`, because IDE and editor integrations won't find it there and will use the Prettier defaults. * Bump the minimum required version of npm to 6.9.0 * Add ESLint config changes notice to changelog * Update package-lock.json * Regenerate package-lock.json Co-authored-by: Grzegorz (Greg) Ziółkowski <[email protected]> * Components: FontSizePicker: Adjust Select Button sizing (#19479) * Documentation: fix typo "Th" to "The" (#19833) * [RNMobile] Long-press on inserter to show options for "add above" and "add below" (#18791) * Add onLongPress prop to Button * Show inserter menu on long press * Make onLongPress a prop of toggle * Make withSelect of Inserter return destinationRootClientId * Insert default block before the selected one on long press * Add add canReplaceBlock key to the insertionPoint state * Hide a block in list only if it can be replaced * Move insertion index logic from menu to inserter * Update selector tests for newly added key in state * Add insertionIndexAfter and isAnyBlockSelected props with selector * Update docs for newly added key in state * Add insertionType to component state and map to insertion index * Refactor insertion index logic * Show BottomSheet on long press to choose to insert before or after * Update UI strings to be title case * Hide cancel button from Bottom Sheet on Android * Add icons to Bottom Sheet options on Android * Add “Replace Current Block” option to menu on long-press * Scroll to newly added block if it doesn't trigger keyboard to open * Change “Replace Current Block” menu icon on Android * Use shorter syntax for setState * Rename getShouldReplaceBlock method to shouldReplaceBlock * Revert "Scroll to newly added block if it doesn't trigger keyboard to open" This reverts commit 9c1c71d25eb573427ca09761bd3154286d19539b. * Revert “Add canReplaceBlock key to the insertionPoint state" * Remove Block show/hide logic from BlockList * Update Inserter local state to store block insertion information * Make InserterMenu add/remove unmodified default block during replace * Handle replacing last remaining block * Fix Inserter test * Fix code style issue * Move insertion options into getInsertionOptions function * Add comment about removing last block case * Use findByProps instead of toJSON when testing Inserter * Docs: Add details for format-js to @wordpress/scripts package (#19946) * Docs: Add details for format-js to @wordpress/scripts package * Update README.md * Update packages/eslint-plugin/CHANGELOG.md Co-Authored-By: Marcus Kazmierczak <[email protected]> Co-authored-by: Marcus Kazmierczak <[email protected]> * Fix: Crash when creating a hierarchical post without title (#19936) * Fix: Color Gradients component was not able to handle only gra… (#19925) * Add markdownlint script to lint docs markup (#19855) * Add markdownlint script to lint docs markup Adds a new script `lint-md-docs` that runs markdownlint to lint markdown files for proper syntax. A default `.markdownlint.json` config is included, it will require some testing to tune. Fixes #12426 * Clarify naming of lint-md scripts js and docs - Updates lint-md scripts to lint-md-js for linting source included in the document and lint-md-docs for linting the markup of the document itself. - Update scripts changelog - Update readme with commands * Apply suggestions from code review Co-Authored-By: Grzegorz (Greg) Ziółkowski <[email protected]> * Fix URL for markdownlint CLI * Add -i check, details around ignore on CLI * Check for additional project config files * Update script commands to all for lint:* * Local changes applied to package-lock.json * Update packages/scripts/README.md Co-Authored-By: Grzegorz (Greg) Ziółkowski <[email protected]> * Apply suggestions from code review Thanks for the review and updates 👍 Co-Authored-By: Grzegorz (Greg) Ziółkowski <[email protected]> Co-authored-by: Grzegorz (Greg) Ziółkowski <[email protected]> * Use require.resolve() instead of <rootDir> in @wordpress/jest-preset-default (#19957) * use require.resolve() instead of <rootDir> * formatted * added changelog entry (#19958) * Move the insert dashicon to the icons package (#19943) * Replace all occurences of the yes dashicon with the check icon from the icons package (#19926) * Build: Include block.json files in the build output (#19786) * Block Editor: LinkControl: Prevent focus loss in edit mode toggle (#19931) * Block Editor: LinkControl: Prevent focus loss in edit mode toggle * Block Library: Remove custom focus loss protection Previously used effect lifecycle to anticipate and respond to focus loss. Now, focus loss is prevented by LinkControl. See: 722a4d6dec * Block Editor: Rephrase and move forced input rendering comment * Block Editor: Ensure isEndingEditWithFocus always assigned as boolean * Move Alignment, movers and trash icons to the icons package (#19944) * Navigation Block: Move the link description panel below the SEO panel because this is likely to be used signficantly less than the SEO panel. (#19917) * Update hover and focus selectors for Move to Trash to ensure they're always red (#19974) - Updates the selectors in .editor-post-trash to use similar specificity as .components-button.is-link for the hover and focus states to ensure that they are always red. * Create block: Code quality improvements for the block scaffolding (#19867) * Create block: Code quality improvements for the block scaffolding * Improve the strucutre and handling of templates Props to @aduth for the proposal: #19773 (comment). * Ensure that package-lock.json file is refreshed with the changes from master * Docs: Add a note about version and help options * Code style: Run Prettier formatting on the package files * Create block: Align .editorconfig with Gutenberg settings * Fix: Use the description provided to fill the `description` field in `package.json` file in ESNext template * Fix: Ensure that values provided for slug and namespace get converted to lower case * Fix: Simplify the logic for transforming slug to title * Update packages/create-block/lib/templates.js Co-Authored-By: Andrew Duthie <[email protected]> Co-authored-by: Andrew Duthie <[email protected]> * Code quality: Enable linting for JS files starting with . * Popover: fix typo in removing event listener (#19978) * Eslint Plugin: Lint code formatting. (#19963) * Eslint Plugin: Lint code formatting. * Gutenberg: Add code formatting pre-commit hook. * Eslint Plugin: Update docs. * Gutenberg: Format code. * Storybook: Update snapshots. * [RNMobile] Show the media edit icon only if the block is selected (#19961) * Only shows the media edit icon if the block is selected Also, matches the style of the native gallery block buttons * Fix lint * Fix: Admin menu collapses for 960px width but editor doesn't (#19970) * Chore: Fix differences in package-lock.json file * RichText: try using hooks for wrapper component (#19095) * Components: Apply width-based modifier classes to Placeholder only when width is known (#19825) * Components: Apply `is-small` modifier class to Placeholder only when width known * E2E Tests: Wait for placeholder error display in embed tests * Testing: Update snapshots for Placeholder class assignment * Eslint: set line width to 80 (#19992) * Update config * npm run lint-js:fix * Move eslint comments * Update snapshots * Editor: Remove post title escaping (#19955) * Add: Global styles css variables generation mechanism (#19883) * Navigation: Change UX to move focus to navigation link label and close the LinkControl (#19686) * When adding a link via the LinkControl, selects/highlights nav link label text if it's url-like. Focuses if not. Automatically adds url-like labels as the label. * Adds @wordpress/dom to package-lock.json * Removed test for awaiting for Link Control focus after pressing Enter, as the focus should now be on the navigation link text with the Link Control closed * Lib: Limit `pre_render_block` extension. (#19989) * Lib: Limit `pre_render_block` extension. * Update lib/compat.php Co-Authored-By: Andrew Duthie <[email protected]> Co-authored-by: Andrew Duthie <[email protected]> * Fix, update, and sort _rc_ `hasProjectFile` filenames (#19994) * Update and fix `hasProjectFile` filenames * Sort `hasProjectFile` filenames * Update CHANGELOG.md * Docs: Include CHANGELOG entries from the relocated create-wordpress-block package * Blocks: Rename patterns to variations in the Block API (#19966) * Blocks: Rename patterns to variations in the Block API * Fix: Remove ESLint errors and warnings related to block variations * [Mobile] Fix gallery upload sync (#19941) * Invoke mediaUploadSync for gallery in React hook * Use integer type explicitly for gallery image id * Set state before attributes on upload success in gallery image * Use ref hook for concurrency in media placeholder * Extract dedup function and add comments in media placeholder * Fix lint * Use explicit radix with parseInt Co-Authored-By: Gerardo Pacheco <[email protected]> * Import useRef from @wordpress/element * Fix lint * Fix lint / prettier Co-authored-by: Gerardo Pacheco <[email protected]> * [Mobile] Fix blank image size labels on mobile (#19800) (#20045) * Fix blank image size labels on mobile * Use name instead of label in default imageSizes * [RNMobile] Enable Dismiss on PlainText in Android (#20095) * Add flag for determining if running on Android * Enable Dismiss button on PlainText. Enable show keyboard in Android on PlainText mount * Enable Dismiss button on PlainText. Enable show keyboard in Android on PlainText mount Co-authored-by: Enrique Piqueras <[email protected]> Co-authored-by: Andrew Duthie <[email protected]> Co-authored-by: Glen Davies <[email protected]> Co-authored-by: Christopher Reece <[email protected]> Co-authored-by: Marcus Kazmierczak <[email protected]> Co-authored-by: Ella van Durpe <[email protected]> Co-authored-by: Jorge Costa <[email protected]> Co-authored-by: Bernie Reiter <[email protected]> Co-authored-by: Jorge Bernal <[email protected]> Co-authored-by: andrei draganescu <[email protected]> Co-authored-by: Omar Alshaker <[email protected]> Co-authored-by: Riad Benguella <[email protected]> Co-authored-by: Damián Suárez <[email protected]> Co-authored-by: Grzegorz (Greg) Ziółkowski <[email protected]> Co-authored-by: Bart Kalisz <[email protected]> Co-authored-by: Jon Quach <[email protected]> Co-authored-by: Edi Amin <[email protected]> Co-authored-by: Seghir Nadir <[email protected]> Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Matthew Kevins <[email protected]> Co-authored-by: Abdelmajid HAMDANI <[email protected]> Co-authored-by: Delowar Hossain <[email protected]> Co-authored-by: Steven Dufresne <[email protected]> Co-authored-by: Adam Boro <[email protected]> Co-authored-by: Kukhyeon Heo <[email protected]> Co-authored-by: Gerardo Pacheco <[email protected]> Co-authored-by: etoledom <[email protected]> Co-authored-by: Sérgio Estêvão <[email protected]> Co-authored-by: Florian TIAR <[email protected]> Co-authored-by: Chip <[email protected]> Co-authored-by: Haz <[email protected]> Co-authored-by: Rich Tabor <[email protected]> Co-authored-by: Benjamin Intal <[email protected]> Co-authored-by: Rostislav Wolný <[email protected]> Co-authored-by: Chris Van Patten <[email protected]> Co-authored-by: Luke Walczak <[email protected]> Co-authored-by: Miguel Fonseca <[email protected]> Co-authored-by: jbinda <[email protected]> Co-authored-by: Leandro Alonso <[email protected]> Co-authored-by: Jarda Snajdr <[email protected]> Co-authored-by: Martin Posselt <[email protected]> Co-authored-by: Ceyhun Ozugur <[email protected]> Co-authored-by: James Newell <[email protected]> Co-authored-by: Andy Peatling <[email protected]> Co-authored-by: Andrew Serong <[email protected]> Co-authored-by: Stephen Edgar <[email protected]>
Description
closes #9647
This PR is a preparation for #16484
there has been a lot of talk of standardizing the current approach about using some standard icon library & pattern of use.
the main reason I needed this is to build a searchable-filterable icon block, the current approach uses a switch case for each icon, making them impossible to filter or getting them as a list.
while this package only includes the icons in Dashicon, it helps us pave the way to an easier experience adding icons.
the build process will be expanded in the future to easily include icons from svg files directly (the current approach uses an
iconObject
object that contain the svg paths with names, essentially turning the switch case to a traversable object.This should replace all future uses of Dashicon component, and graduilty deprecate it & replacing it with this.
How has this been tested?
npm install
Notes
the builder is a quick draft, I expect it to be expanded more and would love any feedback in it
Checklist: