It’s almost that time of the year again - the Spring ‘19 release is upon us!
There’s loads of goodies coming our way, but one of the most exciting for developers is the release of Lightning Web Components. It’s a new programming model for Lightning component development, built on top of cutting-edge web technologies - and we think it’s going to bring a wealth of benefits to Salesforce developers.
What’s a web component?
To explain what Lightning Web Components are all about, it’s useful to take a look at the tech they’re built on top of, and how it came about.
The concept of “components” on the web has existed for a long time. The general idea is to split your UI component into modularized chunks, each of which is self-contained and re-usable. There are many benefits to this approach, not least of which are the reduction of duplication in your logic and UI, and the maintenance advantages of building your application out of small, easy to understand pieces of functionality.
Modern web frameworks such as React, Angular and Vue all put some concept of a “component” front and center as core primitives, with great results. However, even as this approach has become more and more common, the frameworks themselves have remained fragmented in their implementations - you can’t (easily) drop an Angular component into a React project or vice-versa, and once you’ve learned how to create components in Vue you might have to re-learn a lot of concepts before you can be productive in one of the other frameworks.
Web components are an attempt to address this fragmentation, and create a set of standards for how components can be natively supported by all browsers. By standardizing the underlying technology, we can both pave the way for interoperability between different frameworks, and reduce the friction for web developers and teams who want to migrate between different frameworks.
...OK, but what’s a web component?
Web components are a set of standards. There are several different specifications that make up what people refer to as “web components”:
- Custom elements - These allow you to define a custom HTML tag that can be used inside your existing markup. Instead of an endlessly nested set of
<div>tags, you can create your own
<myapp-navbar>element which has its own encapsulated UI and behaviour.
- HTML templates - HTML templates allow you define a chunk of HTML markup which is not rendered until you need to insert it. They can contain
<slot>elements which allow you to dynamically inject content into certain parts of the markup. You can think of this as a standardized version of Handlebars.js (or your HTML templating library of choice).
- Shadow DOM - Much less ominous than it sounds, the shadow DOM (Document Object Model) is a way of “componentizing” the DOM . The DOM is a representation of all of the elements in your web page - but accessing the DOM is usually done in a global manner by querying the entire document for nodes matching certain properties, which causes issues when you’re trying to encapsulate components and stop them treading on each others’ toes. The shadow DOM gives you a way of creating a “shadow tree” which only contains the elements in your component. This allows you to hide elements inside the tree from elements outside it, and vice-versa, creating the encapsulation that components are all about.
What does any of this have to do with my Lightning components?
This standardization push opens the door for a new breed of web frameworks, which are more focused on providing specialized functionality on top of the platform, rather than plugging gaps in the platform itself. We’ve touched on the benefits already, but they include the prospect of:
- Interoperable components between frameworks, making it easier to migrate between frameworks and re-use functionality that other developers have built using other frameworks
- More transferable skills for developers: developers will be able to get up and running across different technology stacks with less ramp-up
What about my existing Lightning components?
With the addition of Lightning Web Components, the existing development model for Lightning components is being renamed back to the Aura programming model. Aura Components and Lightning Web Components can coexist and interoperate, and they share the same high level services for accessing Salesforce data and metadata, as well as the same base Lightning components (which were already implemented as Lightning Web Components!) You can put both types of component on the same page, and Aura components can include Lightning Web Components.
The upshot of this is that you can manage your migration to the new programming model however you like - you can continue to build Aura Components, or you can start to slowly transition your new components over to Lightning Web Components, without worrying about interoperability.
If you’re starting a new project then we’d recommend jumping straight in with Lightning Web Components. It’s built on modern web standards, it’s here to stay, and most importantly it delivers a whole host of benefits that you can start to realize straight away.
Deploying Lightning Web Components with Gearset
Of course, these fancy new components won’t be much fun if you can’t move them easily between environments! Luckily, we’re already working on support for them in Gearset, and we’ll have that support ready before the release of Spring ‘19.
An exciting step forwards
Lightning Web Components represent an exciting step-change in front end development for Salesforce. It’s a technology stack built from the ground up on cutting edge web standards, but it’s available to you right now - and better still, it integrates with your current codebase so that you can handle the migration seamlessly.
If you want to read more, there’s some great blog posts on the Salesforce developer blog introducing the new components and going into a bit more detail about developer tooling. There’s also a Trailhead module if you want to try out making your first Lightning Web Component. If you want to know more about the web components standards themselves, I’d recommend the MDN documentation as a good starting point.