While many base components use slots to display content, some require you to pass configuration information and data to an attribute on a base component. Let’s compare these two different approaches below.
For simple and maintainable code, we recommend using slots. For more information about slots, see Pass Markup to a Base Component Slot.
Note
Attributes enable you to configure the base component to achieve specific behaviors. Base components that use the attributes pattern result in a flatter structure in the template. For example, you use the lightning-map base component like this. Notice that the map-markers attribute takes in the map configuration information.
1<template>
2 <lightning-map map-markers={mapMarkers}> </lightning-map>
3</template>However, using the attributes pattern in some cases can lead to complex code. For example, if lightning-button-group uses an attribute to pass in button configuration information, your code can be hard to read and maintain. In this case, you pass in the configuration information to the lightning-button-group component. And you pass the data and metadata for each button in the group as an object. Finally, you pass an array of these objects into an attribute on the button group component.
1// Don't do this
2config = [
3 {
4 label: "Refresh",
5 },
6 {
7 label: "Edit",
8 },
9 {
10 label: "Save",
11 iconName: "utility:save",
12 iconPosition: "end"
13 },
14 { label: "Edit" }
15 {
16 type: "button-menu",
17 iconName: "utility:down"
18 items: [
19 ...
20 ]
21 }
22 ]Since there are many base components that are button-based, such as the lightning-button-icon-stateful and lightning-button-stateful, the attribute for the configuration information must support that and its metadata as well. This can increase code complexity and impact code readability. That’s why lightning-button-group and many other base components uses the composition structure instead.
Using an attribute can be helpful in certain cases, as shown by base components such as lightning-checkbox-group and lightning-select. Generally, consider using an attribute if you want:
Rendering native HTML inline can provide a performance boost, especially if you want to render the same element many times within a base component.
The lightning-select base component uses the <select> element and iteratively renders each option based on the configuration you provide. The base component internal markup looks like this, shortened for brevity.
1<!-- lightning-select -->
2<!-- For demonstrative purposes -->
3<div class="slds-form-element__control">
4 <div class="slds-select_container">
5 <select
6 autocomplete={autocomplete}
7 class="slds-select"
8 disabled={disabled}
9 id="select"
10 multiple={multiple}
11 name={name}
12 onblur={handleBlur}
13 onchange={handleChange}
14 onfocus={handleFocus}
15 required={required}
16 accesskey={accessKey}
17 size={size}
18 aria-invalid={computedAriaInvalid}
19 part="select">
20 <template for:each={options} for:item="option">
21 <template if:true={option.disabled}>
22 <option disabled key={option.value} value={option.value}>{option.label}</option>
23 </template>
24 <template if:false={option.disabled}>
25 <option key={option.value} value={option.value}>{option.label}</option>
26 </template>
27 </template>
28 </select>
29 </div>
30</div>Base components’ internal markup is for demonstrative purposes only. The markup is an internal implementation that can change anytime.
Note
When you use lightning-select in your custom component, the base component renders this markup in the DOM.
1<select class="slds-select" id="select-3" name="tickets" part="select">
2 <option value="">choose quantity...</option>
3 <option value="1">one</option>
4 <option value="2">two</option>
5 <option value="3">three</option>
6</select>In this case, providing an attribute for passing in configuration information and data allows developers to work with a flatter component surface.
See Also
Release Preview
j