Decorators and Mixins in Lightning Web Components
The evolving nature of these three technologies has lead to the introduction of web components, a cross-browser solution for building complex web apps. On top of this open source standard, Salesforce developed Lightning Web Components (LWC) as a fast, enterprise-grade wrapper around vanilla web components. The result is a thin, performant, and feature-packed framework built entirely on the open web.
What is a Mixin?
In many object-oriented programming languages, classes can “receive” additional methods through a feature called inheritance. For example, if you have a
Vehicle class with the methods
stop, subclasses like
Car can implement them directly:
Inheritance affects the composition of an object by changing its hierarchy. Every
Car is now also a
Vehicle. But what if you merely wanted to add in common methods to objects without dealing with any parent class? That’s what a mixin does.
Object.assign method, which copies all of the properties from one object onto another:
User can now call
User can also inherit from just one class, while including properties and function) from any number of mixins:
However, writing out
(For more information on this technique, check out this article.)
User includes the
greetingsMixin and inherits from the
Person class, all in one line.
This technique is more than syntactical sugar: it’s actually the one which LWC regularly prefers. For example, the
Navigation Mixin provides methods that are useful to navigational UI elements, but ultimately, each class that includes it should also derive from a plain
NavigationMixin provides functionality that’s crucial to components dealing with navigating through pages, while
LightningElement provides all the base functionality for every component. Thus,
TestComponent will need to include
NavigationMixin and subclass from
LightningElement, and can do so in the easy-to-see, single-line format.
What is a Decorator?
Suppose we have a class like this:
Now, any code which makes use of this class can create a user:
getFullName method if they so desired:
Now, this is obviously a trite example, but the danger still remains. You can write code to make a class property read-only, like this:
This works, but it’s obviously cumbersome to write for multiple properties.
Enter decorators. You can define a decorator function to apply any behavior you want to a target property. For example, to set a target as
writable: false, you could do this:
We just defined a decorator called
readonly which, when passed a target, sets its
descriptor.writable property to
false. This can be applied to our
User class like this:
Voila! The same functionality, in a single line of code.
LWC provides several decorators for developers to use. They are:
@api: by default, every property is hidden and private.
@apiexposes it publicly.
@track: this marks a property as reactive, which means that when its value changes, the web component will re-render and display the new value.
@wire: this is a decorator which signifies that we want to read Salesforce data.
These three decorators, which are unique to LWC, aim to help reduce rewriting the same code while easily providing common functionality.
Since LWC is built on web standards, it can leverage native APIs and languages in order to make developers immediately productive, since they’re using existing skills rather than learning proprietary techniques.
If you’d like to take a closer look at Lightning Web Components, Salesforce has a boilerplate app that’s built in TypeScript. There’s also a Trailhead lesson to help you learn about web components in less than an hour. Or, feel free to check out the LWC dev docs for more specific reference information.
Credit: Source link