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

Use parameters for info addon #3697

Merged
merged 15 commits into from
Jun 9, 2018
Merged

Conversation

Keraito
Copy link
Contributor

@Keraito Keraito commented Jun 1, 2018

Last of #3625

On top of implementing the new parameterized way of using addons for info, I also added made changes regarding how the options and parameters were processed with respect to each other, #3625 (comment). Before, the addon parameters would be the ones that were the latest set (global -> local -> story), replacing the previous ones entirely.

Now, it only replaces the addon properties per key, #3625 (comment). I don't think my solution in lib/core/src/client/preview/client_api.js is the cleanest one, so if anyone else has a better idea, happy to hear! I tried some stuff with reduce but that only made more of a mess.

I applied similar logic to the handling of options and parameters.

Core tests

2 snapshot tests failed in 1 test suite, both output:

    - Snapshot
    + Received
    
...

    - <Component>
    + <deprecated>

This seems unrelated to my changes, or am I mistaken?

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.

Some comments to remove the old API a little more.

I'm not sure if info is a special case because it needs to be the first addon?


It is important to declare this decorator as **the first decorator**, otherwise it won't work well.

```js
addDecorator((story, context) => withInfo('common info')(story)(context));
addDecorator(withInfo);
Copy link
Member

Choose a reason for hiding this comment

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

I think it is worth indicating this should be done in .storybook/config.js

);
```


## Global options
Copy link
Member

Choose a reason for hiding this comment

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

Let's deprecate this and the usage as a HoC ("Basic usage" and "Usage with options") -- so let's remove it from the docs.

Copy link
Member

Choose a reason for hiding this comment

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

@tmeasday on a related note, do you think we should have a Deprecated section in storybook-official so we still get story snapshots for deprecated usage, but they are separate from the recommended usage examples?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tmeasday Just so we're on the same line: you want to deprecate the setDefaults way of setting defaults (and shift that to the addDecorator in the config.js with either options or parameters) and remove all the docs involving this + the HoC?

Related to this, should I then rewrite all the existing info stories in official-storybook to use the parameterized way?

Copy link
Member

@tmeasday tmeasday Jun 4, 2018

Choose a reason for hiding this comment

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

Sorry guys, missed this!

should have a Deprecated section in storybook-official so we still get story snapshots for deprecated usage, but they are separate from the recommended usage examples?

Probably a good idea @shilman -- perhaps a small refactor of the stories after we get the last few PRs merged is in order.

Just so we're on the same line: you want to deprecate the setDefaults way of setting defaults (and shift that to the addDecorator in the config.js with either options or parameters) and remove all the docs involving this + the HoC?

Yeah that was what I was thinking, do you agree? Definitely get rid of the HoC; and setDefaults seems redundant now, right?

Related to this, should I then rewrite all the existing info stories in official-storybook to use the parameterized way?

What I've been doing is leaving the existing ones as "tests" for the deprecated functionality (we can remove them when actually delete that functionality). Then making sure there are stories to cover all the new ways of doing it! You don't need to re-test that parameter inheritance works though (although maybe adding a the story in core.stories.js to test your change to the way it works?), just add stories that make sense.

I hope I'm making sense here 😬

