Lightning LockerService and Component Inheritance

(I’m hoping one of the Lightning Component developers will be able to chime in on this, as I’m rather concerned that the LockerService will break code using inheritance)

Salesforce are introducing the LockerService to tighten up security around Lightning Components. One feature of this is:

In addition, custom components will only be able to access public and
documented Lightning JS APIs and won’t be able to access Lightning
framework’s “private” APIs

In order to maximise re-use, I have implemented inheritance in a number of my components, where the sub-component overrides and extends the helper. The functionality is typically triggered from markup in the super component which invokes a controller method. However, as there is only the super-component controller, I have to find a way to access the sub-component helper. The only way that I’ve found to do this is to get the concrete (sub) component in the superclass controller, then access the helper via the concrete (sub) componentDef as follows:

superHelperFunction: function(component, event) {
    var cc=component.getConcreteComponent();
    var subhelper=cc.getDef().getHelper();
    // invoke sub-component helper method

However, ComponentDef has been removed from the Lightning Documentation App some time around Spring 16, which presumably means it is no longer documented and supported. It was there in Winter 16, which suggests it was released by mistake and then pulled, which rather scares me:

  1. When the LockerService is in place, does this mean that making something private and removing from the documentation app will suddenly cause any production JavaScript relying on that to fail? If so, will we be notified that a breaking change of this nature is on its way?

  2. If ComponentDef (and by extension getHelper()) are no longer supported, how are we supposed to access the concrete component’s helper? I can’t find anything suitable in the API documentation, which suggests that I’ll have to replicate the markup and controller methods in my subcomponent, and that doesn’t sound anything like inheritance to me.


LS itself has no direct impact on inheritance or other features in the lightning framework. It does however enforce existing visibility and access rules that previously were unenforceable.

As we’ve gone through the process of developing the service’s secure virtual proxies we have identified a number of places where things were documented but actually not marked correctly as part of our public documentation and in those cases we’ve actually corrected the documentation. we have not removed access to something that was marked as part of the publicly supported API (unless it represented and unsupportable security risk of course – e.g. Document.innerHTML’s getter).

The specific API change you are talking about above occurred long prior to locker service and we’ve been working off of the current set of classes and methods marked with the @platform annotation that indicates that they are part of the publicly supported, API version and surface area. I do know that we never intended for that incantation to be a public part of Lightning.

I am researching now to get more information about the nature of the change with regard to Component.getDef() from the folks that made the change a few releases ago. The pattern your using looks like, correct? We do need a supported way to implement that very useful pattern. For example instead of helpers what about using an interface with aura:method’s that can be implemented in the subs instead (I have not verified this works yet – just an idea)? Helpers are meant to be an internal component detail and the fact that these are “inherited” has never been treated as part of the API – was always a hack or workaround at best.

Also please note that I fully expect the summer 16 lifecycle to include many additional updates to increase what is visible in the locker service. For example the next patch schedule for deployment tomorrow has over 50 additional APIs visible primarily in the secure virtual DOM. Some of these are because we discovered even more inconsistencies between what is marked as platform versus exported. Each and every method, class, property etc. has to undergo a very range of threat analysis depending on the complexity that is being proposed for exposure.

Source : Link , Question Author : Bob Buzzard , Answer Author : Doug Chasman

Leave a Comment