[SalesForce] What are Lightning Web Components

Salesforce has just announced a new feature, Lightning Web Components. What is this? What does it have to do with Lightning Components and the Lightning Component Framework?

Best Answer

Lightning web components (LWC) are a new programming model for the Lightning Component Framework that is slated to be released in the Spring 19 release. This programming model was architected with three principles in mind.

Align with modern web standards
Interoperability with the original Aura-based Lightning component development model
Performance

Standards

LWC is compliant with most ES2015 (aka ES6) and later standards that have seen good adoption across modern browsers. JavaScript APIs such as Class, Module, Shadow DOM, CustomComponent, decorators, mix-ins, and many more figure heavily into the architecture, as do modern HTML and CSS features. This brings a great deal of benefit for the developer. First, the main body of knowledge and skill required is modern JavaScript. It also brings a much simplified component bundle structure and developer experience where a given component is comprised solely of an HTML template, a JavaScript module, and a CSS file (where required).

Here's a screen shot of the component bundle (no CSS) in a project in VisualStudio Code.

Here's an example of the code from a Lightning web component:

HTML Template:

<template>

    <lightning-card title="RecordEditFormDynamicContact" icon-name="standard:contact">

        <div class="slds-m-around_medium">

            <lightning-record-edit-form
                object-api-name="objectApiName"
                record-id="recordId">
                <lightning-messages></lightning-messages>
                <lightning-input-field field-name="Name"></lightning-input-field>
                <lightning-input-field field-name="Title"></lightning-input-field>
                <lightning-input-field field-name="Phone"></lightning-input-field>
                <lightning-input-field field-name="Email"></lightning-input-field>
                <div class="slds-m-top_medium">
                    <lightning-button variant="brand" type="submit" name="save" label="Save"></lightning-button>
                </div>
            </lightning-record-edit-form>

        </div>

    </lightning-card>

</template>

JS Module:

import { LightningElement, api } from 'lwc';

export default class RecordEditFormDynamicContact extends LightningElement {
  @api recordId;
  @api objectApiName;
}

While this is a very simple component that simply surfaces two attributes (the @api decorated properties), you can already see how the JS code reflects modern standards in the import statement for including other JS modules, the export of the class of this module, the use of the class and extends syntax, and the use of JavaScript decorators.

Interoperability

In designing a new programming model for the Lightning Component framework, interoperability with existing Aura-based components is a must. With the GA of LWC, any component built using the LWC programming model can be used in an existing Lightning Component page. To prove this model, Salesforce have used LWC to build Lightning base components for the last year. Any of your existing Lightning Web Components that use a lightning:xxx base component is already using LWC.

Performance

Salesforce has yet to publish any benchmarks or performance data related to Lightning Web Components. But look for upcoming blog posts from the LWC engineering team.

Anecdotally, as more and more of the Lightning Experience UI has become composed of LWC over the past year, many customers have reflected back to Salesforce an experience of better performance.

Learn More

For more details about LWC, please see the introductory blog post on the Salesforce developer blog which has many links to documentation, sample code and applications, and of course, Trailhead.

Aagh! I don't want to read a whole blog, I just want to do something!

No problem. Just go to this quick start project on Trailhead and get the badge.

Events

Events now only go up to a Shadow DOM boundary by default, except for "onevent" handlers. This means that events propagate faster by default. You can choose to control the behavior, though. Also, event.target, which could sometimes be either null when outside the component, now returns the component itself as the target in these situations.

CSS

CSS outside the component can now only affect the top-level of the component. This is not the same as Aura, where you could affect internals with CSS. CSS cannot affect parent, child, or sibling CSS. It is completely isolated, which allows a component to appear as the developer intended regardless of what anyone else might do to that component. You can still style the component itself (e.g. put a border around it), and you do so by specifying the component's actual name. Taken from the documentation:

c-child {
    display: block;
    border: 2px solid red;
}

This styles c-child with a block display mode and a solid border of red.

You can respond to class names, though, through the new :host syntax:

:host(.active) {
  background-color: lightgreen; 
}

Whenever the "active" class is applied to your component, then it changes to light green. The component itself defines how classes can affect it, rather than having the parent force its styles on its children.

DOM

This should be of no surprise, but you can't use things like document.querySelector to find elements outside of your own Shadow DOM. This includes trying to finding elements in parent, sibling, or child components. There is a way to do composition, which is done through <slot> elements. This is similar to Aura's Aura.Component[] and Visualforce's apex:composition.

There's quite a bit more to this, so I suggest you read the Developer Documentation for more details (currently requires a Spring 19 org).

[SalesForce] Lightning Web Components – Benefits and Support

If you are considering LWC, and would like see code samples and how to implement LWC, including interoperability with Aura, take a look at the lwc-recipes sample app. It's maintained by Salesforce Developer Relations. You can find it (and contribute to it) on github.

