-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Framework: Add Component Storybook. #17475
Conversation
How would it play with #17173 from @ItsJonQ where he proposes a site with live examples of components? There is also the playground. In addition, there is also a proposal to create some specialized testing app for RichText proposed by @ellatrix in #17303. Moving forward, we will also need playgrounds for iOS and Android example apps working with React Native. See #17456 from @Tug. I guess, all individual solutions makes sense but we should coordinate everything and bring them as close as possible so we don't have to maintain 6 completely independent apps with their own unique tooling and build steps. Do you have any thoughts on how this could be consolidated as much as possible? Should we start with some sort of proposal which describes the role of every tool and how they can benefit workflows of different types of contributors? |
Thanks, @epiqueras – storybook has improved since the last time I looked at it. The keyboard shortcuts are handy. Is there a chance we can get as part of the netlify deploy? Not having to run it locally will be super useful. I thought twice before running it locally :) The in-browser test also look like a useful tool. On styles – the link uses the default browser styles, do you think it would make sense to put it in some WordPress style context? How was the story format chosen? Both mdx and And few additions that would be helpful, even if not in this PR:
|
This is a much simpler alternative approach. We should however, theme it so that it looks more like WordPress docs, but that can be a different PR.
Yeah, those are parallel things.
Yeah, Storybook can support React Native.
This is a very conservative start. I'm making no assumptions about any sort of decision beyond using Storybook for the component playground.
Yeah it looks like it reclaimed its throne in the UI playground space. They even support MDX docs now.
Yeah me too. I just added it.
I'm not sure. I added the Gutenberg styles, but if this will be potentially used outside of a WordPress context, maybe it's a sign we need to add more default styles?
Good question. The MDX is for authoring freeform Docs with embedded stories like React Styleguidist. It can and should complement the playground.
The addon that does that is out of date, so it might be a bit involved, but another PR can take care of it.
I almost added the Knobs addon, but linking props to it is a very manual process and I want to be conservative about enforcing things on contributors. If we think it's worth it, we can add it.
Yeah, that's what MDX will be for. |
Just took a look! @epiqueras thank you for putting this together! I think Storybook is a fantastic addition to the UI dev/design work flow (essential IMO). @gziolo Re: documentation @epiqueras shared this link with me: If we're able to get this into Storybook, then it is able to accommodate the needs that the doc site (that I had proposed) attempted to address. cc'ing @jameslnewell 😊
P.S. I'm a big fan of Storybook knobs :). The reason is because it allows folks to very quickly QA things in the browser. A great example is text values. "What if this person has no first name?" You can add these things via knobs, and see if/how the UI breaks Folks can do this directly in the Netlify generated deploy preview within PRs. |
I've gone ahead and added the new MDX doc features. Every story file now gets a docs page automatically generated, but you can overwrite them with custom MDX files. I've also added a stand-alone documentation page as an example. I think this new "Docs" feature suite removes the need for most of the plugins talked about above. We can always add more later on PRs that actually make real use of them. Here is more information on the new features: https://github.com/storybookjs/storybook/blob/next/addons/docs/README.md#more-resources Take a look at how pages are automatically generated, how MDX can be used to overwrite them, and how you can theme the docs and export them on their own. |
@epiqueras Could you try to create stories for a component that has JSX? I'm using your PR to create stories for
It's fixed if I add an empty |
@diegohaz It was picking up the root babel config and that transforms JSX into calls to Thanks! |
It seems like Storybook performs some magic operations on Babel config, similar to what Parcel does. This is what we had to add for Parcel: Lines 1 to 9 in bf1ca07
|
"playground:start": "concurrently \"npm run dev:packages\" \"parcel playground/src/index.html -d playground/dist\"", | ||
"preenv": "npm run check-engines", | ||
"env": "wp-scripts env" | ||
"env": "wp-scripts env", | ||
"design-system:dev": "concurrently \"npm run dev:packages\" \"start-storybook -c ./packages/components/storybook\"", |
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.
for playground we use :start
and for gutenberg we use :dev
I personally prefer start but we should try to consolidate all these similar commands on :dev
maybe to avoid impacting the plugin devs.
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've seen start
used more to start production apps like web servers, so I kind of liked we opted for dev
.
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.
Can we update the playground one?
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.
Done
|
||
# Introduction | ||
|
||
Hello World |
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.
Are we concerned about the duplication in terms of docs, this will introduce. Components have READMEs that are currectly synced into the WordPress handbook and they'll have special docs that will live in the storybook?
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.
These are the design system docs.
A lot of that content will probably be moved here though.
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.
These are the design system docs.
This is what the README are for. so the components part for the design system will get duplicated?
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.
Yes, but MDX is much better than a simple README.md and will be the new framework for them.
I guess we can delete the READMEs once the new docs are fleshed out.
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.
We can't delete the READMEs until we figure out how to show Storybook in the wp.org devdocs. I'm concerned that it will take a lot of time and that we'll have to maintain duplicated content for a long time.
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.
Storybook can export static files, that won't be hard to do. And it won't be duplicated, the new docs will be better and there won't necessarily be a 1 to 1 mapping, because the goal is to overhaul this package into a proper design system component kit.
@@ -0,0 +1,41 @@ | |||
/** |
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.
Is it possible to move it out of the components
package?
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.
It can be wherever, but I don't think that's a good idea. These are like tests and should live next to components.
Other storybooks, like the block editor's, might warrant a different file structure though.
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 can see that but if we're using Storybook as a doc website, I think it defeats that argument. We should first clarify what we want Storybook to be used for.
If it's for a docs website, I believe a separate location is better, if it's just for having stories to develop the component, I think having them in subfolders is fine.
I can also see a folder structure like that:
playground
- design-system
- block-editor (current playground)
- ios (these exist today but in the mobile repo)
- android
basically a folder for all playgrounds.
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.
We are using it for both. Storybook has a component playground mode and a docs website mode.
The playground mode files should live next to their components, because they are like tests and will need to reference them heavily. It also lets you easily see which components are missing stories.
The docs mode files should live in a docs folder in the root of their package, like docs/introduction.story.mdx
here, because they are just freeform documentation and are not tied to a specific component.
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 feel we're trying to solve a lot at the same time. While I agree that it would be great to use storybook for both, I think we should have a clear plan about how to update the docs, how to sync them to wp.org docs. Right now when I look at the output, it's a mix of both which I'm not sure is perfect to sync as is into wp.org. Also how to do it.
I'd be ok to land storybook as an experiment for now until we figure out all these things but an experiment shouldn't impact the current codebase a lot that's why I wonder if it's better to start as a separate folder
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 feel we're trying to solve a lot at the same time.
We are just solving "choosing the docs framework for reusable components".
I think we should have a clear plan about how to update the docs, how to sync them to wp.org docs.
Travis job that deploys static files.
Right now when I look at the output, it's a mix of both which I'm not sure is perfect to sync as is into wp.org
There's CLI options for separating the 2 or we can theme it so that it fits better into .org's site patterns.
I'd be ok to land storybook as an experiment for now until we figure out all these things but an experiment shouldn't impact the current codebase a lot that's why I wonder if it's better to start as a separate folder
What could change is how we theme and layout Storybook's output, but not the use of Storybook, it's by far the best option out there for this.
Right now this just uses defaults for everything, but with this as a base, designers can lay things out with custom navigation, layouts, colors, and whatever else the .org site needs.
Yeah, we don't need that though, because Storybook uses its own version of React. |
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 willing to merge this but we need a plan to move this forward, should we create a follow-up issues about adding stories for all components, how about docs? who own this?
80006cc
to
b06c88b
Compare
cc @ItsJonQ Merging as soon as Travis is finished here 🎉 |
22ee0cb
to
0f08f49
Compare
I rebased changes with |
Added unit tests might fail from time to time so it would be nice to address this comment from my accompanied PR: |
2c47dcc
to
1778807
Compare
1778807
to
edd53d4
Compare
https://wordpress.github.io/gutenberg/ is broken, not sure if this is related to this PR but we need ot investigate it. See the section about the playground: |
before_deploy: | ||
- npm install | ||
- npm run playground:build -- --public-url '/gutenberg' | ||
- npm run design-system:build |
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.
It looks like with the changes applied in this PR, design-system:build
will run twice on Travis:
"playground:build": "npm run build:packages && parcel build playground/src/index.html -d playground/dist && npm run design-system:build",
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.
#17818 also fixes this. |
Description
This PR adds Storybook support to the repo and uses it to create a storybook for
@wordpress/components
using theButton
component as an example.It also adds plugins for automatically running and displaying accessibility tests right besides stories, simulating color blindness, and changing the viewport size/device.
The PR also modifies the Travis config so that the storybook is deployed to GitHub Pages using the
/design-system/components
path.This gave me the idea that maybe the GitHub Pages page should use a custom domain in
wordpress.org
and present some sort of landing page for the JS focused WordPress efforts. That can then link to the editor playground and the storybook.How has this been tested?
The new storybook was verified to work in development (
npm run design-system:dev
) and production (npm run design-system:build
) modes.Screenshots
Passing a11y Tests
Failing a11y Tests
Color Blindness Simulator
Changing Viewports
Checklist: