Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tabs] Wrong tab selected when tab array changes #828

Open
vsaarinen opened this issue Aug 17, 2021 · 8 comments
Open

[tabs] Wrong tab selected when tab array changes #828

vsaarinen opened this issue Aug 17, 2021 · 8 comments

Comments

@vsaarinen
Copy link

vsaarinen commented Aug 17, 2021

🐛 Bug report

Current Behavior

I'm working an application where we use @reach/tabs to manage our tabs. The list of tabs can change—both in length and in the ordering of tabs—when the user is using the app. We're using the tabs in a controlled way, i.e. we provide an index and onChange to the Tabs component.

I'm currently seeing three issues:

  1. When I add a new tab to the end of tabs array and set the index to the last index in the array, the second-to-last tab is selected. When I add more tabs, the selected tab doesn't change. It seems to be set to the last element of the original array, before any additions.
  2. When I change the order of the tabs and keep the index constant, the tab that's selected is always the one that was selected before the order change instead of the one specified by the index.
  3. When I change the order of the tabs and try to keep the same tab selected as before, a random (?) tab is selected.

If I inspect the components, it seems that the right Tab component is receiving the isSelected = true prop, but the CSS styles are incorrect. If I unmount the component and remount it, the correct tab is shown.

Is this a bug or am I using the library incorrectly? Might this be caused by some sort of tab array caching and/or the caching of the CSS styles?

Expected behavior

I would expect the index number to select the right tab.

Reproducible example

CodeSandbox example

Suggested solution(s)

N/A

Additional context

N/A

Your environment

Software Name(s) Version
Reach Package @reach/tabs 0.16.1
React react 17.0.2
Browser Chrome 92.0.4515.131
Assistive tech N/A
Node node 14.17.5
npm/yarn yarn 1.22.10
Operating System MacOS 11.4
@vsaarinen vsaarinen changed the title Wrong tab selected when tab array changes [@reach/tabs] Wrong tab selected when tab array changes Aug 17, 2021
@vsaarinen vsaarinen changed the title [@reach/tabs] Wrong tab selected when tab array changes [tabs] Wrong tab selected when tab array changes Aug 17, 2021
@som-sm
Copy link

som-sm commented Aug 18, 2021

Another observation: Even if you just simply add a new tab without even updating the selected tab index, the selected tab automatically shifts one to the left.

@felixmosh
Copy link
Contributor

felixmosh commented Dec 16, 2021

And additional example of lazy loading tab.
https://codesandbox.io/s/react-tabs-lazy-load-bug-y14bb

Started at 0.16.1

@robinvdvleuten
Copy link

robinvdvleuten commented Dec 24, 2021

Same issue here! The default "selected" styling is applied to the newly added tab (without it being selected) and the index within the context is invalid.

@okjulian
Copy link

Can confirm this issue, I also ran into it. A quick and hacky solution would be adding a key to the Tabs component. That way you'll recreate the component every time you change the array of tabs. This may ir may not be an acceptable fix for you, depending on what you're building.

Forked and fixed the reproducible example: https://codesandbox.io/s/eager-nova-32edn?file=/src/App.tsx

@CodingDive
Copy link
Contributor

CodingDive commented Feb 8, 2022

I'm experiencing the same issue! I'm pretty sure it used to work just fine in prior versions so it must have been introduced in one of the last releases.

@felixmosh
Copy link
Contributor

Any update?

@jasikpark
Copy link

Using a key worked well for me!

@dayoolacodes
Copy link

Using a key worked well for me!

Thanks @jasikpark. using key worked for me too. I think this is a subtle bug that should be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants