Picklists are one of those components which are quite extensively used during Salesforce customization. Even I happened to come across the same requirement recently and as always, I went to the component library and keyed in ‘Select’ in the quick find hoping to find an in-built LWC component only to find nothing in the search results. I was so surprised to not find one considering the extensiveness of its usage. This in fact gave me an opportunity to come up with something of my own. Nevertheless, once I started, I realized I could customize it and make it more generic to handle the following scenarios:
- Make the select component independent and let it fetch all the picklist values on its own by just providing the object and the field name.
- Extend it further to handle the dependent picklists
- Also make it configurable to support multi-select picklists.
I am pretty sure the scenarios mentioned above are quite common in many of the business requirements. Considering that, this component would come in handy to many out there. In this post, I will discuss how I handled each scenario in detail with code samples.
If you think going through the whole post is painful and you are in a hurry to get quick access to the code, jump to the Github link provided at the end of the post ;-)

Simple dynamic picklist component
Even before we jump into the implementation, let us first understand the meaning of the title. A simple picklist component can be defined as one which is capable of fetching the picklist values of any field from any object in Salesforce. It is dynamic in the sense that the object and field name are specified as strings on the component and it only gets loaded on the fly during component rendering. The component would look like below(Similar to the standard picklist component):

Just like any other LWC component, this makes use of only the component markup and the component javascript and an Apex controller to achieve its purpose.
The Component markup
The component markup mainly consists of the following elements:
- Label to display the picklist label with a capability of displaying a ‘*’ if mandatory. Another unique thing about this component is it also fetches the field label on its own given the field API name.
- A html select element to display the options with a default ‘select’ option. This element can be marked ‘disabled/enabled’/’required’ based on conditions.
The component markup is as below:
The component javascript
The javascript consists of mostly few reactive fields bound to elements in html and calls to apex controllers as explained below:
- Fields:
- Fields which store the picklist options fetched from controllers.
- Fields which hold the required status.
- Fields that hold the enabled disabled status.
- Fields that are exposed to set the object & the field names
2. ConnectedCallback() lifecycle hook which invokes the picklist value fetching API and the label for the given field
3. Selection changed handler which raises an event ‘selected’ whenever the picklist value selection changes.
The class code looks like the following:
The Apex controller:
The apex controller holds code only to fetch the picklist values and the field label value from the API name. This is an optional part of the component based on which object the component is used on. If the component is used on objects that are supported by Lightning data service, then we could simply use the ui*api LDS calls. The component code is as follows:
Advantages
By designing the component as above we get the following benefits:
- Currently the component uses Apex controllers to fetch picklist values, but once Lightning Data Services start supporting all the objects we could switch to ui*api calls without any change in the parent component code.
- A lot of redundant code can be avoided in the parent component if it is expected to display
- This base component can be extended further to support dependent picklist and multi-select picklist components.
This component will be extended further in the coming days and the updates will be explained in the next few sections of the current series.
Dependent picklist component
Let us delve into the second enhancement of the picklist component. If you have been using picklists a lot, you will surely feel the need for it. In my experience, a dependent picklist would rather come more handy. Dependent picklists are picklists whose options are dependent on the value selected in another picklist. Let us refer to the other picklist as the controlling picklist and the value selected as ‘ControllingFieldValue’ in our discussions. The implementation changes as below:
The component markup
There are no changes to be done in the markup since the looks of the component remain the same for this use case.
The component javascript
The following changes are needed in the javascript for handling this scenario:
- A new field named ‘controllingFieldName’ which corresponds to the API name of the field ‘fieldName’ is dependent on. This field decides if the picklist is independent or dependent.
- A new filed named ‘contrFieldValue’ which holds the value of the controlling field.
- Add a conditional block in ‘connectedCallback()’ to invoke the Apex controller method to fetch all combinations of picklist dependencies beforehand.
- A public getter named ‘controllingFieldValue’ adorned with ‘@api’ decotator.
- A setter named ‘controllingFieldValue’ which sets the options based on the value set on the dependent picklist.
The code changes are as below:
The Apex Controller
The Apex controller just introduces another method to fetch all the dependent values between the controlling and the dependent picklists.
Usage
The Usage is as below
<c-select-component object-name="Task" field-name="Field1"
controlling-field-name="Field2"
controlling-field-value={controllingFieldValue}
label="Dependent Picklist"></c-select-component>Multi-select picklist component
The implementation of the multi-select component took more time and efforts than expected and it turned out to be more trickier than I initially thought. Unfortunately there is nothing much that can be used from the out-of-box picklist component. Nevertheless, I was still able to achieve what I set out for in the end. When you think of multi-select picklists, you can think of the following requirements:
- Should be able to select multiple options.
- The items selected should be displayed as comma separated list.
Of course there are a couple more that could be added to the list, but for simplicity sake let us address the above 2 requirements in the discussions to follow. I would not be adding the code for this here since the readability would be completely lost. However, you could still find the complete implementation on my Github repository.
The component markup
The implementation requires you to create a picklist component from scratch and customize it further to support multi-select. Since there is not much of common code between the previous and the current implementation, I had to do a conditional rendering of the markup based on the value of the flag ‘isMultiSelect’. The markup for the multi-select consists of the following:
- A button that simulates the picklist component providing a way to open the popup on the click of the component. This further consists to 2 children. A label to display the options selected and a drop down icon like in any other picklist.
- An unordered list which stores the items of the picklist with each item containing a checkbox and a label. This is embedded in a <div></div> and acts as the pop up component of the picklist.
- The mouse enter/ mouse leave events are tracked to open the popup whenever there is a mouse movement over the picklist component.
The component javascript
The javascript adds a couple of more methods to handle the multi-select scenarios. The once of significance are the following:
- A Boolean variable indicating whether or not the mouse is over the component.
- The mouse event handlers like mouseEnter, mouseLeave, mouseClick. These handlers mainly set or reset a boolean value indicating if the mouse is over the component or not.
- Few getters which return the class value that is to be set on the containers hosting the whole component.
- A variable which indicates how many items are to be displayed in the picklist without a scroll bar.
- Checkbox Selection change handler which is responsible for displaying the selected items in the picklist.
Every time an item is selected/unselected, the selection change handler takes care of coming up with a list of items that are selected and displays them as a list of items separated by a comma.
That brings us to the end of the customization of picklist components in LWC. You can find the entire code in my Github repository.This implementation is a simple yet very useful customization on picklists. Salesforce might come up with a component of its own someday in future. But till then, this component will come handy.