-
Notifications
You must be signed in to change notification settings - Fork 1
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
Set up Storybook #5
Conversation
- Adds Storybook itself, set up via Storybook CLI - Adds basic configuration, utils, and styles - Adds sample documentation section and introduction page - Adds simple configurable Button story
@egardner According to the docs for storybook-builder-vite, HMR is broken unless you're using |
Since having a reusable Story template isn't really applicable here, don't bother creating one and just create separate stories with their own component data.
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.
This is great! It starts up so quickly compared to Webpack. Build and dev mode both work fine as far as I can tell.
Just one question about whether we can use ES2017 here.
import { filterKeys, makeActionArgTypes, makeActionListeners } from '../../utils/StoryUtils'; | ||
import './Button.stories.less'; | ||
|
||
// This whole mess is because we're not using ES2017's Object.values(). |
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 a library preview, is there a reason we can't use ES2017 code if that makes things more legible? I assume Vite will transform the built code according to its configuration, which means we could compile back to ES2015 if we need to. Unless I'm misunderstanding something about how Vite + Storybook interact.
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't think of a reason. The eslint config in this library targets ES6, which is different from the WVUI config. Do we need to restrict ourselves for any of the code in this library, given we're using a build tool that will transpile it?
Also, regarding the lack of HMR, I think that this isn't such a big issue for a component library – it's not like you're going to need to preserve a lot of state to demo standalone components. If developers do want to get the HMR workflow while editing components, they should use Vite's |
This would involve setting up two separate demos, one for development and one for Storybook, right? I've always thought that one of Storybook's primary functions in a library like this is for the development process, too. Fortunately, I think this is actually a nonissue: now that I'm looking at it more closely, HMR does appear to work when updating a component. However, when updating a story, the entire contents of the story pane disappear for a few seconds, then reappear with the changes included. It's about 2 seconds in Chrome and 4 seconds in Firefox. Regardless, this is probably acceptable: it's much more important that we have true HMR during component development. |
Note that this repo's implementation of the Button is different from WVUI's so the stories won't match exactly, but if we want to update this Button component to match the current WVUI Button we can do that (and update the stories accordingly) in a future PR.