3

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?

Improve this question
3
  • 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, 2019 at 12:52
  • 3
    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, 2019 at 13:49
  • @glls see my comment at JPParadis answer.
    – Uwe Heim
    May 16, 2019 at 4:27

1 Answer 1

Reset to default
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.

Improve this answer
12
  • 1
    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, 2019 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, 2019 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, 2019 at 14:55
  • 1
    @UweHeim, thanks for sharing that feedback. The browser API is large, and we focus on what we hear is important, so please do share your examples. For iframes, we could accelerate the port of lightning:container to LWC: developer.salesforce.com/docs/atlas.en-us.lightning.meta/…
    – JF Paradis
    May 17, 2019 at 13:49
  • 1
    For starters, you could fix Range.setStart(), a bug in locker which has been outstanding for two years, which hardly fits the definition of "as they come up". If you're going to essentially rewrite the entire DOM API to "improve it", then at a bare minimum you should have extensive unit tests which would of course include the Range API, which would have turned up this and other bugs (such as commonAncestor) before they even shipped.
    – kamezaburo
    Jan 8, 2021 at 18:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .