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
What’s in a name
Lightning Web Components embodies two pillars of the technologies it was built around.
- Lightning: Called after the newest Salesforce user interface experience: Lightning Experience
- 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’
This section assumes that the reader uses Visual Studio Code as the main IDE for the force.com platform, as recommended by Salesforce.
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
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.
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.
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: https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_lwc_track.htm
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.
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!