As user interfaces (UI) go, tabs are a particularly useful pattern. The word “tab” invokes images of beige manila file folders. Early UI mimicked this physical property by placing buttons along the top of a dedicated space. Mobile devices, with their confined spaces, find the tab pattern in accordions, bottom button bars, and more.<\/p>\n
In this example, we will look at the mechanics of building a tab component using Stencil<\/a>.<\/p>\n <\/p>\n Let us talk for a moment about composition. How does a component magically grow a tab? In Web Components parlance, composition refers to the idea that a component can have other HTML elements, including components, inside of the opening and closing tags. What the parent component does with that content is up to it.<\/p>\n Given the above HTML snippet, in the case of a tab component, we would expect to have something like three buttons, each controlling the visibility of one child element at a time. Believe it or not, there is almost enough information here to make that happen. The only piece of information missing is what to label the buttons.<\/p>\n One of the great features of HTML is how extensible it can be. One of the ways that HTML accomplishes this is through the use of data attributes. Data attributes have this name because you can use the word “data” followed by a hyphen, and then whatever word you want to use. As an attribute, like many other defined HTML element attributes, a data attribute can also be assigned a value.<\/p>\n \n A data attribute does not have to be assigned a value, in which case, it will be treated as a To work with data attributes from JavaScript, we have a few functions at our disposal. If the data attribute contains a value, we can use From a markup perspective, this is enough to generate, and label, the buttons that control the visible content.<\/p>\n In the above markup, we are considering any child element to be representative of a piece of content whose visibility is controlled by a button, which is called a “tab” by convention. We have already decided that a tab has a label, but there are other properties to consider as well.<\/p>\n The first additional property would be if the tab is selected or not. This is important not only internally, to hide content that is not selected, but also for the purposes of styling. A selected tab should have a different appearance than a tab that is not selected.<\/p>\n A selected tab should also look different from a disabled tab… Disabled… There is another property! Depending on the state of the application using the tabs, we may also want to disable specific tabs.<\/p>\n Closely related to disabled is visibility, which we can consider another property of a tab. Your tabs might have icons, which could be considered another property of the tab. Maybe you want the ability to “pin” tabs. Whatever properties you find relevant to your tab implementation, bundle them up into a class. This class will allow us to refer logically to each tab and its related properties.<\/p>\n Now we have a good grasp of the markup that should represent our tab component, and we even have a logical representation of the individual tabs. Now we will turn to the implementation itself, starting with the component properties.<\/p>\n In order to get access to the child elements (composed content), we will need a reference to the web component element itself. This is called the “host element” in Stencil. From a web component standards perspective We will also want the component to keep track of the state of the tabs, which means an \n From an object-oriented programming perspective Our component will also need to keep track of the selected tab. To keep things easy, we can use a zero-based index to represent selection.<\/p>\n The selected index will change when a tab is clicked. When a component modifies one of its properties directly, it must be marked as Inside of a web component template, the When the elements inside of a web component slot are changed, the component emits an internal Within the tab component template, we need two distinct areas – one to hold the buttons which represent the tabs themselves, and one to hold the desired content to be rendered.<\/p>\n When a tab button is clicked, the index of the selected button is assigned to the As for the Up to this point, we have put a lot of focus on the buttons that represent the tabs of our component. We still have one last concern – the visibility of the content within our tab component. We want to make sure that the visible content stays in sync with the buttons that control that visibility. The best place to do this is a quick check-in the It might seem odd that assigning or removing a And with that, our tab component is complete! \ud83c\udf89<\/p>\n The component itself is not that complex, but it does involve taking into account just about every aspect of building web components. You need to understand composable content, how that translates into slots inside of components, and then how that can be managed in CSS. You need to understand the lifecycle of a web component with Unordered List<\/strong><\/p>\n I display the tab buttons as In this case, I am taking advantage of a special behavior of the You might then in turn suggest putting a Logical Tabs<\/strong><\/p>\n In this example, we used a However, a case can be made for going the other way as well – formalizing a Ionic Framework<\/a> takes this approach. In fact, because of the myriad situations in which a truly generic tab component may be used, Ionic Framework actually breaks the structure down even further.<\/p>\n This is good for Ionic Framework, but this example is not teaching how to use Ionic Framework tabs. Rather this example is about how to implement the baseline tab UI pattern for your own components. For this reason, I kept this example as spartan as possible.<\/p>\n Now that you have an understanding of all the moving parts of this pattern, maybe you will want to layer in some abstractions of your own. Maybe you will go the declarative route and add specific components for the tab buttons. Or perhaps you might decide to allow the developer to specify a renderer to use for those buttons. Maybe you will add animation between the tab contents. Maybe you will implement an accordion rather than tabs.<\/p>\n Once you get the hang of the pattern, you will find uses for it in many places. The complete code for this example is in GitHub<\/a>, and there is a live demo<\/a> you can view as well.<\/p>\n","protected":false},"excerpt":{"rendered":" As user interfaces (UI) go, tabs are a particularly useful pattern. The word “tab” invokes images of beige manila file folders. Early UI mimicked this physical property by placing buttons along the top of a dedicated space. Mobile devices, with their confined spaces, find the tab pattern in accordions, bottom button bars, and more. In […]<\/p>\n","protected":false},"author":85,"featured_media":3801,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"publish_to_discourse":"1","publish_post_category":"21","wpdc_auto_publish_overridden":"","wpdc_topic_tags":"","wpdc_pin_topic":"","wpdc_pin_until":"","discourse_post_id":"530324","discourse_permalink":"https:\/\/forum.ionicframework.com\/t\/building-with-stencil-tabs\/213633","wpdc_publishing_response":"","wpdc_publishing_error":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[223,124],"tags":[140,76,82],"class_list":["post-3800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-stencil","category-tutorials","tag-design-systems","tag-stencil","tag-web-components"],"acf":[],"yoast_head":"\nComposition<\/h2>\n
<ionx-tabs>\n <p>Content 1<\/p>\n <p>Content 2<\/p>\n <p>Content 3<\/p>\n<\/ionx-tabs>\n<\/code><\/pre>\nData Attributes<\/h2>\n
<ionx-tabs>\n <p data-label="One">Content 1<\/p>\n <p data-label="Two">Content 2<\/p>\n <p data-label="Three">Content 3<\/p> \n<\/ionx-tabs>\n<\/code><\/pre>\nboolean<\/code> value. CSS can also be applied using the CSS attribute selector such as input[type=text] { ... }<\/code>. We will circle back to both of these concepts later in this example.<\/p><\/blockquote>\ngetAttribute()<\/code> to get that value. Conversely, we can use setAttribute()<\/code> to set that value. If we do not want the data attribute to be present, we can use removeAttribute()<\/code>. In the case of a boolean<\/code> value, we want to check if the attribute is present (true) or not (false). For this we can use hasAttribute()<\/code>.<\/p>\nWhat Is A Tab?<\/h2>\n
export default class Tab {\n disabled: boolean = false;\n label: string;\n selected: boolean;\n\n constructor( \n label: string, \n selected: boolean = false, \n disabled: boolean = false\n ) {\n this.label = label;\n this.selected = selected;\n this.disabled = disabled;\n }\n}\n<\/code><\/pre>\nComponent Properties<\/h2>\n
this<\/code> is the same as the host element. To get a reference to this host element in Stencil, the @Element()<\/code> decorator is used. You can name the property whatever you want, but convention is “host”.<\/p>\n@Element() host: HTMLElement;\n<\/code><\/pre>\nArray<\/code> of Tabs<\/code>.<\/p>\n@State() tabs: Array<Tab> = [];\n<\/code><\/pre>\ntabs<\/code> is a property of the component class. From a component perspective, it represents the state of the tabs, and is decorated appropriately. This is not to be confused with the properties decorated with @Prop()<\/code>. These are properties, too, but are decorated to control how the component manifests itself to the developer.<\/p><\/blockquote>\n@Prop( {mutable: true, reflected: true} ) selectedIndex: number = 0;\n<\/code><\/pre>\nmutable<\/code>. We will also want to let the developer programmatically control the selected tab, as well as determine which tab is selected. Both of these purposes are served by marking a property as reflected<\/code>.<\/p>\nSlots<\/h3>\n
slot<\/code> tag allows us to specify where child content should go within the context of the overall layout of the component itself. If you need to specify more than one designated area for child content, you can name the slots, and then use those names on the child elements. If you choose not to have a slot<\/code> tag at all, then the child content will not be shown.<\/p>\n<!-- In a component template -->\n<button>My Button<\/button>\n<slot name="label"><\/slot>\n<div>\n <slot name="content"><\/slot>\n<\/div>\n\n<!-- In your HTML -->\n<my-component>\n <p slot="label">My Label<\/p>\n <img slot="content" src="\/img\/stencil.svg" \/>\n<\/my-component>\n<\/code><\/pre>\nSlot Change<\/h2>\n
slotchange<\/code> event. Capturing this event allows a web component to take any special actions it needs to address the change. In the case of a tab control, we can leverage this event to know the component needs to evaluate the child content, and may in turn need to update the buttons representing the tabs.<\/p>\nTemplate<\/h2>\n
render() {\n return ( [\n <div>\n {this.tabs.map( ( tab: Tab, index: number ) =>\n <button\n onClick={() => this.selectedIndex = index}\n {... {\n 'data-selected': tab.selected,\n 'disabled': tab.disabled\n }}\n title={tab.label}>\n {tab.label}\n <\/button>\n ) }\n <\/div>,\n <div>\n <slot onSlotchange={() => this.doSlotChange()}><\/slot>\n <\/div> \n ] );\n}\n<\/code><\/pre>\nselectedIndex<\/code> property. This will invoke a render. True to form, and in sticking with the data attributes, if a tab is selected, it will have the data-selected<\/code> attribute. This is then picked up in the CSS to style the button accordingly. The same is true for any disabled tab, in which case the button gets a disabled<\/code> attribute.<\/p>\nbutton[data-selected] {\n background-color: #f4f4f4;\n border-left: solid 1px transparent;\n border-top: solid 2px #0f62fe;\n color: #161616;\n font-weight: 600;\n}\n\nbutton[disabled] {\n background-color: #c6c6c6;\n color: #8d8d8d;\n cursor: not-allowed;\n}\n<\/code><\/pre>\ndiv<\/code> holding the content (via a slot<\/code>), when the slotchange<\/code> event is fired, the doSlotChange()<\/code> handler is called. The doSlotChange()<\/code> handler evaluates the child elements and populates the tabs<\/code> property accordingly. When the tabs<\/code> property is changed, a render is invoked.<\/p>\ndoSlotChange() {\n this.tabs = [];\n\n for( let c: number = 0; c < this.host.children.length; c++ ) {\n const label: string = this.host.children[c].getAttribute( 'data-label' );\n const selected: boolean = this.selectedIndex === c ? true : false;\n const disabled: boolean = this.host.children[c].hasAttribute( 'data-disabled' );\n this.tabs.push( new Tab( label, selected, disabled ) ); \n }\n}\n<\/code><\/pre>\nRender<\/h2>\n
componentWillRender()<\/code> lifecycle function.<\/p>\ncomponentWillRender() {\n for( let t: number = 0; t < this.tabs.length; t++ ) {\n if( t === this.selectedIndex ) {\n this.host.children[t].setAttribute( 'data-selected', '' );\n this.tabs[t].selected = true;\n } else {\n this.host.children[t].removeAttribute( 'data-selected' );\n this.tabs[t].selected = false;\n }\n }\n}\n<\/code><\/pre>\ndata-selected<\/code> attribute on the children elements is what controls their visibility. This happens because within the context of web components, CSS has the ::slotted()<\/code> selector which allows you to target specific elements within a slot<\/code>. In this case, any child element that does not have the data-selected<\/code> attribute is hidden.<\/p>\n::slotted( :not( [data-selected] ) ) {\n display: none;\n}\n<\/code><\/pre>\nslotchange<\/code> and componentWillRender()<\/code>. And you need to understand how we can extend HTML using data attributes, and they can be used in CSS. And now? You do!<\/p>\n\u270b But What About …<\/h2>\n
button<\/code> elements inside of a div<\/code> container element. Since the tabs represent a list of options, the ul<\/code> element may seem like a better fit. If you had no other function in your tabs save to label content, then the ul<\/code> element would certainly be a good choice.<\/p>\nbutton<\/code> element in that it already has a disabled<\/code> attribute. When the disabled<\/code> attribute is present, the button does not emit a click event. Using the button<\/code> element means I do not have to write additional code to manage the event listener.<\/p>\nbutton<\/code> element inside the li<\/code> element as part of a ul<\/code> element. At this point, I would suggest we are splitting semantic hairs on content that is hidden in the shadow DOM in the first place.<\/p>\nTab<\/code> class to hold the properties that are related to what a tab should represent. If I were using plain JavaScript, and not TypeScript, then I would not even bother making the class in the first place, and just keep an Array<\/code> of Object<\/code>.<\/p>\nTab<\/code> component, perhaps using it as the container.<\/p>\n<my-tabs>\n <my-tab label="One">\n <p>Content 1<\/p>\n <\/my-tab>\n <my-tab label="Two">\n <p>Content 2<\/p>\n <\/my-tab>\n <my-tab label="Three" disabled>\n <p>Content 3<\/p>\n <\/my-tab> \n<\/my-tabs>\n<\/code><\/pre>\nNext Steps<\/h2>\n