I've been trying to build a Lightning Community where I use component inheritance and interfaces to share certain bits of functionality. For my particular use, composition wouldn't fit as well as inheritance, so that's not really an option.

As I dig into it, interfaces seem a bit pointless.

The big gotcha in this whole topic is that the blog here: https://developer.salesforce.com/blogs/developer-relations/2015/03/salesforce-lightning-components-by-example-component-extension.html no longer works as it relies on methods that have since been removed from the public API.

So, I tried a few things. I created the following interface:

<aura:interface description="A test interface">
    <aura:attribute name="example" type="String" default="" description="An example attribute."/>
    <aura:attribute name="exampleMethod" />

And then used it in the following component:

<aura:component implements="c:TestInterface">


Shouldn't that be a compile-error? Or a run-time error? I haven't implemented the attribute or method specified in the interface.

And, then we turn to attempting to use an instance of my component. Say, I have a reference to my component elsewhere and I want to call exampleMethod() on it. I'd expect to write something like this:

    if(component.instanceOf('c:TestInterface')) {

Except that, component.instanceOf() is no longer a public method in Lightning (just like getDef() from the blog above), so I can't write that.

EDIT as Christian Menzinger the correct name is isInstanceOf() and it does work, so this criticism is invalid. Which actually makes me slightly happier

So, I end up writing:

    if(component.exampleMethod) {

Which seems to make the interface entirely pointless. Or, am I missing the point?


1 Answer 1


I agree - interfaces in Lightning Components are kind of lenient and JavaScript is not enforcing strict typing anyway. Most important things about interfaces in my opinion:

  • polymorphism: use component.isInstanceOf('c:TestInterface') which is supported by the components API (resp. see your [mydomain].lightning.force.com/auradocs/reference.app on your org)
  • when a component implements an interface all attributes will be 'created' by the compiler in the background, so the attributes will be available at runtime - say no need to really 'implement' the contract from the interface by yourself
  • most common use case: marker interfaces - the advantage is in documenting your components. By using an interface you define a certain use case your component is gonna to be used for. Have a look at all the interfaces provided from the framework - if you want to have your component available in AppBuilder, give your component the appropriate interface - no more work to do (as the rest is clued together in the background as mentioned). The more complex your scenario will be (like as an ISV building bigger products containing tens or even more then hundred components) you can mark functionality and have groups of components. When it's getting more dynamic and generic, you will see more meaningful use cases for it
  • I think you still can declare <aura:method> in the interface - but you have to implement it in the concrete class as you need a controller function reference to be called. Even if it is not enforced, compile-checked or supported the most important reason for me doing this is developer documentation, again.

Long story short: Interfaces behaving different (btw. same to inheritance) as maybe known from other languages but if you understand for what they could be used they are useful though.

  • 1
    Thanks, some good points there. I wouldn't have been so frustrated with them, had I realised that instanceOf() wasn't working just because I had the wrong name. Without that, they really are pointless. But, with it, you have listed some of the good use-cases, so thanks!
    – Aidan
    Commented Jul 7, 2017 at 12:25
  • If it doesn't enforced or compile-checked today, can they ever do it at all? Given developers out there are using it today, someone could have missed to implement certain interface methods in components that implement them, so if enforced in the future, potentially all those implementations will break? So better not to use it at all? Commented Oct 10, 2018 at 11:17

You must log in to answer this question.

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