Request: Class Decorator Mutation
See original GitHub issueIf we can get this to type check properly, we would have perfect support for boilerplate-free mixins:
declare function Blah<T>(target: T): T & {foo: number}
@Blah
class Foo {
bar() {
return this.foo; // Property 'foo' does not exist on type 'Foo'
}
}
new Foo().foo; // Property 'foo' does not exist on type 'Foo'
Issue Analytics
- State:
- Created 8 years ago
- Reactions:1094
- Comments:242 (53 by maintainers)
Top Results From Across the Web
Instancing class with an without new with a class decorator
Unfortunately, decorators don't mutate the types of the things they decorate in TypeScript. That means the Someone constructor will not be ...
Read more >Documentation - Decorators - TypeScript
A Decorator is a special kind of declaration that can be attached to a class declaration, method, accessor, property, or parameter. Decorators use...
Read more >Top 5 vuex-module-decorators Code Examples - Snyk
Learn more about how to use vuex-module-decorators, based on vuex-module-decorators code examples created from the most popular ways it is used in public ......
Read more >GraphQl-Decorator - GitHub Pages
GraphQl-Decorator · Model class to define how the schema will be. · Resolver class to create query/mutations. · A function defined by you...
Read more >Resolvers - TypeGraphQL
After that we can use the AddRecipeInput type in our mutation. We can do this inline (using @Arg() decorator) or as a field...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Same would be useful for methods:
The async decorator is supposed to change the return type to
Promise<any>
.If the primary benefit of this is introducing additional members to the type signature, you can already do that with interface merging:
If the decorator is an actual function that the compiler needs to invoke in order to imperatively mutate the class, this doesn’t seem like an idiomatic thing to do in a type safe language, IMHO.