-
-
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
Use parameters for info addon #3697
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.
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?
addons/info/README.md
Outdated
|
||
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); |
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 think it is worth indicating this should be done in .storybook/config.js
addons/info/README.md
Outdated
); | ||
``` | ||
|
||
|
||
## Global options |
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.
Let's deprecate this and the usage as a HoC ("Basic usage" and "Usage with options") -- so let's remove it from the docs.
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 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?
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 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?
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.
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 }) => { |
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.
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..
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.
Otherwise (or maybe anyway) we should document setting { info: { disable: true } }
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.
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
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.
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]); |
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.
Maybe just { ...allParam[key], ...params[key] }
? Kind of odd to use Object.assign
and object spread ;)
Look great btw! Thanks @Keraito |
Codecov Report
@@ 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 Continue to review full report at Codecov.
|
I processed most of the feedback. Waiting on a reply on #3697 (comment), then i will finish everything up |
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( |
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 don't feel like this is how I should've implemented the depreciation, but only this worked for me for some reason.
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.
@Keraito you tried export const setDefaults = deprecate(newDefaults => Object.assign(...), 'setDefaults is ...')
I mean what you have is fine anyway ;)
Should be all done now, could u review again @tmeasday ! 😊 |
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.
Looks great @Keraito!
Please update test snapshots: |
I updated the test snapshots, but my 5 added stories for some reason fail with the following error: |
I'm kinda confused at what's going on. I actually updated the storyshots before (29aaa62). My second commit just now (after running |
Nevermind all of that, apperently I just didn't have the dev server running 🤦♂️ Should be all good now |
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 withreduce
but that only made more of a mess.I applied similar logic to the handling of
options
andparameters
.Core tests
2 snapshot tests failed in 1 test suite
, both output:This seems unrelated to my changes, or am I mistaken?