Decorators are a double edged sword and should be used sparingly and carefully, in my opinion. I think that the log example is fine, but the more complex the code decorators become the harder it will be to reason about what on earth the code does. Sometimes code that is a little bit verbose is better, simply because you will be able to read it 2 years from now without looking for the decorator or for the documentation.
The worst part is probably mutability. Since decorators have access to the class context, it's very easy to mutate those classes, making debugging more difficult. I still prefer pure higher-order functions and composition over method decorators. The win here is that they also work with any other function, not just class methods.
Decorators have been around since the days of Angular (or Angular v2). They use it quite extensively as an essential, fundamental element of their platform. Now, I know it's been in the experimental stages during all that time, and I'm assuming TypeScript 5.0 is basically just making it an "official" feature that's finally out of the experimental stage. What I'd like to know is why it took so long when this feature is already used by so many frameworks and platforms ranging from the previously mentioned Angular, to NestJS, Lit, and so on?
@@toxaq No, they don't. Vanilla TypeScript decorators do need to be enable in tsconfig in order for them to work since they are (or were) considered experimental, but that's it. Angular has always had them by default since Angular v2. That's what @Component and @NgModule are.
@@bigk9000 interesting. I seem to recall there were issues early on in Angular 2 that meant you couldn't compile it outside of it's own compiler and some of that was related to the decorator portions. Seems I was wrong
@@toxaq What you are remembering(i think) is that angular 2 alpha/beta used to be written in dart rather than typescript. they switched over before release (or at least had both available)
No, you'll be able to decorate classes, class methods and class properties / getters / setters / fields (unfortunately you can't use decorators for method parameters as in TS 4.x)
Super weird restriction considering the JS community never picked up classes and the rest of the world in the process of detoxing from class-based oop.
Interesting thing would be...is there actually type checking happening when using the decorator? E.g. the @limit decorator can only be applied, when the method attaching to it actually has a first parameter of type Array. I would expect in that case that TS throws a compile error
This reminds me of decorators in Pyhon that were extremely confusing, from what I understood from my python peers (it’s not my language), it’s supposed to be a scary and widely abused feature. Let’s see how the TS community will handle it.
Decorators aren't inherently bad, it's just that if you're ever in a a position to write one you should triple-check whether or not there exists a simpler way to solve the problem. Otherwise, decorators can allow for insane productivity boosts. Just look at a Python framework like FastAPI and a JS one like Express. The gap in developer speed is noticeable, to say the least.
I would also explicitly type the return type of the logger meghod to enforce that the return function has the same signature as the original one. Otherwise nice video
It already does! Our replacement method must match the `Fn` type, which is the target method. So if you have the wrong return type, TS will complain. Now you've got me thinking, though: you could also create decorators for specific return types, as well as specific arguments ...
Is there some sort of functionality that decorators provide that cant be achieved with currying? Granted I never use classes but this seems like it would just be semantic sugar to me.
Decorators moves the responsibility up to the call site, rather than down to the caller. It also adds additional context (the class itself) which may or may not be beneficial if you work with class-based systems. This has arguably a downside of being able to introduce unintended side-effects and mutation of said class. I personally just stick with higher-order functions for composition and if I need to repeat myself at every call, I can just create another function. The benefit is that I am not tied to class-based systems, as they work any standalone functions. I don't personally think decorators is the right way to design an API or write application code.
@@dealloc I think it's fine to change the class as long as the contract represented by the class is kept. I think decorators are excellent for basically "tagging" properties/method/classes/parameters. Basically the equivalent of java annotations. The difference is that in type/javascript it allows you to process those tags without any requiring either runtime reflection or processing at compilation time (which has it's positives/negatives).
@@lengors7327 Decorators can mutate classes in ways that is incompatible with its contract and you can no longer guarantee that properties, methods and even the class itself conforms to those contracts. It's not even possible for TypeScript to ensure that the contract is held up, because it happens at runtime. For example. "tagging" can be done in different ways, but is typically done with reflection ("Reflect") to add metadata about the property, method or class. This has some downsides, and looking past the negative effect on runtime it has, it also now introduces the side effect of saving and retrieving said metadata whenever the property is accessed, method is called or class is instantiated. Side-effects are just the top of the problem. You also have to understand in what order cretain decorators are called; since they are not called in order of declaration, but based on what they are attached to. For example, the class decorator is only called _after_ all method and field decorators are called and applied, and then at last static fields are executed and applied. This adds a ton of indirection, become hard to debug when something goes wrong, etc. Decorators has a niche usage, and in most cases can be replaced with just wrapping your method calls in reusable functions.
Sort of, but java annotations just tag whatever is their target. You then need either reflection or processing at compile-time. Here you are basically allowing yourself to do the latter at runtime
I wonder how people like to get into trouble with all this OOP craziness. This syntax looks absolutely crazy and not easy to read. You can achieve the same result with function composition using a "more fp" paradigm. Mine is not a criticism of the explanation (which I find excellent) but of the Javascript language itself and how in recent years it is pushing more and more to make it look like a legacy oop-like language. I think that all this classy syntactic sugar only complicate things, hiding its true nature.
Hi fellow, As your code base gets bigger, it becomes more difficult to handle it if you did not apply OOP paradigm. Don't take it for granted:). initially, it can be scary, but you need to have patience to understand the code and comprehend this. But as time goes by, it will become easier, and you will understand the strength of this paradigm, and you wont get back to old school way of coding.
Наука
I like the idea of decorators, just not that they are tied to classes. The way I write TypeScript these days just doesn't involve classes at all.
Same, to be honest. I’m pretty sure the ES proposal is for all functions, so when that goes through, TS will have to follow.
Ahah! I thought I recognized you from somewhere. I remember watching several of your JavaScript tutorials over 10 years ago! Great content!
so cool! i think im going to have to watch this a couple of times haha
Supercool video, you are a fine developer!=)
Your Vim setup is very cool. Thank you for the video.
Thanks! If you want more details on the setup: shaky.sh/tools/
time to add this to tree-sitter-typescript
Absolutely gold
Decorators are a double edged sword and should be used sparingly and carefully, in my opinion.
I think that the log example is fine, but the more complex the code decorators become the harder it will be to reason about what on earth the code does. Sometimes code that is a little bit verbose is better, simply because you will be able to read it 2 years from now without looking for the decorator or for the documentation.
The worst part is probably mutability. Since decorators have access to the class context, it's very easy to mutate those classes, making debugging more difficult.
I still prefer pure higher-order functions and composition over method decorators. The win here is that they also work with any other function, not just class methods.
@@dealloc I agree, unless there are real performance reasons to avoid it, I will always pick this approach.
Decorators have been around since the days of Angular (or Angular v2). They use it quite extensively as an essential, fundamental element of their platform.
Now, I know it's been in the experimental stages during all that time, and I'm assuming TypeScript 5.0 is basically just making it an "official" feature that's finally out of the experimental stage.
What I'd like to know is why it took so long when this feature is already used by so many frameworks and platforms ranging from the previously mentioned Angular, to NestJS, Lit, and so on?
Angular decorators are a custom extension are they not? That’s why it needs its own cli.
@@toxaq No, they don't.
Vanilla TypeScript decorators do need to be enable in tsconfig in order for them to work since they are (or were) considered experimental, but that's it.
Angular has always had them by default since Angular v2. That's what @Component and @NgModule are.
@@bigk9000 interesting. I seem to recall there were issues early on in Angular 2 that meant you couldn't compile it outside of it's own compiler and some of that was related to the decorator portions. Seems I was wrong
@@toxaq There may have been, honestly. Angular 2 was a while ago, and I didn't jump on board until Angular 4.
@@toxaq What you are remembering(i think) is that angular 2 alpha/beta used to be written in dart rather than typescript. they switched over before release (or at least had both available)
ZOD, Zod with decorators will be WILD!
pretty sure that exists already
I have a feeling react hook days are numbered and we will be back to using classes and decorators
Wait, they only work on Class methods? That seems shortsighted....
No, you'll be able to decorate classes, class methods and class properties / getters / setters / fields (unfortunately you can't use decorators for method parameters as in TS 4.x)
Super weird restriction considering the JS community never picked up classes and the rest of the world in the process of detoxing from class-based oop.
Nice video, Where does ContextMethodDecoratorContext come from?
Interesting thing would be...is there actually type checking happening when using the decorator? E.g. the @limit decorator can only be applied, when the method attaching to it actually has a first parameter of type Array.
I would expect in that case that TS throws a compile error
It does! I should have showed that, but yeah, you’ll get a compile error if you tried to say, add @limit to the intro method.
This reminds me of decorators in Pyhon that were extremely confusing, from what I understood from my python peers (it’s not my language), it’s supposed to be a scary and widely abused feature. Let’s see how the TS community will handle it.
I wouldn't say it's scary, but absolutely abused.
Yeah they are the exact same thing.
Decorators aren't inherently bad, it's just that if you're ever in a a position to write one you should triple-check whether or not there exists a simpler way to solve the problem. Otherwise, decorators can allow for insane productivity boosts. Just look at a Python framework like FastAPI and a JS one like Express. The gap in developer speed is noticeable, to say the least.
Is there a difference between the types
a: Array
b: any[]
?
Nah, its the same
I remember using this in nestjs. Wasn't this available under a flag in older versions or something?
Yeah, I think decorators were available behind an experimental flag in previous versions. They’ll be a “first class” feature in TS5.
what plugin do you use for showing current function at winbar? (filename -> func name)
it might be lspsaga
Thanks for the video. BTW, may I know the vscode extension you use to show the "🟥Duplicate function implementation" message on the vsc editor?
This is actually Vim, but either way, it’s the basic typescript LSP plugins.
@@andrew-burgess thanks for your reply.. :)
@@fullstackspiderman you can find an equivalent on vscode, it's Error Lens :) !
@@Twiiniil thank you sir
what type of code editor it is?? nice way of error illustration.
They should have went with full AOP like in java.
I would also explicitly type the return type of the logger meghod to enforce that the return function has the same signature as the original one.
Otherwise nice video
It already does! Our replacement method must match the `Fn` type, which is the target method. So if you have the wrong return type, TS will complain.
Now you've got me thinking, though: you could also create decorators for specific return types, as well as specific arguments ...
Is there some sort of functionality that decorators provide that cant be achieved with currying? Granted I never use classes but this seems like it would just be semantic sugar to me.
Decorators moves the responsibility up to the call site, rather than down to the caller. It also adds additional context (the class itself) which may or may not be beneficial if you work with class-based systems. This has arguably a downside of being able to introduce unintended side-effects and mutation of said class.
I personally just stick with higher-order functions for composition and if I need to repeat myself at every call, I can just create another function. The benefit is that I am not tied to class-based systems, as they work any standalone functions.
I don't personally think decorators is the right way to design an API or write application code.
@@dealloc I think it's fine to change the class as long as the contract represented by the class is kept. I think decorators are excellent for basically "tagging" properties/method/classes/parameters. Basically the equivalent of java annotations. The difference is that in type/javascript it allows you to process those tags without any requiring either runtime reflection or processing at compilation time (which has it's positives/negatives).
@@lengors7327 Decorators can mutate classes in ways that is incompatible with its contract and you can no longer guarantee that properties, methods and even the class itself conforms to those contracts.
It's not even possible for TypeScript to ensure that the contract is held up, because it happens at runtime.
For example. "tagging" can be done in different ways, but is typically done with reflection ("Reflect") to add metadata about the property, method or class. This has some downsides, and looking past the negative effect on runtime it has, it also now introduces the side effect of saving and retrieving said metadata whenever the property is accessed, method is called or class is instantiated.
Side-effects are just the top of the problem. You also have to understand in what order cretain decorators are called; since they are not called in order of declaration, but based on what they are attached to. For example, the class decorator is only called _after_ all method and field decorators are called and applied, and then at last static fields are executed and applied.
This adds a ton of indirection, become hard to debug when something goes wrong, etc.
Decorators has a niche usage, and in most cases can be replaced with just wrapping your method calls in reusable functions.
there's a This helper type?! my code could have been more generic :(
Yeah! Check this out for more: ruclips.net/video/Px7qbmFipLE/видео.html
Neovim ftw
is it like java annotations?
The syntax is, not sure about the behaviour. I haven't used Java annotations much.
Sort of, but java annotations just tag whatever is their target. You then need either reflection or processing at compile-time. Here you are basically allowing yourself to do the latter at runtime
I wonder how people like to get into trouble with all this OOP craziness. This syntax looks absolutely crazy and not easy to read. You can achieve the same result with function composition using a "more fp" paradigm.
Mine is not a criticism of the explanation (which I find excellent) but of the Javascript language itself and how in recent years it is pushing more and more to make it look like a legacy oop-like language. I think that all this classy syntactic sugar only complicate things, hiding its true nature.
Hi fellow, As your code base gets bigger, it becomes more difficult to handle it if you did not apply OOP paradigm. Don't take it for granted:). initially, it can be scary, but you need to have patience to understand the code and comprehend this. But as time goes by, it will become easier, and you will understand the strength of this paradigm, and you wont get back to old school way of coding.
It looks like a very verbose way to write a higher order function
please no, its called a function