The Hurt Locker
But What if I Really, Really Need To ...
Now obviously I’m not Salesforce, so I can’t say for sure if they will make any exceptions, but I’d be pretty surprised if they do. The Locker isn’t closing down loopholes because they are worried the world may be blinded by the sheer awesomeness of your solution. Loopholes are being closed because they are a security risk, and whitelisting applications to punch holes in security is unlikely to make customers feel safe.
It’s So Unfair - I Hate You!
- This should have been in place from the start
It’s all well and good putting warnings in the docs, but out in the real world people have hard deadlines and requirements, and not everyone reads the docs before making a questionable decision. I’m sure there are some customers out there who have components where the original developer has since departed or was never on staff. If their components are using anything that the Locker takes issue with, they could lose key functionality without the in-house skills to replace it.
If you think about it, this is like carrying out a Salesforce implementation and giving every user System Administrator privileges with a warning not to rely on them, then coming back after a year or two and changing them to a Standard User. While you can say that you warned them, and its not your fault if their business processes relied on their elevated privileges, you aren’t going to be popular.
- Should we expect breaking changes?
I’m raising this as its something which I think I’m likely to fall foul of. To use inheritance in Lightning Components I’m making use of the component.getDef() method to access the ComponentDef and then executing the getHelper() method. However, ComponentDef has been removed from the Lightning documentation app, which suggests that it isn’t supported - per Skip Sauls reply in this thread:
But here’s the rub - this did appear in the documentation, and then it went away. So where does that leave me? I’ve raised this on Stack Exchange where I know a lot of the Lightning team lurk, so if I get an answer I’ll update this post.
- I Want Workarounds!
Thus far I’ve seen mentions of tools, blogs, articles and Trailhead modules to help us get to grips with this. What I haven’t seen mention of is alternatives. If I’ve gone to the open source Aura project to figure out how to do something, and that turns out to be a private API, I’d like a workaround providing equivalent functionality rather than just being told I can’t use it any more. I only resort to the Aura source if the documentation app isn’t helpful (sadly this happens more than you’d expect, as there are still a number of entries that just have the method signature/component name and no additional information).
There’s an app for that
If news of the Locker makes you fear for your code, there’s an app (or more accurately, a command line tool) that can give you some succour - the Lightning CLI. I’ve run this on some of my components and it has raised a few things that I need to take care of (although doesn’t have a problem with ComponentDef mentioned above, but I’m not reading too much into this at the moment).
The Hurt Locker? Seriously?
Like I could leave that alone!
- Introducing The LockerService For Lightning Components
(The official Developer Relations blog post that scared me!)
- Lightning CLI Package home page