How LockerService For Lightning Components is Like a School Bully

In Summer ’16 release the new critical update –  LockerService for Lightning Components was introduced by Salesforce. It has already made a lot of buzz and it’s high time to set the record straight.

In few words, this is a security architecture for features and applications built with Lightning components. The LockerServices capabilities look outstanding indeed:  

• Security review becomes faster than ever before
• Secure JS development practices increase and become better
• Adding or removing new security features and policies becomes as easy as that.

In the release notes, Salesforce admits: “LockerService enforces modern JS standards and new security rules. So depending on how the component is built, they will need to be upgraded to meet these standards.We’ll be providing tools and articles to make this transition easy”. Sounds unhazardous, doesn’t it? However, if we go into details, the conclusion then becomes not so firm.

The truth is that the LockerService in any case can break your Lightning components.The wide web is riddled with the admins’ pleading for help and LockerService claims. More than that the Salesforce statement that “LockerService will be auto-enabled for all orgs when Winter ‘17 is released in the October timeframe” makes sweat bullets even the toughest of us.

LockerService is about the DOM- elements security. That makes all libraries work with these elements stumbled over blocking of their performance. As a result,  most of the Lightning components, using JQuery, for instance, in operation with DOM- elements work improperly or are out at all.  

So, what LockerService has in store:

1. The change in performance of standard JS methods, event models, and access to the global methods and objects.
2. The change in the expected methods of downloading third-party scripts (static resources)
3. The challenges with the use of the standard methods of debugging
4. The blocking of third-party libraries
5. The performance changes or blocking of the previous features
6. The change in expected and standard behavior of implemented Lightning methods

To make a long story short, LockerService can be disturbing for those who ignored the Salesforce advice while developing the Lightning components. In that case, comes the reasonable question ‘What should we do next?’. Here in Syntegrico we see 2 possible variants how to break the impasse:

1. Pre-existing components refactoring
2. Developing new components according to the LockerService requirements

To sum up, LockerService seems to be very tempting in terms of product security but very ambivalent in terms of its security features and policies. In order to avoid ServiceLocker to be a nightmare for your processes you need a qualified team that knows Salesforce inside out, to make an audit  to distill the soft spots and take preventive actions.

In case there are blanks in your talent pool, Syntegrico’s experts are here to fill it up. Being a Salesforce PDO partner we are eager to help you to ease the pains of implementing the LockerService and minimize the effects for your processes. Don’t hesitate to contact us with any issues occurring.

Text by Ekaterina Pomazai Salesforce Software Engineer