Has there been any discussion to adding this feature, of being able to run storybook at the same time or run it inside the App ?
or if there is a way to do this i'd love to know since i couldn't find anything on this.
Not sure if I understood you correctly. Are you talking about React Native? If so: we always start the storybook in Dev and created a story for the usual app entry. So if you want to test the normal app, you can just select that story.
See https://github.com/serlo-org/serlo-abc/blob/master/App.js and https://github.com/serlo-org/serlo-abc/blob/master/src/index.stories.js
As far as I know, there aren't any plans to allow Storybook to run inside a route so that you can include it in your app. It is meant as a development and testing tool so I'm not sure what the use case would be to have that in a user facing app.
You technically could have two start scripts and two separate entry points so you can run them together doing development but that involves some creativity.
@tmeasday this is something you were interested in, right?
@danielduan I believe the arguments include:
Probably others that I'm forgetting...
Yeah, we have experimented extensively with this, and it is perfectly possible to render storybook stories within the user's app (after all they are just components from the app).
@danielduan a lot of component explorers do work this way. Having to configure webpack a second time for storybook isn't heaps of fun and IMO it would be better if we could avoid it (assuming we don't lose anything, which isn't guaranteed, don't get me wrong).
The idea is that you add a new route that is only added in development. It wouldn't ship to the production app (although I guess it could if that's what you wanted). Something along the lines of:
if (process.env.NODE_ENV === 'development') {
require('../.storybook/config.js');
require('@storybook/react').renderAtPath('/storybook');
}
My motivation is to make it easier for new users to onboard with storybook. Having to think about separate processes / webpack config / scripts etc etc are just barriers that I would prefer not to have ;)
@tmeasday can you elaborate on this? I am attempting to do something like this but can't seem to crack into the storybook webpack the way I'd like.
My task: take the .scss files and generate 3 different versions to swap around from the dom while in storybook.
My attempted solution: run 3 different webpacks within a node server to generate the stylesheets.
Blockers: I can't figure out simple things that are hidden by the storybook webpack, such as entries. I attempted this solution, but don't think I have the placement correct for it. Any help would be appreciated!
@creatyvtype in the above I think I was hinting at doing something like the PR I mention in this ticket.
However I'm a bit confused about how it would help with what you are trying to do. I fact I think I am generally confused about what it is you are doing. Can you explain it to me a little more? ;)
Sure,
So we have a package that exports styled elements like Input, TextArea, Tooltips, etc. They have slight differences based on 3 user types. Previously, to accomplish this, we had to export 3 different stylesheets and the consuming app would have to import the stylesheet they want in order to make it work. For bundle size and overhead, we wanted to find a solution where the element already has its stylesheet imported directly. My solution was to just have the stylesheet include an scss variable for the user type at the top, and based on the webpack configs of the consuming apps, set the user type, swap out that line on the scss files that are loaded, and get the right styles.
The issue is that in the storybook to display these elements to designers and devs for documentation, I cannot load all 3 versions of the stylesheets at the same time. In order to do that, our thought was to run 3 webpacks via a node server to render the 3 different stylesheets, and use just basic dom manipulation to swap out the stylesheets using a switch we create. This task has proven difficult due to the webpack setup for storybook. Our ultimate solution may require us to do away with storybook for this particular package unless there is a better way to rewrite these 3 stylesheets AND have it update automatically while devs develop.
Let me know if this is still confusing...
That makes sense I think.
Given you want to run separate webpack servers for each user type but use a single storybook, could it not make sense to just run the app as usual in the three different configurations, say on ports 3001-3003 and then load the CSS in via injecting a style tag in the head? Or is the CSS not available at a specific URL on the app?
In any case, it should be possible to alter storybook's webpack config in any case. Have you read: https://storybook.js.org/configurations/custom-webpack-config/ -- what is it that you aren't able to do?
We already do have a custom configuration, but yeah what I wanted was to do essentially that... let me take another stab at this tomorrow and see where I get.
I was looking at this as a potential solution, but right now all we have is the storybook running (no actual app to embed in).
@AndreiCalazans please check this: https://github.com/storybooks/storybook/issues/190#issuecomment-444535554
Most helpful comment
Yeah, we have experimented extensively with this, and it is perfectly possible to render storybook stories within the user's app (after all they are just components from the app).
@danielduan a lot of component explorers do work this way. Having to configure webpack a second time for storybook isn't heaps of fun and IMO it would be better if we could avoid it (assuming we don't lose anything, which isn't guaranteed, don't get me wrong).
The idea is that you add a new route that is only added in development. It wouldn't ship to the production app (although I guess it could if that's what you wanted). Something along the lines of:
My motivation is to make it easier for new users to onboard with storybook. Having to think about separate processes / webpack config / scripts etc etc are just barriers that I would prefer not to have ;)