Skip to content

Storybook: Add and Update Block Editor Components stories #67165

@miminari

Description

@miminari

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

Best Practices

1. Use CSF 3 format

Write stories as objects, not functions

Do
export const Default = {
	render: function Template( { onChange, ...args } ) {
		const [ value, setValue ] = useState();
		return (
			<SomeComponent
				{ ...args }
				onChange={ ( ...changeArgs ) => {
					onChange( ...changeArgs );
					setValue( ...changeArgs );
				} }
				value={ value }
			/>
		);
	},
};
Don't
const Template = ( { onChange, ...args } ) => {
	const [ value, setValue ] = useState();
	return (
		<SomeComponent
			{ ...args }
			onChange={ ( ...changeArgs ) => {
				onChange( ...changeArgs );
				setValue( ...changeArgs );
			} }
			value={ value }
		/>
	);
};

export const Default = Template.bind( {} );

2. Consists of only one component

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.

3. Don’t create too many stories

While 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, additional stories should only be included if they involve significant visual or behavioral changes.

4. About meta data

To display the source panel by default, specify 'shown' in the meta.parameters.docs.canvas.sourceState field.

Example
const meta = {
	// ...
	parameters: {
		docs: {
			canvas: { sourceState: 'shown' },
			// ...
		},
	},
	// ...
};

Define the component description via the meta.parameters.docs.description.component field instead of a comment.

Example
const meta = {
	// ...
	parameters: {
		docs: {
			// ...
			description: {
				component: 'Component description here...',
			},
		},
	},
	// ...
};

Explicitly define the type of props via the meta.argTypes.{propName}.table.type.summary field.

Example
const meta = {
	// ...
	argTypes: {
		// ...
		propName: {
			// ...
			table: {
				type: {
					summary: 'string',
				},
			},
		},
		// ...
	},
};

For private components, you may want to define the following fields to display the badge 🔒 (Private APIs README).

Check here to see if the component is exported as private.

Example
const meta = {
	// ...
	tags: [ 'status-private' ],
	// ...
};

5. Others

If the component you're working on doesn't have a README or JDoc, I'd appreciate it if you could do the following to clarify the component's implementation first:

Block Editor Components directories List

Components List

Note: 🔒 indicates that the component is private.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Good First IssueAn issue that's suitable for someone looking to contribute for the first timeStorybookStorybook and its stories for components[Type] Developer DocumentationDocumentation for developers[Type] Tracking IssueTactical breakdown of efforts across the codebase and/or tied to Overview issues.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions