Open mjablecnik opened 1 month ago
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:
build_runner
process by having the widgetbook_generator
there. (this can become irrelevant after our investgation for macros)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.
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?
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.
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.).
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..
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.
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?