Sonoma Partners Microsoft CRM and Salesforce Blog

Lightning Locker Service and You: Working with SecureDOM

Today's blog post was written by Nathen Drees, Senior Data Integration Developer at Sonoma Partners.

One of Salesforce’s recent major releases is the force enablement of the Lightning LockerService. While Salesforce has done their best to give plenty of warning about the LockerService being force enabled, we still see some of our partners and developers confused about what exactly it is, and if it affects them.

Today we wanted to review what the LockerService is, provide context for when it will affect you, and some recommendations on working within it.

What is the Lightning LockerService?

When Salesforce released the Lightning Experience, it had a vision for the AppExchange: developers could write lots of tiny components, and administrators could install them in their org, promoting code reuse and reducing the need to hire for custom development. It was a win-win proposition for both parties – developers have more chances to sell their individual widgets, while administrators have more options to choose from. But this vision comes with a problem: for this exchange to work, Salesforce needs to guarantee that the various components installed by administrators stay safe from one another, to prevent (accidental or otherwise) runaway scripts from causing too much damage. Unfortunately, browsers don’t natively provide a way for multiple scripts within a page to be sandboxed from one another – everyone has access to (more-or-less) everything on the page.

SFDC_Lightning_Locker_service_blog

Enter Lightning LockerService

This is where the Lightning LockerService comes in to play. It provides each lightning component a “locker” that is must fit within, stricter guidelines on what it’s allowed to do, and how it can communicate with other components.

Here’s a comprehensive introduction to the technical aspects of the LockerService on the Salesforce blog, but the key idea to understand is that components are not able to access anything on the page at any time. If components wish to communicate, they  need to coordinate in some agreed upon manner (such as application events).

Does the Lightning LockerService Affect Me?

If you write Lightning Components, the Lightning LockerService affects you.

Going forward (API version 40+), you will need to ensure that your components adhere to the LockerService’s rules or you may find that they no longer function as expected. However, adhering to the LockerService’s rules isn’t as difficult as it may seem.

Working Within the Lightning LockerService

If you are sticking to the native APIs provided by Lightning Components, enabling the LockerService doesn’t change much for you during development. The main area it impacts is when you try to navigate out of your current component into another – this may no longer work as expected, specifically if those other components are not in the same namespace as yours.

In an attempt to help developers ensure that they’re staying within the guidelines (and also pass a security review), Salesforce released the Salesforce Lightning CLI, which lints the components for known errors and mistakes. Using this tool liberally will help to avoid the common cross-component scripting mistakes that may break your components going forward.

If you do need to work across components, you need to start designing and writing events to let the components communicate amongst themselves. Depending on the structure of the components, you’ll want to consider either an application event or a component event.

Wrapping Up

There are of course many more tricks for making sure your components continue to work with the LockerService, most of them being not very difficult to implement. If you would like help reviewing and/or correcting your components, or are looking to launch your product on the platform but could use the help of experienced developers, contact us and we can help.

Topics: ISV for CRM Salesforce