Posted in Lightning Component, Lightning Web Component, LWC, Salesforce

Lightning Web Components for AURA Developers Part – I

The best way to compare the Aura Component and Lightning Web Components programming models is to look at code for similar components written in the two models. The goal of this post is to help you to leverage your Aura components skills to accelerate learning about Lightning web components. You learn how the two types of components work well together.


Before you dive into this post, complete the Lightning Web Components Basics module, which gives you a great introduction to the new programming model.
I am assuming that you’re familiar with the Aura Components programming model, and we won’t explain its features, except in comparison to the Lightning Web Components programming model. If you’re not familiar with Aura components, start with the Aura Components Basics module.

Component Bundles

The component bundle file structure is different for an Aura component and a Lightning web component. Here’s how the files map between the two types of component.

(Source: Trailhead )

Migrate Markup

  • An Aura component contains markup in a .cmp file. The file starts with an <aura:component> tag and can contain HTML and Aura-specific tags.
  • A Lightning web component contains markup in a .html file. The file starts with a <template> tag and can contain HTML and directives for dynamic content.

Attributes Become JavaScript Properties

Migrate attributes from tags in the markup (.cmp) of an Aura component to JavaScript properties in the JavaScript file (.js) of a Lightning web component.

Aura component:

 <aura:attribute name="recordId" type="Id" />
 <aura:attribute name="account" type="Account" />


import { LightningElement, api, track } from 'lwc';
export default class AccountSummary extends LightningElement {
    @api recordId;
    @track account;

The recordId and account attributes in the Aura component become the recordId and account JavaScript properties in the Lightning web component.

The two Lightning web component properties have different decorators. The @api and @track decorators both make a property reactive, which means that when the property value changes, the component’s HTML template rerenders.

The @api decorator marks recordId as a public reactive property. A public property is part of the public API for the component, which means that it can be set in Lightning App Builder, or by a parent component that uses the component in its markup.

The @track decorator marks property as a private reactive property, also known as a tracked property. These properties are used to track internal component state and aren’t part of the component’s public API.

Basic Aura Expressions Become HTML Expressions

Migrate basic expressions from markup in an Aura component to expressions in HTML in a Lightning web component. An example of a basic expression is a reference to an attribute in an Aura component.
For example, the AccountPaginator Aura component uses basic expressions to display the values of the page, pages, and total attributes.

<aura:component >
    <aura:attribute name="page" type="integer"/>
    <aura:attribute name="pages" type="integer"/>
    <aura:attribute name="total" type="integer"/>
    <div class="centered">{!} Accounts • page {!} of {!v.pages}</div>

Here’s the equivalent syntax in the HTML file of the accountPaginator Lightning web component.

