After reading this, you should:

  • Understand why Lightning Web Components were brought to life
  • Be aware of the key building blocks that are made available through the Lightning Web Components framework



This blog targets everyone who wants to get to know a bit more about Lightning Web Components. We are going to start slowly to get you up to speed about the how and the when of Lightning Web Components and will continue with more advanced LWC-related content in future blog posts. Consider this post as the first of a series!


Now, let’s get to the real deal.


Salesforce. Visualforce. Lightning Components. Long ago, three technologies lived together in harmony. Then, everything changed when LWC was released.


A little history lesson

Before we start, let’s reflect on how Salesforce has evolved in terms of user interface technologies. I can imagine the joy of Salesforce partners when in 2008, Salesforce stated:

‘Visualforce and Visualforce Components will be made available with the Summer '08 release, out early June’. At the time, this meant that developers were finally able to customize visualisations and automisations by their customers needs with virtually no restrictions (let’s disregard ViewState issues). Then, seven years later, Salesforce made a new UI technology generally available called Aura Components (now formerly Lightning Components). This technology was very Javascript-heavy, unlike its older brother VisualForce. Aura components were brought to life to accompany Lightning Experience, which then was another fairly new feature of Salesforce. At the time Aura Components were, just like most other Javascript frameworks at the time, yet another way to display and transform data using Javascript. At the time, writing Javascript made you one of the cool kids, and most of the cool kids wrote code without adhering to a commonly established standard whatsoever. Now with the release of Lightning Web Components, Salesforce brought a more mature, efficient and user-friendly framework to the table.


What’s in a name

Lightning Web Components embodies two pillars of the technologies it was built around. 

  1. Lightning: Called after the newest Salesforce user interface experience: Lightning Experience
  2. Web Components: As mentioned before, there was a point in time where there was no real standard to follow for developing web applications. Time went by and this changed when the core [web] stack finally got the update it needed to become an application development platform in its own right. LWC is built on top of this application development platform, which is more commonly called ‘Web Standards’


File structure


This section assumes that the reader uses Visual Studio Code as the main IDE for the platform, as recommended by Salesforce.

Maintaining a lean file structure when developing Aura Components might have been tricky at times, especially because the Salesforce Extension Pack in Visual Studio Code generates all (yuck) the files you might possibly need to create an Aura Component. This means that the simplest of components generated through Visual Studio Code came along with 9 files. With Lightning Web Components, only essential files are generated by default, resulting in only 3 files - html, Javascript and a metadata file.



We say goodbye to the famous controller, helper and renderer files, and bundle them in one Javascript file, which is conveniently named the same as the html file. On top of that, developers are now able to freely unleash the power of Javascript in their custom components as Salesforce traded the JSON-like Aura Component syntax for a full-blown Javascript syntax in Lightning Web Components. Exciting times! This means for example that the times of callback hell are over as async/await is now at our doorstep, waiting to be used!


The designer file has also been dropped and has been merged with the metadata file in one new file called the Component Configuration File. This configuration file allows for different targets to have different design attributes. An excerpt of this file showing a design attribute intended only for a Lightning Community is shown below:


Lightning Web Components building blocks


Starting from ES6, Javascript was hugely improved [in my opinion, that is] by introducing modules. Lightning Web Components takes advantage of this feature to enable developers to write modular code. Developers can write their (reusable) business logic classes in separate files and import them on a per-need basis in their components. 

But that’s not all! In fact, Salesforce itself has made an effort to encapsulate its different features in importable building blocks. You need to use a label? Import it. Looking for a field’s definition? Import it. Desperately in need of data fetched by a custom apex class method? Import it.

Aside from the more obvious imports, LWC also has some dedicated decorators - you know, the things with the @ in in front of them - that you can import. We’ll describe them below.


LWC decorators come in three different flavours: @api, @track and @wire.

  • @api:

Properties and methods can be decorated with this decorator. It exposes the property or method as being part of the public api of the component or application. A parent component can read or pass a value to these decorated members in order to set their values.



  • @track:

A property that you want to keep private but that needs to update the UI when it’s value changes can be decorated with the @track decorator. This decorator notifies the LWC framework that the variable needs to be observed for changes, and that when it changes, its dependencies need to be updated as well. I purposely say dependencies rather than ‘UI components’, as a property can trigger more than just a change in UI. Imagine a complex calculation that is dependent on a user input. This calculation can be made reactive to the user input by using computed properties. More on those later.


Spring 2020 note: The @track decorator is no longer required to make properties privately reactive. More on this:


  • @wire:

Finally, there’s wired properties. As the documentation states: The wire service provisions an immutable stream of data to the component. Each value in the stream is a newer version of the value that precedes it. Basically, wiring is used to either provision data from a custom apex method that provides this data or from one of the wire adapters in the lightning/ui*Api modules. Storing wired data can be done either directly in a property, or through a wired function. I recommend to only use wired functions when an action is tightly coupled with the retrieval of the data.



Noticed the $? This indicates that the variable passed to the wire adapter is reactive. When the variable changes, the wire adapter provisions the application with refreshed data.

Computed properties

Remember the good ol’ days when you could write code in HTML files? Pepperidge farm remembers. With Visualforce and Aura Components it was possible to write complex expressions and more in html files. The most simplest of examples would be:

Many of those could result in unreadable and unmaintainable code. With LWC, computed expressions come to aid to improve readability and maintainability of code. Computed properties are written as follows:


Note that when the foo or bar variable changes, myComputedProperty is recalculated as well. Pretty neat, right?

A playground, how cool is that?

Finally, I’d like to give some kudos to Salesforce for providing us with our own Lightning Web Components playground. The playground allows for developers to do some quick and dirty prototyping in their browser on the fly, rather than deploying the code to an org and visualising the outputs. Be sure to visit the playground sometimes, maybe we can play together some time!

The end is near

Although there is so much more to say, we’ll keep that for future blog posts. In future posts we will discuss eventing in depth, the use of getters and setters, using and understanding the shadow DOM, service components as a framework, and so on.


So, where to go now? Trailhead!