1

Closed

JSDoc Interface Linking

description

With the current JSDoc implementation, you can specify comments in an interface as well as above methods of a class. When dealing with libraries like AngularJS, services are injected through dependency injection.

Assigning a DI services' type to an interface that has JSDoc comments in will give full Intellisense completion. However, if the class itself that will be injected via Angular calls any methods within that class, you do not get Intellisense completion unless you have additional JSDoc comments above the methods in the class.

While it is possible to achieve the end goal here, Intellisense in DI Angular services and Intellisense in the class itself, maintaining the two separate comments is less than ideal and on larger projects is simply not feasible.

My suggestion is that if a class implements an interface, the JSDoc comments that are placed above public methods in the class should automatically be mapped to the interface. This would solve the problem that I have outlined.

The reasoning behind this is that placing the comments above the methods rather than in the interface appears to be the most logical place to put them, as you would do just the same for any private methods a class contains. The only downside I can see to this is that pressing F12 on a DI service method would take you to the interface that has no comments, but I think the benefits far outweigh this pitfall.

I'm reasonably new to TypeScript, so I may have missed something here, but I think that this feature would be a great addition to the project.
Closed Sep 18, 2013 at 10:28 PM by danquirk

comments

danquirk wrote Sep 18, 2013 at 10:28 PM

This seems by design to me, although it's not clear to me how exactly you're imaging this working. Perhaps some sample code would clear things up? More specifically, when you say this:

"My suggestion is that if a class implements an interface, the JSDoc comments that are placed above public methods in the class should automatically be mapped to the interface. This would solve the problem that I have outlined. "

what will happen when multiple classes implement that interface? And how do they get coalesced with comments on the interface members themselves?

Please re-open this if I've misunderstood.