Storybook: Add story for TypographyPanel #35293
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: 0 B Total Size: 1.07 MB ℹ️ View Unchanged
|
mirka
changed the title
ntsekouras
reviewed
Oct 4, 2021
ciampo
reviewed
Oct 5, 2021
packages/components/src/tools-panel/stories/typography-panel.js
Outdated
Show resolved
Hide resolved
ciampo
reviewed
Oct 5, 2021
Comment on lines
+4
to
+9
| import { | ||
| __experimentalFontAppearanceControl as FontAppearanceControl, | ||
| __experimentalFontFamilyControl as FontFamilyControl, | ||
| __experimentalLetterSpacingControl as LetterSpacingControl, | ||
| LineHeightControl, | ||
| } from '@wordpress/block-editor'; |
There was a problem hiding this comment.
What is the reasoning behind picking these controls from @wordpress/block-editor, but picking FontSizePicker from @wordpress/components ?
In general, for the purpose of this Storybook example, should we use components from @wordpress/block-editor or from @wordpress/components?
There was a problem hiding this comment.
I just imported the components used in the existing TypographyPanel for the most part.
I don't think it really matters which things we use here (existing block-editor components or wp-component primitives) at least in this PR, as they are only placeholders right now. We'll be evaluating each piece on a case-by-case basis, and replace when necessary. As a starting point, I'm inclined toward having the "real world" block-editor components as a reference so we don't make assumptions based on static mockups only. (e.g. This has already surfaced a concern with the Letter Spacing mockup, which doesn't take units into account.)
There was a problem hiding this comment.
That makes sense to me. I was just curious about why we didn't also pick FontSizePicker from @wordpress/block-editor.
As a starting point, I'm inclined toward having the "real world" block-editor components as a reference so we don't make assumptions based on static mockups only.
Makes sense, let's go with your approach!
|
Adding @aaronrobertshaw here since he's the main developer behind
I believe that's in the works, including researching the best approach to |
Co-authored-by: Marco Ciampini <[email protected]>
Thanks for the ping. The use of the Other than the exploration into adopting the It's also worth raising here that there is currently an open PR switching the existing Typography panel over to the ToolsPanel. I'm not sure at present whether there is the desire to land that with current controls first or wait until we have all the new components done. Either way, I'm happy to collaborate in whatever way is best. Please let me know if I can help 🙂 |
mirka
force-pushed
the
add/typography-panel-story
branch
from
3bb3d9b
to
e56bbba
Compare
No need to wait. From what I understand, we'll be making incremental updates to the underlying components. @mtias has said that it's fine to have some mismatched styling in the interim 🙂 |
|
I added an item on the tracking issue to use @ciampo Are we good to go? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds an exploratory TypographyPanel story under the ToolsPanel section so it can serve as a living guide/playground for the TypographyPanel-related components work. It uses ToolsPanel and other existing components, so it exposes what’s missing design-wise.
In terms of ToolsPanel, the main gap I'm seeing is the grid/column approach. The
.single-columnclass should not be exposed, but whether we're going to provide some kind of grid/column layout methods as a part of ToolsPanelItem, or allow the consumer to use their own wp-componentGrids, we'll have to decide. (I'm inclined to choose the latter, as it's more flexible.)How has this been tested?
npm run storybook:devScreenshots
Types of changes
Storybook-only, non-breaking
Checklist:
*.native.jsfiles for terms that need renaming or removal).