Storybook: Add and Update Block Editor Components stories #67165
Comments
miminari
added
[Type] Developer Documentation
miminari
added
the
Good First Issue
|
@imanish003 @Sukhendu2002 @Infinite-Null @SainathPoojary @himanshupathak95 @Sukhendu2002 |
|
Hey @miminari , I have submitted PR for the following components:
|
|
Hey @miminari, I have submitted a PR for the following components:
|
|
Hey @miminari, I have submitted PR for the following components:
|
|
Hey @miminari, I have submitted PR for the following components:
|
|
Hey @miminari, I have submitted a PR for the following components:
|
|
I'm curious about the reasoning here :). I'm not saying we shouldn't be doing this but curious to lean what value you folks will be receiving from this ? cc @WordPress/gutenberg-core for awareness. |
|
I see a couple benefits from the maintainer side:
I honestly don't know if there is pure documentation value for the extenders. I'd like to emphasize that we should write the stories in a way that keeps maintenance cost at a minimum. It will quickly become a net-negative if the stories incur a maintenance cost. For example, avoid hardcoded values as much as possible, and try to structure things in a way that will not need fixing when the underlying component code changes. Don't write unnecessary descriptions, as those are another thing that need to be updated manually when things change. Let's start with the simplest possible. |
|
As a plugin developer, I find Storybook extremely useful. When implementing a UI for a custom block or block editor, I can see what components are exposed, what props are supported, and how they work. Without Storybook, it's hard to imagine how something would work unless I actually wrote the code while reading the documentation, or found a place in the Gutenberg repository where the component is actually used. |
|
I have looked at the PR linked to this issue and I think we need some kind of indicator to unify our implementations and approaches for contributors who are already working on this issue or are planning to work on it. Below are my thoughts on best practices, but @WordPress/gutenberg-components, if there are any mistakes, please let me know. Use CSF 3 formatWrite stories as objects, not functions Doexport const Default = {
render: function Template( { onChange, ...args } ) {
const [ value, setValue ] = useState();
return (
<SomeComponent
{ ...args }
onChange={ ( ...changeArgs ) => {
onChange( ...changeArgs );
setValue( ...changeArgs );
} }
value={ value }
/>
);
},
};Don'tconst Template = ( { onChange, ...args } ) => {
const [ value, setValue ] = useState();
return (
<SomeComponent
{ ...args }
onChange={ ( ...changeArgs ) => {
onChange( ...changeArgs );
setValue( ...changeArgs );
} }
value={ value }
/>
);
};
export const Default = Template.bind( {} );Consists of only one componentI think the purpose of Storybook is to test a single UI component itself. Therefore, unless there is a special reason, we should not include anything other than that component. Don’t create too many storiesWhile it's tempting to expose as many variations of a component as possible, the behavior of the component can be changed in the Controls section. Therefore, I think additional stories should only be included if they involve significant visual or behavioral changes. |
|
Additional Tips - To improve code consistency, I would personally be happy to implement the following rules for existing and future PRs: To display the source panel by default, specify const meta = {
// ...
parameters: {
docs: {
canvas: { sourceState: 'shown' },
// ...
},
},
// ...
};Define the component description via the const meta = {
// ...
parameters: {
docs: {
// ...
description: {
component: 'Component description here...',
},
},
},
// ...
};Explicitly define the type of props via the const meta = {
// ...
argTypes: {
// ...
propName: {
// ...
table: {
type: {
summary: 'string',
},
},
},
// ...
},
}; |
What problem does this address?
Most of Block Editor components don't have stories.
Block Editor components's Storybook should also be added and updated like the Components.
related #22891
What is your proposed solution?
We can use this issue to track the addition and updating of the stories for Block Editor.
You can add the link to assign yourself to each component.
As I know, Block Editor Components list has never existed, so at first, we can start to be based on the directory name.
The list was made automatically, and we can ignore the component for native only.
If you cannot edit the list, please comment on which you made the PR for which directory's components.
cc @WordPress/gutenberg-components
Block Editor Components directories List
audio-player (for native only)BlockEditorAutocompletebased onAutocompletefrom@wordpress/components. Pending until theAutocompletecomponent's stories are made.)block-caption (for native only)block-media-update-progress (for native only)block-settings (for native only)caption (for native only)image-link-destinations (for native only)inserter-button (for native only)media-upload-progress (for native only)use-unsupported-block-editor (for native only)video-player (for native only)The text was updated successfully, but these errors were encountered: