-
-
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
Substories/Hierarchy #151
Comments
Currently, we've no plan to implement that. That's because it makes navigation harder. You can namespace story kinds with dot like "ui.core", "ui.app". Then you can filter them as you need. If there are a lot of stories, you can start a few storybook instances. You can do that by having two storybook config directories. But, anyway that's an extreme case. |
I'm willing to concede this point, and thought I'd just make a different config and run it on a different port and whatnot... But I think it'd be much better to allow storybook to take multiple config files... and then toggle between named config files, perhaps reloading... As for UI to switch configs, it would only appear if your config file "loaded" other config files, and it could be sidebar items at the top or bottom of the sidebar nav. Anyway - I think for larger apps, if you can't (or don't) split out configs, it's kinda crazy. |
Adding additional configs seems to be overly complex. What about a toggle for classic/hierarchy view? I'm happy spike out an implementation over the next few days. |
This would be a very valuable feature to me as well, but for organization of component types within a single app rather than for multiple apps. I would be more than happy to provide any help in shaping an implementation that could work for both use cases if this is able to move forward. |
@travi One of our another idea is to provide a drop down menu just below the filter box to select the category. A category is assigned in the config.js and different set of files. So, we can have a another layer of grouping. |
I think that type of solution would be enough to satisfy my needs at this point. In addition, I think the namespacing convention mentioned above could still be a reasonable way to assign the category that could be interpreted into the choices in the drop down. Such a solution would enable linking across categories to still remain simple as well. |
The way that we're getting around this in the app I'm building (hundreds of components, organized inside loose "pillar" areas) is with a script that dynamically writes out the stories for the area we're currently working on.
This means that Storybook doesn't even have to build the other components. I would love some level of support for this as a built-in option. |
#201 could help on this. |
any updates on this one? |
+1 |
I'm argee thats a very useful feature! |
+1 |
5 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
Hey @arunoda, has there been any progress on the categories implementation front? If not, does anyone else have an example app that toggles between two storybook configs? |
+1 I absolutely need one additional level of nesting :/ |
+1 |
5 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
well looks like while your app grows, the components list grows too, and you need some more nesting. 1 more level would already cover much cases |
+1 |
@TheSisb , thanks, will be fixed in the official release. @psimyn , in the current implementation it's not possible.. but might be changed.. @usulpro mentioned this in the initial PR too. |
This is the exact solution I needed !!! thank you +1 |
@psimyn Please open a new issue describing the feature? This issue will be closed real soon with the release of |
is having multiple level of nesting now possible with the new CSF format ? |
@gaurav5430 it's been possible for some time, see our example here: CSF: import React from 'react';
import { linkTo } from '@storybook/addon-links';
import { Welcome } from '@storybook/react/demo';
export default {
title: 'Other/Demo/Welcome',
component: Welcome,
};
export const ToStorybook = () => <Welcome showApp={linkTo('Other/Demo/Button')} />;
ToStorybook.storyName = 'to Storybook'; |
Hey @ndelangen I think what I want is the ability to create sub-folders based on
would show up as |
I think a workaround for the above issue would be to create multiple story files and export default with the correct hierarchy in each of them. like in
and in
That way, both the stories would show up as expected in the storybook folder structure |
@gaurav5430 that's the recommended usage, and not a workaround. 😄 |
Yes, I was just hesitant to do that as both these files are for different states of the same component. In my case, the component has 2 main states and multiple sub states based on those 2 main states. Usually I would keep all the states of the component in the same file, but in this case i would need to have a separate file for hierarchy in stories. |
I would also like to see something like this. Having to create a new file just to create some visual hierarchy is really cumbersome. On the other hand, our storybook gets cluttered really quickly if we dont create subfolders - Designers want an easy to understand storybook where they know where to click, and Developers want to cover all their test states, leading to dozens of stories per component. Being able to group those easily would help a lot with this problem. |
Would be nice to be able to have "Substories" or a Hierarchy of stories. My case involves various mini "apps" being contained in the same repo. A simple solution would be an option to display stores named like
ui.core.foo
andui.core.bar
like:With support for expanding and collapsing nodes.
The text was updated successfully, but these errors were encountered: