-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decorating interface methods. #6818
Comments
Please log issues with enough information for us to understand what's going on. How did |
function tagged(proto, name, d: TypedPropertyDescriptor<any>) {
d.value.tag = 123;
}
class FooImpl {
@tagged
bar() {
console.log("bar");
}
}
const foo = new FooImpl;
foo.bar.tag == 123; Then if we try to come up with an interface definition for interface Foo {
/** This method has .tag property attached. */
bar(): void;
} Having such a comment isn't good enough and the types intersections help us solve the problem to some extent: type Tagged<T extends Function> = T & { tag: number };
interface Foo {
bar: Tagged<() => void>;
} This is pretty good until we decide to extend our class with an overloaded version of /// [file1.ts]
interface Foo {
bar: Tagged<() => void>;
}
/// [file2.ts]
interface Foo {
bar: Tagged<(abc: string) => void>;
} But this doesn't work because /// [file1.ts]
interface Foo {
@tagged
bar(): void;
}
/// [file2.ts]
interface Foo {
@tagged
bar(abc: string): void;
} |
a decorator on an interface does not make much sense. it is an implementation detail, and has no impact on the type anyways. adding the tag to the interface makes it impossible for you to implement it, as again the decorator does not do any type mutations. i think what you are looking for is: #4881 |
@mhegazy Can you elaborate on why this doesn't make much sense? One use case could be something like Retrofit for Android: interface MyAPI {
@GET("/example")
getExampleData(): Observably<ExampleModel>;
@POST("/example")
postExampleData(body: ExamplePostModel): Observable<ExamplePostResponseModel>;
} Do you have any idea how this could be done without interface member decorators? |
Both of those decorators imply some sort of implementation/run-time meta data coupled with an interface. They are fully erasable type information, not implementations. What makes sense about that?
Decorators on a class implementation? |
Any progress? I need them exactly for this purpose #6818 (comment) |
Sometimes it's useful to have methods with properties attached:
The corresponding interface could look like:
The text was updated successfully, but these errors were encountered: