feat(Tabs): add unstable_Tabs component

[emyarod]

Closes #6798
Ref #4758

This PR restores the dropdown tabs and moves the new mobile Tabs variation to the unstable_Tabs component

Changed

• converted fragment to namespaced div in Tabs and unstable_Tabs. This saves us the trouble of renaming classes individually and only requires us to remove the added parent class in our stylesheet, once the scrolling tabs variant replaces the default. The div can be reverted to a fragment at that time as well

Testing / Reviewing

Ensure the dropdown tabs and new mobile tabs appear and function correctly

[netlify]

Deploy preview for carbon-elements ready!

Built with commit 79616df

https://deploy-preview-6803--carbon-elements.netlify.app

[netlify]

Deploy preview for carbon-components-react ready!

Built with commit 79616df

https://deploy-preview-6803--carbon-components-react.netlify.app

[tw15egan]

Do we need to enable a feature flag to get the styles to render properly? Figured if it was under the unstable naming convention it would work similarly to unstable_Pagination

[joshblack]

Could we add the mobile tabs version as a variation instead of it being experimental? Was looking at this real quick and was wondering if the changes were one such that we could support both or not 🤔

[emyarod]

I don't think the unstable_Pagination requires a feature flag to render properly, I forgot to add the unstable tab styles to the PR

is it worth adding a variation if the dropdown tabs are going to be removed? we would just be adding a prop to render a whole new component, just within the Tabs file itself instead of in a separate unstable_Tabs component

[joshblack]

I think the idea is to try and figure out how to ship Tabs under stable while still supporting downstream component libraries (which I believe is who made the parent issue).

In the React component, we could have the default tabs class name be the new variant and then other teams could still use the old class names. In v11, we'd have them be aliases of each other.

[emyarod]

the new variant is technically a breaking change though right? that's why I thought it made sense to roll back to the dropdown variant until v11 and release the new variant as unstable

[joshblack]

@emyarod I think the breaking change would be for consumers of Carbon styles if we changed ones like bx--tabs, for example the Angular or Vue teams. I think for teams using the React component it should be semver-compatible, at least in terms of API, let me know if I'm missing something here 👀

[emyarod]

I see, so what should we do in that case where it's not a breaking change for React but it will be breaking for Carbon implementations in other frameworks?

[joshblack]

@emyarod this is where I was asking if we could have an alternate class name that we use by default inTabs that other teams could then use to build to the newer version. This might not be possible in this case, let me know if so, but would be ideal if we could keep bx--tabs and have a variant like bx--tabs--<name> that we ship by default and use that as the handle for any style differences at the container level or tab level. This way bx--tabs keeps working as expected but teams could build towards bx--tabs--<name> before we have bx--tabs and bx--tabs--<name> be the same in v11

[emyarod]

if this is just about avoiding the unstable_ prefix, we can make it a separate ScrollingTabs component until it replaces the default tabs. currently we are just name spacing it behind bx--tabs--unstable rather than bx--tabs--<name> (but I really do think this is unstable)

this is technically a breaking change since we are also changing the Tab (not Tabs) and TabContent and TabSkeleton styles as well, so I guess we would have to modify those classes as well?

[joshblack]

Yeah, I think the ideal would be that we don't have unstable for the Tab functionality that was added in since we shipped it as stable in the last release, right? If not let me know, I may be misunderstanding the issue.

It'd be great if we could have an adapter for this under bx--tabs--scroll or something similar that reproduces the stable behavior that we shipped while reverting bx--tabs to the original implementation. The Tabs component that we ship can use bx--tabs--scroll but with bx--tabs being changed back no library teams should be impacted.

Let me know what you think 👀

[emyarod]

ok I see this change will be pretty involved to make sure no regressions are introduced. after adding this backwards compatibility we just need to make sure to remove it in the next major version

[emyarod]

opened #6928 if we prefer to go that route, not sure if it's as clean or if it contains any regressions compared to this PR but let me know what you think

[emyarod]

closing in favor of #6928