As an ISV partner we still have to support both Lightning Locker as well as LWS when developing our products. Because not all customers are on LWS or on Lightning Locker and it's not a good product strategy to force the customer to update to LWS to use our components only, this would severely hinders adoption.
And it seems that every week there's a new thing we find that is available in major browser support, that isn't supported in Lightning Locker.
Recently we've had many issues for example with the AbortController to be able to abort a Fetch request. We've had to add a polyfill to our code for that. And now we've discovered that the Headers interface of Fetch is not supported in Lightning Locker... Which means another polyfill.
https://developer.mozilla.org/en-US/docs/Web/API/Headers <- For reference:
"This feature is well established and works across many devices and browser versions. It’s been available across browsers since March 2017."
It's not like it's new either.
Is Lightning Locker being maintained up to date? Is everyone supposed to switch to LWS? How are we supposed to deal with this as an implementor/ISV partner? It would be nice to have an official statement about this.
I know there's eslint plugins files to help with these I think? It would be nice if there was something that strictly scanned our code and told us that X or Y was not supported with Locker or LWS.
I am using a lib we develop internally, and those devs are not just developing it for Salesforce use-case, so they know nothing about potential restrictions of Locker. It's not easy to keep making sure we don't add something to our code that doesn't work with Locker. They do look at browser adoption of features, but from a browser point of view, and Locker is lagging behind.
Good to know we're not the only ones having issues with Locker :)
As I said, this would be less of an issue if Locker was no longer "supported". But AFAIK officially both Locker and LWS are still supported, so as an ISV we HAVE to support both.
And Locker becoming so outdated is making it harder and harder.
@Etienne Rocheleau point taken, this is why I looped in @Greg Whitworth and @Gary Chang, because Locker fixes or improvements require prioritization and resources, and our focus has been LWS (Lightning Web Security).
Yeah, sorry @Etienne Rocheleau for steering the conversation away from the original topic.
We've got a few Locker-related issues, too. Would be nice to have those resolver, too.
For example, the `customElements` API.
Lightning Web Security wraps all globals (Map, Set, Date, etc) in proxies for access control. Instances of those globals are also proxied. When accessing properties or calling methods of those instances, LWS performs various lookups and validations, and applies "distortions". This happens on every single property read/write or method invocation.
Working with large data sets containing date instances then becomes problematic. Some of our components make heavy use of Map and Set to store and manipulate relationships between objects in memory. An example is resource assignment component: projects, tasks, resources, and resource assignments are stored in a graph, which is a map of maps and sets. Projects and tasks also have start and end dates, resources have availability calendars that also contain dates. Put this all together, rendering even a few projects may take _minutes_ in LWS compared to milliseconds in Locker. With the help of those custom polyfills for Map and Set we have managed to improve performance in orders of magnitude. Dates are still a bottle neck though.
@Etienne Rocheleau I have copied Locker/LWS Product Managers and Engineering Managers for their awareness and guidance in regards to Locker.
@Aleksei Murashin can you provide some details about why you had to create polyfills for Map and Set in LWS? In theory, you should't need to do that, so I'd like to understand the motivation. Thanks!
Locker isn't the only issue. We've had to create polyfills for Map and Set globals in LWS!
I wanted to circle back on this. Thank you to @Etienne Rocheleau and @Aleksei Murashin for the time and candid feedback. As we have more to share publicly I'll link it in here.
