-
-
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
Refactored storybook component library #1266
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.
A couple of small things, otherwise 👍
@@ -1,28 +0,0 @@ | |||
import PropTypes from 'prop-types'; |
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.
In theory this file is testing different ways of requiring stories in storyshots.
In practice we don't exercise this test right now. I'm not sure how to do it :/
In any case, I'm not sure we should remove it yet?
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.
There's no difference in requiring it from a local file or from a npm package?
I'd like to remove duplication..
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.
@ndelangen some of the files in the storyshots/stories
are required directly (require('path/to/file')
) in the .storybook/config.js
, where as some others are required via require.context
. I guess the idea is to test both methods.
I think your changes removes that and just requires everything directly.
As we aren't testing everything right now I wouldn't block on this, but I wanted to point it out.
@@ -3,7 +3,7 @@ import React from 'react'; | |||
import { storiesOf } from '@storybook/react'; // eslint-disable-line | |||
import { action } from '@storybook/addon-actions'; // eslint-disable-line | |||
|
|||
import Button from './Button'; | |||
import Button from '@storybook/components/dist/demo/Button'; |
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 export Button
directory from the package? Importing from a sub-path doesn't seem kosher to me.
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.
@tmeasday @ndelangen my understanding (possibly wrong) was that demo
is just one type of component, and that we are going to move all the storybook components into here. If that's the case, I think importing from a sub-path makes sense.
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.
Why not?
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.
My understanding is that it's generally not a great idea to ask users to require from files inside your package. It's obviously not universal not to do it (e.g. react-test-renderer/shallow
), but I think you'll notice most packages are moving away from it. The main reason is it is brittle:
-
You lose the flexibility to re-arrange how your files are organised in your package--certain files have to remain no matter what.
-
You expose details of your build process (cf
/dist/
being in the path). This is a bit ugly and restrictive again--e.g. what happens in the future when we don't need babel any more anddist
is redundant? Or iflerna
has some great new technique that favours a different naming of output files? -
Also, tooling understands the module entry point (
package.json#main
), whereas other entry points are just not going to be picked up. This also means new devs don't have any way to know which of our files users may be importing, exacerbating fix sidebar - content float issue #1.
It doesn't seem that hard to export everything from a common entry file to me.
import DemoButton from '@storybook/components';
OTOH, Storybook already asks users to import from paths a bit so if you want to do it, fine.
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.
@tmeasday I'll think about it. Exposing all components as 1 module would mean we should allow tree shaking, because otherwise there's the potential for package bloat.
In fact maybe we should open an issue for exposing the es-modules code for all packages https://github.com/rollup/rollup/wiki/pkg.module
Thanks for the review @tmeasday, I can't really find anything actionable in your first comment, and would like some additional info on the second one. |
I fully support the idea of having the only package with demo components and use it for all demos! But We can copy these files from package directly to the project |
@usulpro I'm not sure, I always found the fact that storybook puts down component files kind of weird and confusing. I feel like having defined components in your I guess adding a dependency on |
# Conflicts: # examples/cra-kitchen-sink/src/stories/Button.js # examples/cra-kitchen-sink/src/stories/Welcome.js
Codecov Report
@@ Coverage Diff @@
## master #1266 +/- ##
==========================================
+ Coverage 13.71% 13.76% +0.05%
==========================================
Files 207 201 -6
Lines 4646 4620 -26
Branches 517 573 +56
==========================================
- Hits 637 636 -1
+ Misses 3568 3493 -75
- Partials 441 491 +50
Continue to review full report at Codecov.
|
44a8f80
to
f15a548
Compare
f15a548
to
436767d
Compare
@tmeasday I'd really like to get this merged. I don't think the usage of deep file-requires is a too big of a deal to hold of merger. |
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.
¯_(ツ)_/¯
The deeplinks are an ok option for now, we will revisit this later
Issue:
What I did
I added a lib/package that will house all styled UI components.
How to test
npm run test