-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Add Doc Blocks overview & API reference #21113
Conversation
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.
Fantastic job @kylegach ! I have a few suggestions all over the place.
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.
Great job overall 👏 . I left some items that require attention, including snippets we should consider porting over.
006eacf
to
f8d3ab3
Compare
|
||
Each block has a dedicated API reference page, detailing usage, available options, and technical details. | ||
|
||
If a doc block accepts parameters, it is marked with **(P)**. |
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.
Really not sure about this idea. Very welcome to suggestions.
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.
I'm not sure it's needed? I would think it's self-explanatory that some of them reacts to parameters.docs.X
, some don't.
Eg. ColorPalette
doesn't because it doesn't reference any stories/components, so there's no where to pull parameters from. I don't think a user would try that.
But then I also see that Description
don't have a (P), which definitely reads from parameters, so maybe I'm misunderstanding the idea here.
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.
Description
is an odd duck. The content is provided via parameters, but the block isn't configured that way. 🤷♂️
The thought behind marking the blocks was an attempt at helping people understand (before clicking through to the API reference) which blocks can be configured. But I have another idea...
- Remove Doc Blocks guides - Update `docs/api/argtypes` to include information that was in `docs/writing-docs/doc-block-argstable` - Update TOC - Change `Write docs > Doc blocks` from a menu to a page - Add `API > @storybook/blocks menu`
Co-authored-by: Jeppe Reinhold <jeppe@chromatic.com>
Co-authored-by: Jeppe Reinhold <jeppe@chromatic.com>
- Simplify heading hierarchy - Make it more explicit that some block's prop's default values are derived from parameters
- Consistently include space after filename comment - Include `<Meta />` in snippets for blocks that are used in attached docs - Grammatical improvements
- Update ArgTypes and Controls parameter/prop examples
f8d3ab3
to
55786e2
Compare
This is a docs-only change, so I'm merging despite CI failures. |
What I did
docs/api/argtypes
to include information that was indocs/writing-docs/doc-block-argstable
Write docs > Doc blocks
from a menu to a pageAPI > @storybook/blocks menu
Example page
WIP
How to test
frontpage
, check out thedocs-content-style-tweaks
branch (see related PR)yarn extract-monorepo-docs doc-blocks-docs
GATSBY_SKIP_ADDON_PAGES=true yarn start
What to check for:
frontpage
PR for that)Checklist
MIGRATION.MD
Maintainers
make sure to add the
ci:merged
orci:daily
GH label to it.["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]