export const withInfo = makeDecorator({
name: 'withInfo',
parameterName: 'info',
wrapper: (getStory, context, { options, parameters }) => {
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to skip the addon if they don't set options or parameters? Either by passing skipIfNoOptionsOrParameters: true or manually doing it here..

Copy link
Member

Choose a reason for hiding this comment

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

Otherwise (or maybe anyway) we should document setting { info: { disable: true } }

Copy link
Contributor Author

@Keraito Keraito Jun 2, 2018

Choose a reason for hiding this comment

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

Def agree with the disable: true part, will do. I'm not so sure about the skipIfNoOptionsOrParameters part though. I assume the both of them do the same thing, namely disable the addon entirely. But info is slightly different from the others addons imo that it does something even without configuration: display Proptypes, the component, etc.

Example: https://github.com/storybooks/storybook/pull/3697/files#diff-c915ecbefba3a2734ebd93eb258431dbR353 This is basically an parameters- and options-less story, besides some minor options (header styling) and parameters (inline and manual text). The configuration don't add a lot, but the addon itself adds a lot of information stand-alone already.

So I would say just only documenting the disable flag should be the only way

Copy link
Member

Choose a reason for hiding this comment

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

Ok, makes sense. Thanks for thinking about that.

if (params) {
Object.keys(params).forEach(key => {
if (typeof params[key] === 'object') {
allParam[key] = Object.assign({ ...allParam[key] }, params[key]);
Copy link
Member

Choose a reason for hiding this comment

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

Maybe just { ...allParam[key], ...params[key] }? Kind of odd to use Object.assign and object spread ;)

@tmeasday
Copy link
Member

tmeasday commented Jun 2, 2018

Look great btw! Thanks @Keraito

@codecov
Copy link

codecov bot commented Jun 2, 2018

Codecov Report

Merging #3697 into master will increase coverage by 51.13%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #3697       +/-   ##
==========================================
+ Coverage   41.36%   92.5%   +51.13%     
==========================================
  Files         459       6      -453     
  Lines        5087      40     -5047     
  Branches      856       2      -854     
==========================================
- Hits         2104      37     -2067     
+ Misses       2473       2     -2471     
+ Partials      510       1      -509
Impacted Files Coverage Δ
addons/viewport/preview.js
addons/info/src/components/types/ArrayOf.js
app/marko/src/server/index.js
app/angular/options.js
app/react/src/client/preview/element_check.js
lib/ui/src/modules/ui/configs/init_panels.js
addons/info/src/components/types/PropertyLabel.js
addons/links/src/manager.js
addons/graphql/src/preview.js
app/angular/src/server/options.js
... and 441 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 dfb0347...3cc1566. Read the comment docs.

@Keraito
Copy link
Contributor Author

Keraito commented Jun 2, 2018

I processed most of the feedback. Waiting on a reply on #3697 (comment), then i will finish everything up

@Keraito
Copy link
Contributor Author

Keraito commented Jun 4, 2018

Oops I totally referenced the wrong comment in my last message, I meant this one #3697 (comment) (about deprecating the previous usage and what to change exactly). 🙈sorry @tmeasday could you take a look again?

@@ -98,5 +99,8 @@ export const withInfo = makeDecorator({
export { Story };

export function setDefaults(newDefaults) {
return Object.assign(defaultOptions, newDefaults);
return deprecate(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't feel like this is how I should've implemented the depreciation, but only this worked for me for some reason.

Copy link
Member

Choose a reason for hiding this comment

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

@Keraito you tried export const setDefaults = deprecate(newDefaults => Object.assign(...), 'setDefaults is ...')

I mean what you have is fine anyway ;)

@Keraito
Copy link
Contributor Author

Keraito commented Jun 5, 2018

Should be all done now, could u review again @tmeasday ! 😊

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.

Looks great @Keraito!

@Hypnosphi
Copy link
Member

Please update test snapshots: yarn test --core --update

@Keraito
Copy link
Contributor Author

Keraito commented Jun 8, 2018

I updated the test snapshots, but my 5 added stories for some reason fail with the following error: Invariant Violation: React.Children.only expected to receive a single React element child. Not sure what is exactly causing this

@Keraito
Copy link
Contributor Author

Keraito commented Jun 8, 2018

I'm kinda confused at what's going on. I actually updated the storyshots before (29aaa62).

My second commit just now (after running yarn) removed all the updates to the snapshots. The first run of yarn test --core --update however also removed the snapshots update of my added stories and the error described in #3697 (comment) is still present

@shilman shilman mentioned this pull request Jun 8, 2018
6 tasks
@Keraito
Copy link
Contributor Author

Keraito commented Jun 8, 2018

Nevermind all of that, apperently I just didn't have the dev server running 🤦‍♂️ Should be all good now

@Hypnosphi Hypnosphi merged commit 4a250fb into storybookjs:master Jun 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants