The difference between Lightning Components and Lightning Web Components, Part 1, Markup and CSS

Posted by

So like many of us, you just started getting really good at Lightning components and then all of the sudden, Salesforce releases a new programming model. It’s definitely something thats worthy of an eye roll but after a while it catches your interest because we are programmers after all, and we cannot escape the lure of new technology to play with. The goal of this post is to walk through all of the translatable material from building Lightning components to Lightning web components and become comfortable with adopting them. These topics will be separated into a 4 part series discussing:

  • Part 1: Markup and CSS
  • Part 2: JavaScript and Modules
  • Part 3: Salesforce Data and the @wire decorator
  • Part 4: Composition and Events

Business case: You are at a client and have been gathering information from stakeholders and begin putting together requirements and a backlog. Based on your analysis, you ultimately determine that you need one stand alone brand new Lightning web component and you will also need to add a section onto an existing Lightning component (Aura) with an embedded Lightning web component. Let’s get started.

JavaScript properties are the new Aura Attributes

Typically when starting your Lightning component, you would define a few aura attributes that you know you’ll work with.

In a Lightning web component, you would instead build your attributes as JavaScript properties.

Okay thats cool but what is @api and @track? Those are called decorators, which is just a fancy word to say that these properties are reactive, meaning that when the property value changes, the component’t HTML template re-renders. While we are on the subject, let’s dive into the function of these two decorators.

The @api decorator designates a public reactive property. This means that it is part of the public API of your component, which can be set by the Lightning App Builder or a parent component that is using this component in its markup.

The @track decorator designates a private (tracked) reactive property. These decorator types are only part of the components internal state and are not part of the public API.

Saying goodbye to Aura Expressions

When writing a Lightning component, you would use expression syntax {!v.attribute} when wanting to display the value:

With Lightning web components, we lose the !v. part of the expression and simply add in a standard HTML Expression into the {markup}:

The reason that this property reference says currentMessage rather than message, the actual name of the property, is because we are referencing a getter method in the JavaScript that processes the property:

Only on one condition

When writing a lightning component, to write a condition, you would use the <aura:if> tag:

With Lightning web components, this changes to using the if:true and if:false directives to evaluate a condition:

Let’s unpack this a little bit because there are a couple of things here. Notice how the if:true directive is nested in a template element? In standard web development, a template element holds the content inside hidden from the client and will not be rendered, unless by making it visible using JavaScript. Salesforce uses this same approach, however instead of relying on JavaScript to render content inside of a template element, they built special directives to manipulate the DOM. A directive is a special attribute that adds dynamic behavior to an HTML template. In the example above, if:true/false is a directive used to conditionally render DOM elements in a template. For more information on directives and how to use them, visit the documentation. So this is what we have so far!

Iteration is key

When writing a lightning component, to iterate over an array, you would use the <aura:iteration> tag:

With Lightning web components, this changes to using the for:each and for:item directives to iterate over an array:

One important thing to point out is the key directive used in the example above. No matter which iteration directive you use, you must use a key directive to assign a unique value to each item in the list. The key must be a string or a number, it can’t be an object. The engine uses the keys to determine which items have changed.

Lifecycle Hooks

Remember when we used the if:true directive to conditionally render content? In this particular application, we are using a Lifecycle Hook method to initially set our isChecked property before the evaluation occurs. You keep saying this term “Lifecycle Hook”! What does it mean? Let’s back up. In a Lightning component, if we wanted to do some logic on load of the component, we would add a line into our markup that looks something like this:

The onInit function in a Lightning Component any initialization that we need

Lifecycle Hooks are callback methods that let you run code at each stage of a component’s lifecycle. The connectedCallback() lifecycle method fires when a component is inserted into the DOM.

So now when our component evaluates the isChecked property, it will have been initialized for us using this Lifecycle Hook method. If you want more information, there is a really cool diagram that goes over the Lifecycle Flow of a Lightning web component.

.THIS no more

Last but not least, we have vanilla css that we sometimes need to use whenever we cannot use the Salesforce Lightning Design System. For the examples I show you, I use vanilla css to show how it incorporates into your Lightning web component, however I highly encourage you to use the Lightning Design System whenever you can.

When writing vanilla CSS in Lightning components, the style file required that you added a .THIS before each class:

Lightning web component’s css files no longer require you to have the .THIS keyword in front of your css class.

I will eventually do a blog post about css encapsulation and how the Shadow DOM works with Lightning web components compared to traditional web development. Here is the full code and UI:

As we move through the series, the code will steadily become more complex. If you have any questions for me, please leave a comment or reach out! Thanks for reading.

6 comments

  1. Great post. I’ve been curious about lwc, they came out soon after I moved to react. Lots of similarities between the two.

    Glad to see Salesforce improving on their front end. I really enjoyed lightning development, lwc looks a little more modern.

    Liked by 1 person

Leave a comment