Storybook tags, filter UI, and badges

[shilman]

In Storybook 8.4 we released Storybook tags with interactive filter UI, plus an addon for badges in the sidebar. (docs, addon).

Curious if you're finding tags useful, whether you have requests, and if you have use cases that you can share with the community!

[smlimasu]

Thank you for your work.

I would like to have a regex exclude filter option for tags in the sidenav Tag dropdown menu, because we have internal tags that we don't want to show.

Also, it would be great to have a tag like "test-only" or "internal" that displays stories in the sidenav only when they are checked (so that testers can toggle them on, but normal users don't in default.

Other use cases: I have made a docs component that shows various tags above the docs title as chips, also some tag-chips above each story-title in the docs. It reads from the story/meta. Would be great if there was a storybook block or option in stories-block, maybe with the tags addon (great work, frog!).

For the Controls/Argtypes tables, I enhance my Argtypes descriptions with various jsdoc tags and their info (filling the missing gap from compodoc.json) like deprecated, since (version XY), param. I display them in different colors and styles as chips to give my users more info about the argtype. Would be great if a) you could specify in preview which tags to include (like exclude internal, ignore (I know, this can be done via compodoc build options), include deprecated or version, and we would have these jsdoc info generated the same for all frameworks and b) set global styles to these tags like in the tags addon, maybe the same like create theme options.

Wish you happy holidays!

[shilman]

Thanks so much for the wonderful feedback! The "force test tags to show" UI is a great idea and addresses a problem that I've heard from many different users. I don't know the best way to implement that yet, but I'll think about it and will share a short RFC here once I have a proposal.

Would also be really cool to support JSdoc tags somehow. Though probably a non-starter based on the requirement that tags be statically analyzed during indexing.

@Sidnioulz I wonder whether the tags doc block could be a good addition to the Tags Badges addon.

[kylegach]

Sorry for being slightly off-topic here, but your Storybook sounds amazing, @smlimasu! 😍

[Sidnioulz]

@smlimasu please upvote this issue :) I'll likely work on it in a month-ish.

Sidnioulz/storybook-addon-tag-badges#30

[Sidnioulz]

Also, it would be great to have a tag like "test-only" or "internal" that displays stories in the sidenav only when they are checked (so that testers can toggle them on, but normal users don't in default.

I can see a few ways to achieve this.

There could be a default filter. If you wanted that, should it just be a default filter being applied (and you can disable it in the UI), or should the UI display an "empty"/"initial" state despite these filters being applied?

If the former, you could (soon?) use query parameters to pass URLs that configure those default filters. With a bit of redirection magic, you could enforce the default tags you want without having to explicitly set the query parameters.

---

If the latter, it would complicate the UI a bit, and you'd only be able to enforce one default rather than several UI presets for different audiences.

Should it go further? Should you have a general setting that applies content filters / default values for other filters on top of the tag filter? And then a select in the toolbar or sidebar to choose a preset?

Should such a preset be available in MDX so you could add <DevOnly>, <QAOnly>, etc. blocks in your MDX doc?

I suspect most of that can be achieved right now with an addon. The only difficult part would be negotiating what happens with the Storybook tag filter UI when you apply a preset.

---

It could also be a permanent filter that filters out which stories get included in the SB instance, and then you deploy different versions for general documentation and for testers.

In which case, would it differ from instrumenting your stories regex and separating tester/documentation stories? This is already achievable but maybe it's not clear how it can be done. It does involve a more complex deployment process, though.