-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Addon-docs: Module story format & framework param #7110
Conversation
This pull request is automatically deployed with Now. Latest deployment for this branch: https://monorepo-git-7101-module-story-format.storybook.now.sh |
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
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.
👍
@@ -15,5 +14,9 @@ export const { | |||
raw, | |||
} = clientApi; | |||
|
|||
const framework = 'angular'; |
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 understand that passing framework will be used later (I see it already in https://github.com/storybookjs/storybook/pull/7119/files#diff-0f7bedc2d2cb7019c3fe0f0f28c18959R13). Are any other usecases to this ? (I am always standing for things to be generic =) )
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.
@igor-dv Yeah, I use it to automatically configure things about docs. For example, react defaults to inlining story renders, whereas the rest default to iframes. React and vue support Props
prop tables, the rest do not, etc.
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 it worth exposing "feature sets" that each framework supports instead of the framework
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.
That's not a bad idea, though I plan to switch on the framework string to figure out e.g. how to extract the prop definitions. In addition, I believe that having this parameter also coincides with the multiframework stuff that @Hypnosphi is working on, so I thought it would just be a good thing to establish while I am making use of it in the docs work, rather than adding some new mechanism.
Issue: #7101
What I did
This PR combines two different ideas: module story format and adding a "framework" parameter for stories. I combined the two PRs because they touch the same code and it's a pretty simple "regular" change that gets repeated across all the apps.
How to test
Probably should add unit tests as well, and potentially convert the other examples to the new load API. Suggestions?