Ember.js plugin: Inheritance

I'm working on the Ember.js plugin for IntelliJ at https://github.com/Turbo87/intellij-emberjs and was wondering if I could hint IntelliJ on how to handle the Ember.js inheritance pattern.
A component in Ember.js is basically defined like this: https://github.com/rust-lang/crates.io/blob/master/app/components/crate-row.js. After that you can use `{{crate-row}}` in the Handlebars templates and it will delegate to that component automatically due to the filename and path.
In the example file above there is the `.extend()` method on `Ember.Component` that is basically used to create a subclass, but unfortunately IntelliJ doesn't know about that. If I create another subclass and use that as a base class for other components IntelliJ doesn't know about the properties of the base class when I'm writing code in the top-level class. Is there some way that I could teach IntelliJ about this?

Hi Tobias,

can you provide a sample with inherited component and where you are expecting properties of the base class?



You can find one example of this pattern at https://github.com/skylines-project/skylines/blob/59e15413de88cb9c8a24b2b582d4f0685326f76f/ember/app/routes/flights/pilot.js

The `flights/pilot` route is using `extend()` to inherit from a base class that is imported through a relative ES6 import. The base class itself is using `extend()` to inherit from the `Ember.Route` class, which again is extending the `Ember.Object` class where the `extend()` method is introduced.

The `Ember.Object.extend()` method is documented at http://emberjs.com/api/classes/Ember.Object.html#method_extend

Please let me know if you have more questions about this. 


In general it should work like this:

  1. You need to register FrameworkIndexingHandler
  2. Provide type name for object literal in extend call by implementing resolveContextFromProperty
  3. Set up inheritance via outData.setBaseType from that type name to the extended type name
  4. Make sure that inherited type is passed through import binding by implementing addTypeFromResolveResult and resolving binding.

The only problem here is that on step 2 type name doesn't exist yet, it will appear only when element is imported. We're experiencing same problem when unnamed class is default-exported. I've created WEB-23253 for that problem, please follow it for updates, we're planning to fix it in 2016.3 release cycle


Interesting, I've stumbled upon the `FrameworkIndexingHandler` class a few times already but haven't figured out yet what functionality it provides or how it can be used. Are there any docs available on that? 


Sorry, no docs yet :(

Mostly it's used to provide some implicitly present elements during indexing and additional type information during types processing (that happens during completion/navigation)

Angular plugin is quite a heavy user of the FrameworkIndexingHandler and can be used as an example


I guess what I'm asking is: Whats the difference to the FileBasedIndex and the StubIndex?


The docs for platform are definitely better: FileBasedIndex and StubIndex


Ah sorry, what I meant was: how is the FrameworkIndexingHandler different from the other two?


Ok) FrameworkIndexingHandler is not a third way to index but rather an extension to those two specific for JS. process* methods are called during JS stub building so that framework specific information can be stored during indexing. 


Please sign in to leave a comment.