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.

[smlimasu]

@Sidnioulz these are important, elaborate thoughts and use cases you sketched here. Thanks. Initially, I just thought about it as a kind of reverse filter Tag in the tags menu where selecting a predefined Tag like "test-only" would add more content to the sidebar.

I know I can deploy different versions but I thought there might be a more convenient method.

The scenario to have different presets, just like an environment preset, but configurable by the user is an idea I like a lot and I would use that.

I imagine it perhaps like the version switcher button you have with refs, or some people have build as an addon. Or the theme switcher globals. When there was a global button, maybe in the toolbar or in the sidenav or sidenav config, that you could easily configure or add options in the manager based on globals, tags, filters, parameters, themes, languages or versions to serve different stakeholders needs that would be awesome. I think it's already possible but you would need to write your own addon/advanced globals for it. For some weeks, because I did not like some of those toggles being in the toolbar, I have inserted a second top nav bar like in the storybook docs to let users easily toggle different presets/modes/sections but nah, felt wrong. Isn't there this experimental sidenav_top for add-ons? I hesitated to use it atm and to be honest, I found the documentation for local add-ons is not extensive enough to just easily build some of these features without a headache.

So yeah, making it more easily for devs to address some of these use cases by providing more build in features/working addons without needing to deep dive into storybook mechanics and reinventing the wheel would be so great, I would try to contribute. But what and how exactly, that depends what other users need and what's feasible in the storybook teams pov and goals.