Salesforce Lightning Web Components – creating “lightning look and feel“ components

LWC User interface – how to build it?

The Lightning Web Components can be built in a few ways:

• using external libraries,
• using standard HTML tags,
• using standard LWC components,
  (https://developer.salesforce.com/docs/component-library/).

Each of the methods has pros and cons. External libraries are very extensive and include many various components. Unfortunately, not always they can be intuitively used in LWC. Also, they dictate a defined style and design.

Standard HTML tags are easy to use and fully compatible with LWC. The ease of use is both a merit and demerit because usually, it means a very limited application. The disadvantages include style, too. In turn, standard components – and especially their design – for sure will not be accepted in the project.

The best solution to build a user interface are components available in sources in a framework. Their list is quite long, and thanks to their possibilities, most of the project requirements can be met. We want to build a responsive form available by mobile, tablet, and desktop? No problem – use lightning-layout. The same effect can be achieved using other techniques, such as CSS and Flex. The question is: is to worth it? If we want to implement custom validation on fields, we can use lightning-input and setCustomValidity.

The big advantage of LWC components is their design. We get an interface consistent with the whole Salesforce platform as a standard. It only takes a bit of effort on our side – Salesforce developers – so that a user would not see the difference between working with standard forms and fully customized solutions.

Implementing a custom component – where to begin?

Though the LWC components library is big, not always we find there a solution that meets our expectations. It often happens that the available component meets our functional requirements but not visual needs. Unfortunately, shadow dom does not allow overwriting CSS. In such a case, we are forced to step on a lower level and implement a custom component.

Where to begin?  What guidelines to follow?

1. Since we write our own component, let it be reusable. Thanks to that, the extra work pays off when we use the component in the next projects.
2. We do not want to change the entire interface design, so our component must integrate into the current style of the look.
3. In the team, there are people who know LWC components and use them on a daily basis, so the API of our component should be fully compatible, both in the meaning of functionalities and naming.

Implementation of the custom component step by step

Our goal is to build a component of the lightning-select type. In the LWC library, its equivalent exists, lightning-combox. Its behavior and design are not always enough for the current needs.

Step one – building the HTML template

Fortunately, we do not have to start designing our components from scratch. Lightning Design System and Components Blueprint come with help (ttps://www.lightningdesignsystem.com/components/overview/).

This website displays HTML of all components of the LWC library and many more. What is more important, all the components are styled with classes available as standard inside LWC components.

Figure 1 – customSelect.html

The simplest layout can be created within a few minutes. We copy a template from the components blueprint. Then, we insert variables from the js module, connect the onchange maintenance, and add iteration on option. And we are done!

Step two – the js module

We add public variables to the module: label, options, and value. We also implement the handleChange method that creates the event named change.

The js module is as follows:

Figure 2 – the js module

Creating the simplest component of the select type takes 10 minutes maximum. The rest depends on the complexity of requirements.

Step three – the component extension

We want to add to the component the possibility of design management. At this point, it should be remembered to use good practices and the naming pattern consistent with the LWC library. And that is why we add public properties: variant. We also implement the management with the possible value: label-hidden. And the option of adding a default value.

Figure 3 – the HTML template

The js module:

Figure 4 – the js module

Setting variant = label-hidden causes displaying the same select component without a label. This behavior is identical to components available in the Lightning Web Components library. Adding the add-empty-value attribute results in adding the empty value to the available options.

The built component is not, of course, completed. The configuration management, reaction to the value changes, and validation should be added.

Building custom components is easy and brings many benefits – hopefully, I convinced you about it. I encourage you to remember about reusability when creating your own components and about consistency. Following these rules will bear fruits in future projects.