Skip to content
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

Merged
merged 8 commits into from
Jun 16, 2017
Merged

Refactored storybook component library #1266

merged 8 commits into from
Jun 16, 2017

Conversation

ndelangen
Copy link
Member

@ndelangen ndelangen commented Jun 12, 2017

Issue:

What I did

I added a lib/package that will house all styled UI components.

How to test

  • npm run test
  • view examples/cra-storybook's Welcome and Button component
  • use the cli to generate

Copy link
Member

@tmeasday tmeasday left a 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';
Copy link
Member

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?

Copy link
Member Author

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..

Copy link
Member

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';
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not?

Copy link
Member

@tmeasday tmeasday Jun 15, 2017

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:

  1. You lose the flexibility to re-arrange how your files are organised in your package--certain files have to remain no matter what.

  2. 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 and dist is redundant? Or if lerna has some great new technique that favours a different naming of output files?

  3. 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.

Copy link
Member Author

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

@ndelangen
Copy link
Member Author

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.

@usulpro
Copy link
Member

usulpro commented Jun 15, 2017

I fully support the idea of having the only package with demo components and use it for all demos!

But getstorybook a bit another case. We add this files to the project code to let users play with them as the simplest example. I guess users remove Button.js and 'Welcome.js' from theirs storybooks later. So removing sources and adding packages possible could confuse?

We can copy these files from package directly to the project
Here is PR for that against this branch #1283
still one source of code but instead of requiring from the package it copies these files

@tmeasday
Copy link
Member

tmeasday commented Jun 15, 2017

@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 stories folder would be a source of confusion for people "is this what I'm supposed to do? I thought storybook was for testing my components?".

I guess adding a dependency on @storybook/components which eventually will be unused (directly) by the app isn't ideal but (a) it's a devDependency, and (b) the storybook packages themselves will depend on it anyway, so it would have been installed anyway.

# Conflicts:
#	examples/cra-kitchen-sink/src/stories/Button.js
#	examples/cra-kitchen-sink/src/stories/Welcome.js
@codecov
Copy link

codecov bot commented Jun 16, 2017

Codecov Report

Merging #1266 into master will increase coverage by 0.05%.
The diff coverage is 0%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
lib/components/src/demo/Welcome.js 0% <0%> (ø)
lib/components/src/demo/Button.js 0% <0%> (ø)
...ts/stories/required_with_context/Button.stories.js 0% <0%> (ø) ⬆️
...dons/storyshots/stories/directly_required/index.js 0% <0%> (ø) ⬆️
...s/stories/required_with_context/Welcome.stories.js 0% <0%> (ø) ⬆️
app/react/src/client/preview/client_api.js 39.28% <0%> (ø) ⬆️
app/react/src/client/preview/reducer.js 0% <0%> (ø) ⬆️
.../src/manager/containers/CommentsPanel/dataStore.js 34.78% <0%> (ø) ⬆️
addons/knobs/src/components/WrapStory.js 12% <0%> (ø) ⬆️
addons/info/src/components/Props.js 0% <0%> (ø) ⬆️
... and 27 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b244f99...0be8829. Read the comment docs.

@ndelangen ndelangen force-pushed the add-lib-components branch 3 times, most recently from 44a8f80 to f15a548 Compare June 16, 2017 09:26
@ndelangen ndelangen force-pushed the add-lib-components branch from f15a548 to 436767d Compare June 16, 2017 09:29
@ndelangen
Copy link
Member Author

@tmeasday I'd really like to get this merged.
This is a very important stepping stone for storybook IMHO.

I don't think the usage of deep file-requires is a too big of a deal to hold of merger.

Copy link
Member

@shilman shilman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

¯_(ツ)_/¯

@ndelangen ndelangen dismissed tmeasday’s stale review June 16, 2017 12:24

The deeplinks are an ok option for now, we will revisit this later

@ndelangen ndelangen merged commit 40858bf into master Jun 16, 2017
@ndelangen ndelangen deleted the add-lib-components branch June 16, 2017 12:25
@shilman shilman changed the title Add lib components Refactored storybook component library Jun 17, 2017
@usulpro usulpro mentioned this pull request Jun 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants