Skip to content
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

Components: Improve Toolbar #18619

Open
diegohaz opened this issue Nov 20, 2019 · 1 comment
Open

Components: Improve Toolbar #18619

diegohaz opened this issue Nov 20, 2019 · 1 comment

Comments

@diegohaz
Copy link
Member

@diegohaz diegohaz commented Nov 20, 2019

I'm creating this issue to place together the steps necessary to improve both the API and the accessibility of the Toolbar component in @wordpress/components. This work started on #17875, but, since the PR has become too complex, we've chosen to break it into more parts:

  • Introduce an __experimental accessible Toolbar component in @wordpress/components (#18534)

  • Improve ToolbarButton so that it serves more use cases than just being an IconButton. (#18931)

    At this point, the Gutenberg header toolbar (without the fixed block toolbar) could use it.

  • Refactor SlotFill so we won't need to force fills to re-render when fillProps change.

    At this point, block toolbars could start using it.

  • Convert the fixed toolbar buttons (block switcher, more tools etc.) to ToolbarButton.

    At this point, custom blocks could start using it, as long as they use ToolbarButton inside BlockControls or BlockFormatControls.

  • Convert core block toolbars.

    We could convert one per PR (for example, start with the Paragraph toolbar). This would fix #15331 and #3383.

  • If it proves to be useful and works out, deprecate the old usage and remove the __experimental prefix. Otherwise, revert it altogether, which would break the code for people using __experimentalAccessibilityLabel explicitly, but custom blocks would seamlessly rollback to the old usage.

@gziolo

This comment has been minimized.

Copy link
Member

@gziolo gziolo commented Nov 20, 2019

Re-sharing my comment #18534 (comment):

How about we also move packages/components/src/toolbar-context/index.js to be located inside packages/components/src/toolbar/context.js? Well, it might wait until we decide whether we need to expose it. My only concern is that it gives the impression that this is something that could use standalone since it is in the root folder.

There is also README.md missing for the newly introduced ToolbarGroup component. Given that JSDoc comments contain all required defaults, it should be quite straightforward to create a documentation file. A separate story is that it would be nice to be able to auto-generate such files based on JSDoc and Storybook stories :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.