[RFC] Remove addon "tab" type

[Sidnioulz]

Summary

In a distant past, Storybook used to have a global tab bar at the top of the screen, allowing users to switch between Docs pages and stories. Storybook stopped using this internally by moving Docs pages to the sidebar, but the panel feature remains under the hood for addon authors.

This RFC proposes to remove the addon panel type altogether, to simplify UI maintenance and WCAG compliance.

Problem Statement

The fact that a tabbar exists in this part of the UI is problematic. To make Storybook more accessible, we want to implement a proper toolbar pattern for the top toolbar, and tablist patterns where we have tablists.

Having a UI element where both the toolbar tools and navigation tabs intersect makes it particularly hard to provide a coherent keyboard navigation pattern. We either have to present tools before tabs, even though the tools available in the toolbar depend on the current tab, or leave tools between the tablist and tabpanel, breaking the expected keyboard navigation pattern.

Removing the ability to create new tabs would solve this UI dilemma.

Addon authors would have to port their tabs to another UI mechanism. Decorators would allow addon authors to reimplement their own tab structures if they so desired.
Existing and planned layout customisations would allow addon authors to control what tools and UI elements appear in their tabs, which means they'd have good control over the final UI output of their addons.

A11Y Resources

• https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
• https://adrianroselli.com/2013/02/aria-tabs.html
• https://web.archive.org/web/20130208024627/http://www.marcozehe.de/2013/02/02/advanced-aria-tip-1-tabs-in-web-apps/

Non-goals

No response

Implementation

In Storybook 10

• Deprecate the tab type from the addon registration API

In Storybook 11

• Remove the tab type from the addon registration API
• Remove tabs from the manager preview toolbar

Prior Art

No response

Deliverables

No response

Risks

If we don't provide alternatives for addon authors who have a legitimate need for full page views, this may blow back. A decorator could be provided that uses local parameters to switch between the actual story and a custom view.

Unresolved Questions

• Decide what shape an equivalent feature would take for the few addon authors still using tabs

Alternatives considered / Abandoned Ideas

We've considered preserving the tabs feature with the current UI, but making it compatible with the DOM structure we need for accessibility will be hard. We'd end up having to use JS to absolutely position tabs where they exist and dynamically reserve space for them in the toolbar. That UI code would be prone to breaking.

We could also consider other UI forms (e.g. two bars) but the team so far prefers to remove tabs altogether.

[Sidnioulz]

We've internally discussed this and lean towards deprecating the tab type now and remove it entirely in Storybook 11. Speak up now if you disagree :D

[tomdaly]

hey @Sidnioulz 👋 at zeroheight we've developed a Storybook addon that shows design system documentation in a tab, alongside a component (see our docs for more info).

removing tabs in Storybook 11 will mean that our addon no longer works as intended. we're on board with the accessibility and maintenance improvements that result from this change, but the lack of alternatives here might lead addon authors to develop solutions that create an inconsistent UI (or result in addons re-implementing tabs, which goes against the original goal of this RFC).

do you have any recommended alternatives for addons that use tabs?

[Sidnioulz]

Hi @tomdaly, thanks for giving us a use case to mull over!

(cc. @MichaelArestad this could be one example of custom view mode in future Tree iterations)

My suggested workarounds would depend on whether you show the tab with docs pages, or with individual stories.

---

For docs pages, I'd suggest an autodocs template that provides the original data structure in a tab, and your doc pages in other tabs. I think you could do that by writing your own JSX component that acts as a wrapper/decorator to the rest of the autodocs content.

export const parameters = {
    docs: {
      page: () => (
        <ZeroHeightTabsWrapper>
          <Title />
          <Subtitle />
          <Description />
          <Primary />
          <Controls />
          <Stories />
        </ZeroHeightTabsWrapper>
      ),
    },
  },
};

If you run into a blocker attempting this, feel free to provide feedback on how we can improve the template API to support you.

---

If you want to provide the docs for stories, I'd suggest using a toolbar button that, when clicked, opens a full screen modal. I wouldn't suggest a decorator as it will interference with component tests.

[tomdaly]

@Sidnioulz this is really helpful, thank you! these workarounds seem feasible. if we run into any problems implementing a solution, I'll reach out again :)

[Sidnioulz]

Glad to hear! Do let me know how it goes. If you or your users find it inconvenient to have to redefine the whole template (rather than wrap around it), feel free to check for / open an issue on that as well.

[MichaelArestad]

I'm considering some custom view modes and this feels like a potential solid use case for some ideas I have cooking. I would love to chat and work through ideas. Feel free to reach out on Discord or LinkedIn if you have the time and are interested in a quick feedback session.