-
Notifications
You must be signed in to change notification settings - Fork 77
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
Enhancement: Add closable
functionality to calcite-tabs-title
#2620
Comments
Hello! XI Design would definitely have a need for this issue with the Knowledge Studio project we are working on. Prioritizing this would help many out! |
Just wanted to bump this requirement from the ArcGIS Knowledge Studio team again following our conversation with Adam T. yesterday. |
This was mentioned in a Community post as well: https://community.esri.com/t5/calcite-design-system-questions/calcite-tab-dismissible-closable/m-p/1238589#M278 |
Similar to the attribute table in web appbuilder, it would be a great feature to be able to add a tab containing the feature table of a loaded layer and then be able to remove the tab when the layer is removed from the map. |
@geospatialem @jcfranco - this is high-impact for Knowledge Studio and other teams and matches existing |
closable
functionality to calcite-tabs-title
Should consider with the efforts of #2721, anticipated for the May 2023 milestone. |
Quick question about behavior on this as we work out details. I would expect [closable] to be globally set, e.i. all tabs are closable or not-closable. This way we would avoid a confusing possible state of mixed closable and non-closable tabs. Does this thinking jive with expectations? |
I’d imagine it would be more flexible to set per tab. Perhaps the tabs represent tables or sheets, and the app has a minimum number to display, or for the same workflow, some tabs are locked due to permission (and denoted as such with icon-start/end). Those are just two use cases that come to mind but I’d expect some other similar needs. Some related questions: Should we consider allowing tabs to be re-ordered (log as separate enhancement). If tabs can be closed, we can imagine they may be used in workflows where users could reorder the representative tabs. |
Reallocating to the April milestone. |
@geospatialem, final designs are ready in the Figma enhancements folder and had a walkthrough chat today with Eliza. The Figma branch should get merged this week so designers can start playing with it. |
Yay! Thanks Aaron, we are looking forward to using this! |
Thanks for working on this! We are definitely glad to not have to custom roll this as an extended capability in Studio |
I have a lingering question regarding what happens when we close a tab. As in does closing tab 3 mean we get tab 4 selected (tab 4 contents displayed) after tab 3 and its contents are gone? Or do we let it refocus to default: tab 1 with its contents displayed? |
I'd expect the previous tab to be focused and open, similar to how closing a Sheet in Excel opens the previous Sheet and makes that Tab active (they don't have a close button, but you can right click to select from menu). For example if I close tab 4, tab 3 would be open / focus on tab title. This also follows how it is set up in upcoming Chip Group - if you close a chip, the previous chip gains focus. |
My expectation was for the next tab to be focused and opened rather than the previous, but I could see either way as long as we are consistent 👍🏽 |
Like how it was implemented on the Attribute table of the Web AppBuilder, if tab3 closes, then tab4 will be selected and show its contents. If tab 4 then tab3 will be selected. So, the tab to be closed, the tab to its right will get focus, if the rightmost tab closes then the tab to its left will be focused, and if the leftmost tab closes, the tab to its right will be focused, |
I think this is problematic when the closed tab is the last tab. And since we decided that the first tab cannot be closed if it's the last remaining one, the previous tab being focused makes more sense to me. This will simplify the logic or we'll have to swap direction at the edges. |
This feels like the correct approach with the best ux. See this video of Chrome tabs as a demonstration.
CleanShot.2023-03-30.at.08.04.59.mp4 |
Adding link to the final spec in Figma for reference. |
Migrating to the May release for implementation. |
…b-titles` (#6740) **Related Issue:** #2620 ## Summary `handleTabTitleClose` sequence is as follows: > if `closed` item is `selected`, fall back on the next > unless it's the last item, which falls back on previous > closing non-selected items doesn't affect the `selected` tab > last remaining item becomes `disabled`, if `closable` - Added `closed` property - Added `closable` property - Added `calciteInternalTabsClose` event - Added `calciteTabsClose` event - Added t9n messages for `Close` text. - Updated styling per new Figma specs - Added tests `handleTabTitleClose` keeps track of `visibleTabTitlesIndices` instead of having Dom queries filter out `hidden`. This helps to sync `tabs` with `tab-titles` using their corresponding `id`s set on the original render. `visibleTabIndeces` is an array of `id`s of the non-hidden `tab-titles`. When `tab-title` is `closed` this `id` is used to navigate to the next visible item. This makes figuring out what the next item should be when closing out of order is now more straightforward. Tests coverage for - simple closing behavior - closing sequence behavior: > - when closing `tab-titles` in sequence 1 (first selected) through 4, `tab-title` and corresponding `tab` become hidden, and selection fallback is the next tab > - reverse fallback: when closing `tab-titles` in sequence 4 (last selected) through 1, `tab-title` and corresponding `tab` become hidden, and selection fallback is the previous tab > - closing an unselected `tab-title` does not deselect the current selection > - 2 additional cases: works with a randomized closing sequence with mixed selected and not --------- Co-authored-by: Matt Driscoll <[email protected]> Co-authored-by: JC Franco <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Anveshreddy mekala <[email protected]> Co-authored-by: jona7150 <[email protected]> Co-authored-by: Kitty Hurley <[email protected]>
Verified on A follow-up issue will be created shortly to mitigate the high contrast color of the closable button. <!-- HTML structure -->
<calcite-tab-nav scale="m">
<calcite-tab-title selected closable tab="one">Tab 1 Title</calcite-tab-title>
<calcite-tab-title closed closable tab="two">Tab 2 Title</calcite-tab-title>
<calcite-tab-title closable tab="three">Tab 3 Title</calcite-tab-title>
</calcite-tab-nav>
</div>
<!-- JavaScript event -->
<script>
const tabNav = document.querySelector("calcite-tab-nav");
tabNav.addEventListener("calciteTabsClose", (evt) => {
console.log(evt.target.tab);
});
</script> |
Description
Add action button to the calcite-tab-title component to allow for closing tabs
*Obviously very rough implementation below
Acceptance Criteria
Include action button in tabs with custom icons and custom onClick event
Relevant Info
Which Component
calcite-tab-title
Example Use Case
Allow users to close opened tabs using the action button in the tab titles
The text was updated successfully, but these errors were encountered: