feat(cdk-experimental/ui-patterns): tabs ui pattern#30568
feat(cdk-experimental/ui-patterns): tabs ui pattern#30568andrewseguin merged 1 commit intoangular:mainfrom ok7sai:ng-aria-tabs
Conversation
src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.css
Outdated
Show resolved
Hide resolved
| 'class': 'cdk-tabs', | ||
| }, | ||
| }) | ||
| export class CdkTabs { |
There was a problem hiding this comment.
I'm a little unsure about having CdkTabs as a necessary wrapper / container vs. the tabpanel having a reference/input for the tablist, implying a 1:1 relationship between tablist and tabpanel.
There was a problem hiding this comment.
I was going to include the decision making of choosing a top-level wrapper in the design doc for later. Here's a quick comparison.
Passing references
<ul cdkTablist>
<li cdkTab #tab1="tab">tab1</li>
<li cdkTab #tab2="tab">tab2</li>
</ul>
<div cdkTabpanel [for]="tab1"></div>
<div cdkTabpanel [for]="tab2"></div>
Note that the template variable referencing can be reversed. The only dealbreaker I can think of is the dynamic generated tabs or tabpanels via control flow may be impossible. Another downside is the templating effort of creating template references for general use case.
The wrapper solution on the other hand can support both implicit and explicit(yet implemented, but likely via a string identifier other than id) tab-tabpanel binding, which I think it's more intuitive. I also found the same pattern used in most similar libraries, so it can be familiar to developers as well.
There was a problem hiding this comment.
Yeah, I think we should probably have a discussion on the API(s) we expect an end-developer to define for their own tab implementations, and then how to best accommodate that with the directives. FWIW I think we will have a requirement that there may be elements between the tablist and the tabpanel(s).
For content, I suspect these directives will need to end up being oriented around rendering <ng-template> content.
| /** The required inputs to tabs. */ | ||
| export interface TabInputs extends ListNavigationItem, ListSelectionItem, ListFocusItem { | ||
| tablist: Signal<TablistPattern>; | ||
| tabpanel: Signal<TabpanelPattern>; |
There was a problem hiding this comment.
It seems odd to me that the tab would need to know about the tabpanel. I was imagining the relationship would be that the tabpanel only knows about the value of the tablist, not necessarily any of the specifics tabs
| } | ||
|
|
||
| /** A tabpanel associated with a tab. */ | ||
| export class TabpanelPattern { |
There was a problem hiding this comment.
This is probably a bigger conversation, but I wonder whether it makes sense to have a tabpanel pattern at all, since it doesn't actually do or render anything.
| 'class': 'cdk-tabs', | ||
| }, | ||
| }) | ||
| export class CdkTabs { |
There was a problem hiding this comment.
Yeah, I think we should probably have a discussion on the API(s) we expect an end-developer to define for their own tab implementations, and then how to best accommodate that with the directives. FWIW I think we will have a requirement that there may be elements between the tablist and the tabpanel(s).
For content, I suspect these directives will need to end up being oriented around rendering <ng-template> content.
src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.html
Outdated
Show resolved
Hide resolved
src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.html
Show resolved
Hide resolved
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
No description provided.