Exploring Salesforce Lightning Web Components: Part 3

We explore data binding and related topics.

This article is part of the series starting with Exploring Salesforce Lightning Web Components: Part 1.

Data Binding

One important feature that Lightning Web Components provides is data binding; again this is not part of the Web Component specification.

Let us look more carefully at the first example:

Notice that the HTML uses curly brackets, e.g., {greeting} and {changeHandler}. This syntax binds the HTML to the Lightning Web Component’s JavaScript; specifically to the property or method of the exported class.

In addition, the @track decorator makes the data binding reactive, i.e., changes to the property are automatically reflected in the HTML. This is accomplished by re-rendering the template.

When a component re-renders, all the expressions used in the template are reevaluated.

— Salesforce — Data Binding in a Template

Binding to Computed Values

It is also important to observe a limitation:

The property can be a JavaScript identifier (for example, person) or dot notation that accesses a property from an object (person.firstName). LWC doesn’t allow computed expressions like person[2].name[‘John’].

— Salesforce — Data Binding in a Template

Lighting Web Components, however, can leverage the JavaScript get syntax to bind to computed values, for example we can update the HTML and JavaScript to display the greeting in uppercase:

The updated HTML and JavaScript:

Observations:

• Here we take advantage of the fact that updating a tracked value causes all the expressions, including greetingUpper, to be re-evaluated

Directives

In addition to data binding, Lighting Web Components provides several other custom HTML markup features related to data binding: conditionals and iteration.

note: If you have used other JavaScript frameworks, e.g., Angular, React, or Vue.js, you were likely expecting something like this.

Conditionals

Let us explore conditionals by example; conditional content that is controlled by a checkbox.

The updated HTML and JavaScript:

Observations:

• I am pretty sure that the official documentation on conditionals uses a poor pattern. In their example, they do not drive the checked property on the lightning-input from JavaScript. In React, this would be called having an uncontrolled component; a poor practice

Iteration

Let us explore iteration by example; listing multiple contacts:

The updated HTML and JavaScript:

Observations:

• The only non-obvious requirement is that each rendered element must have a unique key property (string or number) obtained from the data set
• Lightning Web Components provides an alternate, slightly more flexible, iteration pattern using the iterator directive

Iteration and Tracking

Much like the JavaScript primitives we used earlier, Lightning Web Components can track changes in more complex objects, e.g,. arrays. In this example, pressing the button adds an item to the array.

Observations:

• From years of React development, I have been trained to never mutate objects; thus the array spread syntax
• At the same time, through a bit of experimentation, I learned that the @track decorator detects changes even when one mutates properties, e.g., using the array push method. While this was surprising, the specific capabilities are documented in Reactive Property Data Types

Virtual DOM Like Behavior

First, it is clear from the documentation that Lighting Web Components use the Shadow DOM (or more precisely a polyfill of it):

The elements in each Lightning web component are encapsulated in a shadow tree. This part of the DOM is called a shadow tree because it’s hidden from the document that contains it. The shadow tree affects how you work with CSS, events, and the DOM.

Shadow DOM is a web standard that encapsulates the elements of a component to keep styling and behavior consistent in any context. Since not all browsers that Salesforce supports implement Shadow DOM, LWC uses a shadow DOM polyfill. A polyfill is code that allows a feature to work in a web browser.

— Salesforce — Shadow DOM

What is not clear from the documentation is that Lightning Web Components also uses something like React’s Virtual DOM; when the template re-renders it only updates the differences to the DOM.

We can illustrate this by observing the DOM updates when pressing the button in the previous example:

Observations:

• Even though the component is re-rendered, notice that the entire list of DOM elements is not; rather, the new DOM element is simply appended

Next Steps

In the next article, Exploring Salesforce Lightning Web Components: Part 4, we explore a variety of JavaScript related specifics.