-
-
Notifications
You must be signed in to change notification settings - Fork 753
Closed
Description
I think the ultimate solution would work well for .d.ts-es like:
declare module "background-http" {
/**
* Encapsulates some information for background http transfers.
*/
export interface Task {
/**
* Subscribe for a general event by name.
* @param event The name of the event to subscribe for.
* @param The handler called when the event occure.
*/
on(event: string, handler: (e: observable.EventData) => void): void;
/**
* Subscribe for error notifications.
* @param event The name of the event to subscribe for.
* @param handler A handler that will receive the error details
*/
on(event: "error", handler: (e: ErrorEventData) => void): void;
/**
* Subscribe for progress notifications.
* @param event The name of the event to subscribe for.
* @param handler A handler that will receive a progress event with the current and expected total bytes
*/
on(event: "progress", handler: (e: ProgressEventData) => void): void;
/**
* Subscribe for success notification.
* @param event The name of the event to subscribe for.
* @param handler A function that will be called with general event data upon successful completion
*/
on(event: "complete", handler: (e: observable.EventData) => void): void;
}
}Replacing the @param with @event fails the code completion and suggestions for parameters in some IDEs. Using @event somewhere would be fine (though it would appear as plain text in the suggestions but the same is valid for @return) I would be more comfortable setting the "on" and "addEventListener" names as parameters to the tool rather than adjusting my .d.ts-es.
Currently the oversloads for the above methods are displayed nicely, but when the @event is used instead of @param for the first paramter, all parameter documentation display the doc from the first overload declaration. I guess I am doing something wrong?
It would be nice if this could be added in the documentation.
Metadata
Metadata
Assignees
Labels
No labels