    {totalItemCount} items • page {currentPageNumber} of {totalPages}

The HTML references the totalItemCount property in paginator.js. The {currentPageNumber} and {totalPages} expressions reference getters that process the pageNumber and pageSize properties.

import { LightningElement, api } from 'lwc';
export default class Paginator extends LightningElement {
    /** The current page number. */
    @api pageNumber;
    /** The number of items on a page. */
    @api pageSize;
    /** The total number of items in the list. */
    @api totalItemCount;
    get currentPageNumber() {
        return this.totalItemCount === 0 ? 0 : this.pageNumber;
    get totalPages() {
        return Math.ceil(this.totalItemCount / this.pageSize);

Aura Conditionals Become HTML Conditionals

Migrate <aura:if> tags in an Aura component to if:true or if:false directives in a Lightning web component’s HTML file.
Here’s some conditional markup in the AccountDetails Aura component.

<aura:if isTrue="{!v.spinner}">
    <lightning:recordForm recordId="{!v.accountId}"
      fields="{!v.accountFields}" columns="2"/>

Here’s similar HTML in the accountDeatils Lightning web component.

<template if:true={spinner}>
    <lightning-record-form object-api-name="Account" 
      record-id={accountId} fields={accountFields} 

The HTML file of a Lightning web component starts with the standard HTML <template> tag, and it can also contain other <template> tags in its body. In this example, the content in the <template> tag conditionally renders depending on the result of the if:true directive.

Aura Iterations Become HTML Iterations

Migrate <aura:iteration> tags in an Aura component to for:each directives in a Lightning web component’s HTML file.
Here’s the Aura syntax in Sample.cmp.

<aura:iteration items="{!v.items}" itemVar="item">

Here’s similar HTML in the sample Lightning web component.

<template for:each={items} for:item='item'>
    <p key={}>{item}</p>

Stay tuned for next blog post for Lightning Web Components for AURA Developers Part- II.


Lightning Web Components for Aura Developers

Working with Aura and Lightning Web Components: Interoperability and Migration

Posted in Lightning Web Component, LWC, Salesforce

Introducing New Lightning Web Components

Introducing Lightning Web Components

In case you missed it, Salesforce recently announced Lightning Web Components (LWCs) — a new programming model that developers can use in addition to the existing Aura-Based programming model to build Lightning components. 

Lightning Web Components is a new programming model for building Lightning components. It leverages the web standards breakthroughs of the last five years, can coexist and interoperate with the original Aura programming model, and delivers unparalleled performance.It’s not same as Lightning Components or built on top of Aura framework but it’s a different model which will co-exist with Lightning Components.
For more information Trailhead Project: Quick Start with Lightning Web Components

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

Lightning Web Component mainly consists of below mentioned files :

  • HTML provides the structure for your component.
  • JavaScript defines the core business logic and event handling.
  • CSS provides the look, feel, and animation for your component.
  • Component Configuration File(.js-meta.xml) –  This file provides metadata for Salesforce, including the design configuration for components intended for use in Lightning App Builder.

Here’s take a look simple Lightning web component that displays “Hello World” in an input field.


    <input value={message}></input>


import { LightningElement } from 'lwc';
export default class App extends LightningElement {   
message = 'Hello World'; 


input {
   color: blue;

Component Configuration File

<?xml version=”1.0″ encoding=”UTF-8″?>
<LightningComponentBundle xmlns=”” fqn=”helloWorld”>
<isExposed>true </isExposed>
        <targetConfig targets="lightning__RecordPage">
  • Required
    • apiVersion binds the component to a Salesforce API version.
    • isExposed (true or false) makes the component available from other namespaces. Only set this to true to make a component usable in a managed package or by Lightning App Builder in another org.
  • Optional
    • targets specify which types of Lightning pages the component can be added to in the Lightning App Builder.
    • targetConfigs let you specify behavior specific to each type of Lightning page, including things like which objects support the component.

See the documentation for the full list of supported syntax.


The Lightning Web Components programming model has three decorators that add functionality to a property or function.
The ability to create decorators is part of ECMAScript, but these three decorators are unique to Lightning Web Components.

To expose a public property, decorate it with @api. Public properties define the API for a component. An owner component that uses the component in its markup can access the component’s public properties. Public properties are reactive. If the value of a reactive property changes, the component’s template rerenders any content that references the property.
See Public Properties.
To expose a public method, decorate it with @api. Public methods are part of a component’s API. To communicate down the containment hierarchy, owner and parent components can call JavaScript methods on child components.
See Public Methods.
To track a private property’s value and rerender a component when it changes, decorate the property with @track. Tracked properties are also called private reactive properties.
See Tracked Properties.
To read Salesforce data, Lightning web components use a reactive wire service. When the wire service provisions data, the component rerenders. Components use @wire in their JavaScript class to specify a wire adaptor or an Apex method.
See Use the Wire Service to Get Data and Call Apex Methods

What happens to Lightning Components?

Lightning Components are not going away and they will continue to exist in parallel to Lightning Web Components. It’s something similar when Lightning Components were available and we started thinking that if it’s going to replace Visualforce pages.
As VF pages and Lightning Components co-existed, now they are being joined with Lightning Web Components. It will be more of a choice of the framework that you will want to choose when building UI components. With the standard Web development model, it looks like Lightning Web Components definitely will be the choice in future.

Migration Strategy

The programming model for Lightning Web Components is fundamentally different than the model for Aura Components. Migrating an Aura component to a Lightning web component is not a line-by-line conversion, and it’s a good opportunity to revisit your component’s design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.

To understand more about migration strategy stay tuned for my next blog posts where i will explain in details about Lightning Web Components for AURA Developers.

Lightning Web Components for AURA Developers Part – I

References :

Lightning Web Components Basics

Introducing Lightning Web Components

Lightning Web Components ( LWC ) in Salesforce with Non-Scratch Org