`category` and `folder` parameters for `@UseCase` about widgetbook HOT 8 CLOSED

@geisterfurz007 Good luck with the implementation 🍀
After solving this issue, the users should be able to write the following code:

@UseCase(
  type: Button, 
  name: 'Default',
  category: 'Inputs',
  path: 'buttons/primary/',
)

This should override the default path path/to/widget/Button/Default with Inputs/buttons/primary/Button/Default.

from widgetbook.

Hello, I would like to work on this 🦥

from widgetbook.

@YoussefRaafatNasry Quick request for clarification: The title says folder and your code says path. Which of the two would be preferred?

from widgetbook.

And @YoussefRaafatNasry another question: What would the result be if either of the two was null?

Or actually: Why even have the split between a category and a path/folder in the first place? Storybook for example splits the component's title and uses that as path. If none is provided, it falls back to the path, just like widgetbook does now.

Is it possibly even viable to have

@UseCase(
  type: Button,
  name: 'Inputs/buttons/primary/Default',
)

produce something slightly different from what you provided above: Inputs/buttons/primary/Default. If I as developer provide such a path, I personally at least would not expect another Button node to be added at the end, tbh.

I also wouldn't mind a dedicated parameter for the path but I don't understand the usecase (pun not intended) for having two that are just put together anyway. It just introduces more chaos with the potential of either of them being null.

from widgetbook.

@geisterfurz007 I would prefer using path over folder to give the "nesting" vibes, because if it's only called folder I would think it's just a single folder name.

I like your suggestions of combining the component, folder and title variable in one parameter, and it's actually one of the approaches we are considering for Widgetbook 4 with slight modifications. The reasons I don't see us going with exactly this approach are:

1. Currently all WidgetbookUseCases should be a child of WidgetbookComponent. So providing Inputs/buttons/primary/Default will result in Inputs/buttons/primary/Button/Default, and it will be a bit confusing as you've mentioned. (We are working on changing this in future versions)
2. Some users might want to use folders over categories, so with two parameters category and path they can just leave category undefined. To differentiate between categories and folders in Widgetbook 4, we used square brackets like this [Inputs]/buttons/primary.

To sum it up, I don't mind merging category and path in one parameter called path (using the square brackets approach or any other similar one). But I am slightly not fan of merging path and name due to the first point mentioned above. I am quite open for more discussions if you have any other thoughts/ideas.

Here's an example that can make things more clear as well:

@UseCase(
  type: PrimaryButton,
  name: 'Default',
  path: 'buttons', // or '[Interaction]/buttons'
  category: 'Interaction'
)

@UseCase(
  type: TextField,
  name: 'Default',
  path: 'inputs', 
)

@UseCase(
  type: RadioButton, // This type is defined in widgets/group/radio_button.dart
  name: 'Default',
)

.
├── widgets/
│   └── group/
│       └── (RadioButton)
│           └── Default
├── inputs/
│   └── (TextField)
│       └── Default
└── [Interaction]
    └── buttons/
        └── (PriamryButton)
            └── Default
            
 Glossary:
 .     : WidgetbookRoot
 foo/  : WidgetbookFolder
 (foo) : WidgetbookComponent
 foo   : WidgetbookUseCase

from widgetbook.

Yeah, I figured that aiming for everything in name was a bit of a longshot 😄

Can you give me some insight as to what the difference between a category and a folder is? Other than a different icon in the UI, I am struggling to understand what the significance of one or the other is and why it needs a special notation for it.

from widgetbook.

Can you give me some insight as to what the difference between a category and a folder is? Other than a different icon in the UI, I am struggling to understand what the significance of one or the other is and why it needs a special notation for it.

@geisterfurz007 Category is just a "folder" in disguise, it's just a better way to organize/group your use-cases. We will work on making it more visually different than a folder in the future. Some users use categories to group by app, if they have a monorepo. Others will use it to group by platform (e.g. android and iOS).

from widgetbook.

Gotcha, thanks! I'll get back to fiddling around with this a bit more somewhere next week then 👌

from widgetbook.