Project Structure

[mjablecnik]

Hello, when I see your Project Structure,
I want to ask you if you think about have your stories in same directory where is also widget.

For example I have this project: https://github.com/mjablecnik/design_package_example
where I have SimpleButton component in one directory with simple_button_styles, simple_button_stories and golden tests:
https://github.com/mjablecnik/design_package_example/tree/master/lib/design/buttons/simple_button

Reason is don't have more separate directory trees for stories, golden tests or styles but everything what depends with my widget component is in the same directory with the component and avoid splitting mutually related components into multiple directories.

What do you think about it? I solved this with storybook_toolkit which support generate golden tests in directory where I need.
Is something possible also with your Widgetbook 4?

[yousinix]

Hello @mjablecnik 👋
Thanks for you great feedback!

In fact, having the stories living next to the widgets is something not just considered, but also wanted to have (I personally liked it as well). But, we ended up going against it for the following reasons:

1. For big projects, we do not want to slow down the build_runner process by having the widgetbook_generator there. (this can become irrelevant after our investgation for macros)
2. Having such structure requires widgetbook package to be in the dependencies of your app or design system library. If you wanted to mock stories using mocktail (as seen here), then the dependencies list becomes even more "weird".

For one of our users with a big project, they realized that having widgetbook in a separate package is not that bad, as they could counter it with split editors or file finding.

We are still open for suggestions if you have any on how to counter the above problems.

[mjablecnik]

1. Is it slowed down also with: flutter pub run build_runner watch command?
   Or only with: flutter pub run build_runner build command?
   I compared it and build_runner watch is still watching my project and rebuild only some small piece of code which I changed and is not going via whole project as during build_runner build.
   And yes. I believe macros can solve this problem.

2. What is weird to have mocktail in dependencies? It is only for testing purpose there. When you build release of app so thanks by tree shaking some dependencies would not be included in result build. Or not?

[yousinix]

1. I believe that build_runner watch has a lot of caching going on. The build_runner build command will also use existing caches if you run it more than once. But usually these caches are checked-out of source control, causing the build_runner build command to be a relatively slower on CI.

2. These dependencies issues are not just about the bundle size, which can will be tree-shaked (unless users do something that cause it not to), but also about the confusion coming from having both widgetbook and mocktail in dependencies and not dev_dependencies. Since widgetbook have a couple of dependencies as well, the user's app might run in version conflicts.

Generally, one of our requirements is that widgetbook should not affect the user's app by any means (including dependencies download time, generating files, solving conflicting versions, etc.).

[mjablecnik]

Generally, one of our requirements is that widgetbook should not affect the user's app by any means (including dependencies download time, generating files, solving conflicting versions, etc.).

Yes, it make sense to have widgetbook folder out of the main project code. I will try to think about how to solve it. But right now I do not have any idea how to do it somehow else..

You can only give a choice to developer if he want to have it in extra directory or in the main project but with warning about these disadvantages..

[yousinix]

You can still technically have your widgetbook within your main project, but it is not something we would be willing to document or provide first-class support for it.