- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 449
Open
Description
Hello,
I am using react-tabs with with success in my app.
In some places though, I use it with no panel at all. In that case, it is used to change a property on another component.
Stripped down example to illustrate:
const [page, setPage] = useState(0);
<Tabs selectedIndex={page} onSelect={setPage}>
<TabList>{ /* one Tab per page here */ }</TabList>
</Tab>
<DocumentView url={url} page={page} />
This works perfectly.
However, react-tabs complains that
There should be an equal number of 'Tab' and 'TabPanel' in
Tabs
It then continues happily and everything works fine.
- Do you see any issue with this use case?
- If not, would it be possible to silence that warning when the number of
TabPanel
s is exactly 0?
katiemcculloch, WisetrackPeru, ozanturhan, oguzzkilic, savasozcan and 2 more
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
add usePanel prop for tabs component
add usePanel prop for tabs component
joepvl commentedon Mar 10, 2022
This would add more surface to the API, only to support a use case that was obviously not intended to be supported. (And in my personal opinion does not make sense.)
As an alternative, maybe we should allow the use of
TabList
outside ofTabs
instead? Perhaps export a standalone variant ofTabList
that takesselectedIndex
andonSelect
props.Although, to be honest, I don't see a meaningful advantage over adding your desired behaviour to
<ul><li></li></ul>
, akin to my comment in the fleetdm/fleet issue that references this issue.spectras commentedon Mar 10, 2022
It sure would add more surface to the API, so the concern of whether it adds value makes sense.
The value in my case - and also it seems on the issue you linked - does not come from instantiating a bunch of
<ul>
and<li>
s but from the user interactions.If all the UX logic was exported as a set of react hooks, then yes I would have a bunch of
<ul>
and<li>
s and apply UX logic through hooks. That would indeed be much better from a design perspective.