What are the benefits of using Lightning Web Components?

LWC is built on web standards for almost all of the code involved, with a minimal amount of "custom code" that represents the core Aura runtime that underlies both technologies (as mentioned in the opening blog post). This means they are more secure (LWC adds CSS isolation, leverages native DOM support for better performance, and uses more web-standards JavaScript that can be optimized better).

Also, LWC automatically provides polyfills for older browsers, rather than having code silently (or often not-so-silently) fail on IE 11 and older versions of Safari/Chrome/Firefox. In addition, we have new component "types", such as service components; they have no UI so they use no markup, but can export methods for other components to import in just a single line of code. No more static resources just to share code within a set of components.

LWC itself has a richer API based on the UI-API for better performance and less Apex to write, and calling Apex is now a less painful experience. API support for third-party APIs is also improved, allowing you to call code in a safe, secure manner in ways that are not possible or required Apex code in Aura components.

LWC provides support for the Jest testing framework through the sfdx-lwc-jest plugin. This means you can now write unit tests for your client-side logic in a standard format. In Aura, you were expected to find your own testing framework, like Jasmine or something else. This will help improve your client logic, the same way that Apex unit tests can help improve your server-side logic.

LWC leverages a combination of knowledge of Aura and web components (the general standards), so developers with experience in web components can get in to LWC faster, and developers familiar with Aura will already know most of the major standard components already; you just need to translate them from the old syntax to the new. Should you decide to port an Aura component to LWC, it will be a straight-forward process, since they can be converted almost 1:1 (there are some major differences, but those are very limited).

So, better security, better testing, better browser compatibility, better performance, generally smaller components in terms of overall markup and script size, less need for Apex, less need for multiple Apex controllers, and strong leverage of already existing/established knowledge and skills from both Salesforce development and general web component development.

How much faster are they?

In the opening blog post, they say "we don't know, but it's better" (paraphrased, of course). Salesforce also mentions that customers have reported that Lightning Experience is faster than it was a year ago, and that's partly because the UI is now mostly LWC, and the all/most standard Lightning part of the Lightning Component library is LWC under the covers, which has contributed to faster Aura performance. So, anecdotally, it's better. But we're probably not going to know until someone with a lot of time on their hands converts a bunch of components and does a side-by-side comparison.

Where are Lightning Web Components supported?

According to the docs, as of Spring '20, LWC support is as follows:

Supported features

Lightning Experience
Salesforce App
Lightning Communities
Lightning App Builder
Community Builder
Standalone Apps
Lightning Components for Visualforce
Lightning Out (beta)
Custom Tabs
Utility Bars
Flows
First-Generation Managed Packages
Second-Generation Managed Packages
Unlocked Packages
Unmanaged Packages
Change Sets
Metadata API—LightningComponentBundle
Tooling API—LightningComponentBundle, LightningComponentResource
EMP API
Embedded Service Chat
Gmail and Outlook integration

Unsupported features

Salesforce Console APIs (Navigation Item API, Workspace API, Utility Bar API)
URL Addressable Tabs
Conversation Toolkit API, Omni Toolkit API, Quick Action API
Standard Action Overrides, Custom Actions, Global Actions, List View Actions, Related List View Actions
Chatter Extensions

One additional missing piece is the lack of built-in documentation. Aura provided the Auradoc feature in the Aura bundle. No such feature exists yet for LWC.

How are LWC compatible to existing Aura Components?

The syntax itself is pretty different, so there will be significant portions of your code you'll have to rewrite to convert an Aura component to an LWC. That said, if you're familiar with Aura, it's easy to do the conversion, and familiarity with React and other JavaScript web component frameworks will aid in helping understand LWC. Even better, LWC experience will make it easier to learn other standards-based web component frameworks, unlike Aura, which is proprietary in comparison.

LWC components can be placed in Aura components, but Aura components may not be used in LWC components. For this reason, you'll want to start converting your code from the utility/widget portion of your components before converting main components. You'll need to check the "supported experience" list above before trying to convert top-level Aura components to LWC.

Both Aura and LWC components can coexist in the same Lightning page. With the beta release of Lightning Message Service they can communicate with each other (and with Visualforce pages) via events.

In cases where you can't use LWC immediately, you can always put those on a backlog or, just not worry about it, since Aura will be around for a while. The more components you convert to LWC, the better performance you can expect from your components overall. Converting your core UI components from Aura to LWC won't require any major inconvenience in your existing Aura components, because they look like Aura components in Aura.

To Sum Up

Since its initial release a year ago LWC has had significant improvements such that unless you are inhibited by one of the specific limitations listed above, there is nothing preventing you from building any custom UI project using LWC.

Furthermore, everything in LWC is far simpler than Aura. There are fewer overall "gotchas" than Aura. Finally, if you're just starting out developing on the platform there's a lot less to learn to begin using LWC, because it's a very lean API, in a good way.