Introducing Lightning Web Components (LWC)
Earlier Web Stack & Frameworks
Until recently, web standards only offered a limited foundation for the full stack that developers need to build large scale web applications. They had a few shortcomings – rendering wasn't optimized, creation of custom elements was difficult, and core language lacked modern constructs to write large, modular enterprise-class client-side apps.
In 2014, Salesforce launched the Lightning Component Framework along with the Aura programming model to enable large scale client-side application development on the web. This framework came with both its own component model and its own modular programming model. With this, came a number of challenges – React, Angular, and the Lightning Component Framework are all JavaScript frameworks, but they provide such a high level of abstraction that they feel like different languages. As a result, skills were not transferable, and developers found it hard to ramp up. Apps and components written with different frameworks are not interoperable.
Web Standards Reborn – More Standards, Less Frameworks
New standards developed during the last five years include – ECMAScript 2015 (6), 2016 (7), 2017 (8), 2018 (9) and beyond (adding classes, modules, promises, decorators, etc.), web components, custom elements, templates and slots, shadow DOM.
The standardization of the core stack opens the door to a new breed of frameworks that provide a thin layer of specialized services on top of a standard stack. The main benefit of all of this is a common component model and a common programming model, transferable skills, and the fact that it is now easier-to-find/ramp-up developers. Other benefits include interoperable components and a considerably improved performance because core features are implemented natively in web engines instead of in JavaScript in framework abstractions.
Lightning Web Components
That brings us to Lightning Web Components, which is essentially Salesforce's implementation of this new breed of lightweight frameworks built on web standards. It leverages custom elements, templates, shadow DOM, decorators, modules, and other new language constructs available in ECMAScript 7 and beyond.
Lightning Web Components provide a layer of specialized Salesforce services on top of the core stack, including Base Lightning Components, Lightning Data Service, and User Interface API.
This blog is going to talk about a filtered custom related list component that we built using a Lightning Web Component programming model. This mainly uses the Salesforce Lightning's lightning-data table base component and its features. Before moving forward, we will understand how Lightning Web Components evolved and its advantages over Aura component development.
Choosing Between Aura and Lightning Web Components
For the most part, if you're building brand new functionality, you should look at building with Lightning Web Components first. Your applications will benefit from the increased native in-browser operation, which then translates to faster app performance and more functionality.
However, there are some places where the functionality afforded to Aura components isn't yet fully supported in Lightning Web Components. In these cases, you'll need to determine whether you can build most of your applications with Lightning Web Components and add key functionalities with an Aura wrapper, or if you need to build more functionality with Aura components.
Filtered Custom Related List Component Using LWC
The need to build this custom component
Salesforce provides the "Related List" and "Related Lists" standard Lightning Components in order to show related records. But this standard component has a few limitations such as a lack of custom sorting, an inability to search using specific fields, no custom filters, no pagination/infinite scrolling to load more data, and difficulty in terms of formatting columns with appropriate data types (such as email, phone, currency, etc.)
To fulfill these needs in addition to existing features, we built a new generic custom related list component using the Lightning Web Component programming model, which can be used for any type of object in Salesforce.
Features of Our Custom Related List Component
Supports any object which has a relationship (lookup or master-detail) with its parent object.
Add default filters while configuring this component on the records page to show specific records.
In addition to default sorting, sort records by clicking on columns in any direction.
The component provides infinite scrolling to display more data when users scroll to the end of the table.
Search records using all column fields except date, date/time and Boolean fields.
This component has to be configured according to need as well as design attributes.
The data in the related list is displayed in formatted columns according to their field’s data type, such as email, phone, currency, etc.
You can view, edit or delete any record from the related list.
You can also create a new record of the object specific to the related list.
Design Properties (Configurations)
When you add this component on the Lightning records page, you have to configure certain properties. These are:
Title – Specify the title for the custom related list. If you do not specify this explicitly, then it will take the plural label of the object by default. For example, “IT Department Contacts”.
Related List Object – Enter the object API name for which records will be shown. For example, “Contact”.
Related List Fields – Specify comma separated multiple fields (API name) which will be shown as columns in the related list. For example “Name, Email, Title, Phone”.
Related Field – The relationship field’s API name must be entered. For example “AccountId”.
Default Sort By Field – If you want the list to be sorted by a specific field by default, then enter that field’s API name. For example, “Name”.
Filter Logic – To display specific records based on some criteria, enter the default filters in this property. You can enter multiple conditions with logic i.e using AND, OR.
LIMIT Size per Load – Enter the limit per load, i.e number of records to be shown initially and every time you scroll to the end of the table to load more data. By default, the limit size will be considered as “30” if you leave it blank.
Icon Name – Provide the Lightning Design System’s name of the icon. The name can be written in the format, 'standard:related_list' where 'standard' is the category, and 'related_list' is the specific icon to be displayed. This icon is used by default. The icon is displayed in the header to the left of the title.
Read other Extentia Blog posts here!