• garybreavington

Lightning Web Components


Salesforce have announced the biggest change to Lightning since… well, Lightning!

Lightning Web Components are the future of front-end development on Salesforce. We've been on the pilot and wanted to share some of our thoughts. Spoiler alert: we like it a lot!

Why the change?

Technology in the front-end world moves quickly. Not only do Javascript frameworks move at a brisk pace, but browsers are also adding features and supporting new standards over time. The reality is that technology has moved on since Lightning Components were first introduced - to take advantage of those developments and to continue to improve the performance of UIs in Salesforce, a new approach was necessary.




What's changed? How do Lightning Web Components differ from Aura-based Lightning Components? Firstly - the component bundle is a lot more straightforward, and much more in line with standard web technologies.

With Aura-based Lightning Components, there's the component file, which is XML; there's the controller, which is Javascript, but requires a particular structure, includes a lot of repeated function arguments, and a lot of get this, and set that; a helper file which helps with code organisation, but there's only one of them. And sharing code across components is possible - but requires work.


A html template used in a Lightning Web Component. A lot less XML!

With Lightning Web Components, life is simpler. Your template is a html file with syntax to allow you to refer to properties and methods in a handler. That handler is written in Javascript that's just like the Javascript you'd see in the likes of NodeJS. It supports ES7 features, including imports - organise code across multiple files and import it where you need it, even outside of the component you're currently working with! No need to use service components to expose shared functions across components.

Referencing server-side functionality - both custom Apex controllers and standard APIs - is a lot simpler too. Import the Apex methods you need and then use them much like you would any Javascript function. Decorators allow you to succinctly pass in parameters to the method, and your code focusses on handling the response.


A Javascript handler used in a Lightning Web Component.

There are a host of changes like this across the framework that really simplify the code you write - there's a lot less boilerplate, and features more in line with standard, modern Javascript development.

What will the benefits be? As hinted above, the main driver for the new framework is to take Lightning to the next level of performance. The framework has been built to leverage features found in modern browsers that will be key to future performance enhancements in Lightning.

Unlike traditional Aura-based components, the new "LWC" model is in line with web components found elsewhere. This means Lightning Web Components should be much more familiar for those who do not currently develop on the platform, and the skills more commonly found - whereas the existing Aura model is not always well-known outside of the Salesforce ecosystem.


This is the E-Bikes sample application, available in the Samples Gallery. We'd highly recommend playing with it for a demonstration of what LWC can do!

It'll help to open up developer tooling. For example, useful IDE plugins thrown off by the syntax, styles and conventions of Aura-based components will now be usable in Salesforce front-end development.

The team behind LWC have also revisited some of the fundamentals of the Aura-model, to rework the way developers accomplish their goals, and encourage best practices. This may just appear as changes to syntax; however, the changes in the model will help eliminate entire classes of bugs, make framework behaviour more predictable, and make developer intent clearer.

There are many other benefits, but you'll be hearing more about those over the coming weeks and months!

Concerns

Now, you may be thinking: "What about all the time I spent with Lightning Components?!" Fret not - the Aura-based model will still be available for you to use, so you can continue developing with what you already know to give you time to transition. Existing Aura-based components and Lightning Web Components will work side-by-side so there will be plenty of opportunity to explore the new model without having to rebuild everything you've worked on in the last few years.

What about the risk of introducing a new UI model in this way? Actually - Lightning Web Components have already been in use for some time. Lightning Base Components are built on the LWC model, so though the new model is only becoming GA in Spring 19, the underlying technology has already been put through its paces.

What should I do next? Firstly - plan how you'll get access to a Spring '19 org, either via pre-release sign up or by planning your sandbox refreshes to make sure you get an org. Once you have access - get reading the development material Salesforce will be making available, and get coding.


Whilst that org is provisioned, have a look at the official announcement which goes into more detail about changes in the technology that are driving this change.


When can we expect Trailhead content? Already available! the Lightning Web Components Quick Start will have you up and running with your first component in no time.

Salesforce have been working on new sample apps to demonstrate LWC - they've also rebuilt the existing apps you already know using LWC, so you can compare the Aura-model with the new. Head to the Sample Gallery to have a look.

If you've come to Javascript via Lightning but not had the opportunity to learn about Javacsript outside of that context, now might be a good time to spend some time learning the core concepts - the Learn to Work with Javascript trail is a good place to learn.

Planning for the Future

You can then explore opportunities where to start using LWC in your applications. You don't need to go big bang and re-write entire applications - there may be small components you can incorporate in a single area of your application, then as you and your team learn, look for opportunities to refactor other components to LWC.

A gradual ramp-up in this way (versus an entire re-write) will help you in the long run. When looking at opportunities to refactor to LWC, treat it as a chance to re-architect your applications rather than trying to copy and paste your components to the new model. Not everything will map neatly across from old to new - some aspects of LWC have been deliberately designed to prevent certain patterns that are available in the Aura-based model. For example, dynamic creation of components (where components are inserted into the page via Javascript) is a feature that is useful in a number of scenarios, but can be the cause of a number of subtle and difficult to trace bugs. Therefore in LWC, a different approach will need to be considered. Not that the same effect cannot be achieved, just that you will need to go about it differently (and that's better for you in the long run!).

We'll be sharing more about our experience with LWC in the coming weeks and months. It's an exciting time to be a Salesforce developer, so we look forward to sharing our stories!

984 views

Recent Posts

See All

Async Component in LWC

Sameed is back at it with a blog post on the application of Lightning Web Components (LWC) to build out an asynchronous component that will be useful in addressing a fairly common real world scenario

Code Reuse in Salesforce Lightning

As part of Mav3rik's ongoing efforts to #raisethebar and #giveback to the Salesforce community, here's the first in a really insightful (and opinionated) series of posts from Sameed on the topic of re

  • LinkedIn - Black Circle
  • Twitter - Black Circle
  • Instagram - Black Circle

© 2020 | mav3rik.com