Ride the Lightning: Tips for Building Salesforce Lightning Web Components

I wanted to learn more. About a year ago, I noticed a series of Chatter posts from our Sr. UX Designer regarding Salesforce’s launch of Lightning Web Components (LWC), a programming model built on modern web standards for creating custom components on the Lightning Platform. I decided to explore this new alternative to Aura (the previous model built by Salesforce).

In order to develop the most progressive solutions possible for our customers, our development team works with the latest features and tools that Salesforce is rolling out. I started my adventure by attending the Lightning Web Components Global Broadcast webinar. Aura is no longer open source (LWC is) , and it’s likely that any new functionality Salesforce rolls out will be available in LWC as opposed to Aura. So, I decided to start building with Lightning Web Components.

Sayon-Aura

As we gradually say goodbye to building with Aura Components, Aura has not been able to leverage recent advances in modern web technologies. Built from the ground up, LWC takes advantage of modern standards that are natively available in today’s web browsers such as Web Components, Custom Events, ECMAScript classes, and more.

Consequently, more of the core tasks involved in managing component execution are now handled natively by the web browser which results in a snappier user experience.

Simple Survey’s new “Insights” functionality. Built using LWC.

Tips for Exploring LWC

While I will admit there were points of frustration at first (as to be expected with using any new tool or system), I personally have grown to enjoy using LWC. My advice to anyone getting started is to take some time to really dig in and understand it. Below are some tips that cover some of the capabilities and limitations we’ve discovered while using LWC, as well as a few best practices and resources we’ve leveraged along the way.

Tip 1: Seek to Understand the Capabilities of LWC

LWC is lightweight and faster than Aura, which mean less loading wait times, it has a more responsive UI due to faster execution, and it picks up where Lightning Experience (LEX) tends to drag.
It’s built around modern ECMAScript so we can use imports, extend classes, use arrow functions, etc.
It’s much easier to call @AuraEnabled annotated apex methods and not restricted to a specific controller (simply import them!)
We no longer need to define component attributes in markup. Just mark a property with the @api decorator.
Events can be dispatched without having to create an event definition (as required by Aura).
Wrapping callbacks in $A.getCallback() is no longer necessary.
We can import a script from another LWC.

Tip 2: Take Note of Where LWC is Not Yet Supported

Although LWC is the way forward for new development, there are a few places they are not supported yet, such as Salesforce Console APIs (Navigation Item, Workspace, Utility bar) as well as URL addressable tabs. Others are outlined in supported experiences.

The good news is that we can work around these limitations by nesting the LWC inside of an Aura component, then handle communication between the parent Aura component and child LWC by firing off an event to the parent Aura component, and set an attribute or call a method exposed by the child LWC from Aura. Note that although one can nest an LWC inside of an Aura component it is not possible the other way around.

Tip 3: Watch Out for ‘Gotchas’ or Limitations

You cannot use a LWC yet for Actions and LEX console is not yet supported.
You can embed the LWC inside of an Aura component as a work-around.
LWC does not offer two-way data binding, as Aura does. As a result, user input does not automatically propagate back to the controller.
A practice I follow to account for this is to define a single change handler which copies event.currentTarget.value to the controller property corresponding to event.currentTarget.name
@api properties passed down from a parent component cannot be modified in the child component.
To work around this limitation, one can expose the @api property via a getter / setter which clones the value to an internal property.
Will have to dispatch an event if the parent component needs to know when the value is updated
“Merge field” expressions are not supported
This can be handled via a getter property in the component controller
Modifying an element inside of a tracked array property will not trigger a render update since one has to assign to the property directly for the framework to know about it.
For arrays one can call .splice() with no parameters to force a render update.
Component styling cannot reach across component boundaries such as into a standard component.
Notable exception is that one can override css variables which do pass through to the child component boundary.
The standard components have been open sourced so one can make a custom version and modify as needed.

Tip 4: Take Advantage of Resources to Power Your Lightning Learning

And of course, Trailhead!