Group Stories in Example Apps by Addon or Feature

[danielduan]

Changes are really hard to test right now on our example apps. It's hard to find which component uses which addon and what features of the addon where.

I think it'd be nice if we follow a hierarchy that reflects the example's feature set.

example:

• Addon-Info
  • Docgen
    • React Prop Table
    • React Flow Prop Table
    • Imported Component Prop Table
  • Options
    • Custom Component Prop Table
    • Header
    • Inline

cra-example-app todo:

• Group by Addon or storybook feature in the top level
• Add examples of each addon use case
• Move deprecated features to its own top level group
• Add top level group for internal package development

future goals:

• get build process and location to host static storybook demo

[igor-dv]

I have had the same thoughts 👍

[usulpro]

I like this approach! 👍

I would also discuss :

• remove from cra-kitchen-sink examples emitting deprecating (and any other) warnings

• move big branches into separate files

• where to keep subcomponents of a package if we need them for development? For example, addon-info has a bunch of own components in src/components and src/components/markdown. Having a Storybook with them provides good dev experience. But do you really want to keep all of them in the common app?

[danielduan]

remove from cra-kitchen-sink examples emitting deprecating (and any other) warnings

I think that's a great idea, but it's nice to have one example that checks backward compatibility so that it doesn't regress. At least until we deprecate the feature.

move big branches into separate files

Yes, 100%! I was thinking a new file per top level group

where to keep subcomponents of a package if we need them for development

I see the kitchen sink more as an example app and also a testing environment for us. But I think it's possible we can add a top level dev file that includes components for development as well.

[usulpro]

Maybe we could put all deprecated examples into a separate story file in order to switch it off easily?

I see the kitchen sink more as an example app and also a testing environment for us

I fully agree with this! In this point, it makes sense to keep all warnings with it. But if you run it as a dev tool it could be not very convenient.
How can we import subcomponents from other packages?

[danielduan]

How can we import subcomponents from other packages?

I think we can do it the really ugly way and have it require from the relative path of the source package. That way when a developer changes the source file, it's immediately reflected. The import paths might get really long, but I think it's the most ideal solution.

I'd also like to get the examples working in a way that can showcase storybook usage so we can deploy it somewhere as well.

I'm gonna be away for the next two weeks. If anyone wants to take a shot at refactoring, feel free. Otherwise, I'll start when I get back.