1

Is it possible to disable Locker Service for Lightning Web Components? For Aura Components it goes like this:

https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/security_ls_disable.htm

This works for Aura Components very well and as expected.

Now, how can we disable the Locker Service for a LWC?

  • Maybe you can share what it is you are trying to do that requires LS disabled (eventhough i dont believe this is possible with lwc) – glls May 15 at 12:52
  • 2
    I think it is not possible. locker service could be disabled only if the API version is below 40.0 and LWC is available only starting from API 45.0 – Oleksandr Berehovskyi May 15 at 13:49
  • @glls see my comment at JPParadis answer. – Uwe Heim May 16 at 4:27
2

In LWC, Lightning Locker is always enabled to enforce code isolation.

https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.security_locker_service

Are you facing an issue with Locker? We monitor these forums and try to address the concerns as they come up.

  • My experience with aura and LockerService was very bad and as a result we did most components in v36.0 having any locker issues out of the way. We usually have to do a lot of DOM manipulations of our own elements with jquery. This works with LockerService somehow but the JS Proxies make debuggin hard and the performance was brutally slow. with v36.0 all is fine. Also we are using stuff like CKEdtior, Cytoscape JS and other huge JS Libs which were hard to make them work even without LS in Aura. But we made it somehow. With LS it would have been either impossible or super slow or too much effort – Uwe Heim May 16 at 4:23
  • btw. with our v36.0 compos we have created also own lightweight containment pattern to e.g. prevent css bleedouts of the compos or unwanted affection of DOM manipulations to sibling compos. but our "micro locker" is way less restrictive and has practicality a zero footprint in terms of performance. it just keeps the guts of the compos to where they belong. – Uwe Heim May 16 at 4:37
  • @UweHeim The immediate option for large libraries is to iframe them. We're also hard at improving Locker performance, so if you have a few examples to post, we will add them to our metrics. We're also removing proxies and your comments show that we are on the right path. – JF Paradis May 16 at 14:55
  • thanks so much sharing this future looking statement. if you like we could indeed share some examples with you. e.g. screenshots or maybe even a managed package to play around with. Especially direct access to google maps would help. I know the new lightning:map and the iframe approach but we need the full unleashed stuff to succeed – Uwe Heim May 16 at 18:56
  • in fact we have heavily used iframing. but this raises the immediate need for a way more powerful visualforce container as the your native is. especially automatic height adjustments to the vf-content is a MUST HAVE. also that we've done. again with a v36.0 aura bundle. but the requirements grow and grow in terms of communication via window.sendMessage() which pushes us to recode everything as v36.0. just need to verify that LWC can't do what v36-aura can. good to learn that you understand that the current locker stops lots of people to proceed with components in general... – Uwe Heim May 16 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.