-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Ensure Tab
order stays consistent, and the currently active Tab
stays active
#1837
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
169e9c8
to
e58dd3c
Compare
This ensures that whenever you insert or delete tabs before the current tab, that the current tab stays active with the proper panel. To do this we had to start rendering the non-visible panels as well, but we used the `Hidden` component already which is position fixed and completely hidden so this should not break layouts where using flexbox or grid.
e58dd3c
to
9992f09
Compare
Hello @RobinMalfait my team is also encountering this issue, is there any plan for this to be released into a new version soon? |
@elco45 This should be fixed, and will be available in the next release. You can already try it using:
|
@RobinMalfait tried it out and that fixed the issue for us! Will be patiently waiting for the next release! Thanks |
This was necessary to ensure the `Panel` and the `Tab` were properly connected with eachother because it could happen that the `Tab` renders but the corresponding `Panel` is not the active one which means that it didn't have a DOM node and no `id` attached. Whenever new `Tab` became active, it rerendered but the `Panel` wasn't available yet, after that the `Panel` rendered and an `id` was available but the actual `Tab` was already rendered so there was no link between them. We then forced a re-render because now the `Panel` does have a DOM node ref attached and the `aria-labelledby` could be filled in. However, in #1837 we fixed an issue where the order of `Tab` elements with their corresponding `Panel` elements weren't always correct. To fix this we ensured that the `Panel` always rendered a `<Hidden />` component which means that a DOM node is always available. This now means that we can get rid of the `forceRerender`.
* remove `forceRerender` code This was necessary to ensure the `Panel` and the `Tab` were properly connected with eachother because it could happen that the `Tab` renders but the corresponding `Panel` is not the active one which means that it didn't have a DOM node and no `id` attached. Whenever new `Tab` became active, it rerendered but the `Panel` wasn't available yet, after that the `Panel` rendered and an `id` was available but the actual `Tab` was already rendered so there was no link between them. We then forced a re-render because now the `Panel` does have a DOM node ref attached and the `aria-labelledby` could be filled in. However, in #1837 we fixed an issue where the order of `Tab` elements with their corresponding `Panel` elements weren't always correct. To fix this we ensured that the `Panel` always rendered a `<Hidden />` component which means that a DOM node is always available. This now means that we can get rid of the `forceRerender`. * update changelog
This ensures that whenever you insert or delete tabs before the current
tab, that the current tab stays active with the proper panel.
To do this we had to start rendering the non-visible panels as well, but
we used the
Hidden
component already which is position fixed andcompletely hidden so this should not break layouts where using flexbox
or grid.
Fixes: #1834