The mapped type might be more succinct and useful if it didn’t have an “extends” in the keys and the original types were actually used. For example: type MyType = { [K in key of T as `on.${Capitalize}`]: (value: T[K]) => any } When you iterate over the keys of some generic object, TS assumes that it’s “symbol | string | number”. While these types aren’t strings, they’re still “string able”, i.e. you can use them in template strings like `prefix.${string | symbol}`. You could also “assert” that the key should be a string by using extract, e.g. Extract. This automatically “returns” never if the key isn’t a string. It’s just a bit neater than having a nested extends directive; those should probably be reserved for omitting keys based on the original value.
Great interesting video and really well explained. But also this is why I think typescript is awefull and can become extremely hard to read. In a fully typed language you would just have a class for every event inheriting from a common parent class. You would have a service which has an overloaded onEvent method for each Event and you are fine.
Amazing content. I'd like to know how did you setup that " // ^? " functionality to see type information permanently in the editor. You used it in previous videos. Is it a plugin? I can't find out anything about it and it doesn't work in VSCode and IntelliJ
@@tngerik14Thank you. I‘ve created a plugin called „WiTT“ and you can download it from the Marketplace in IntelliJ. plugins.jetbrains.com/plugin/23294-witt--typescript-type-hints-like-in-the-ts-playground For VSCode there is a plugin called „vscode-twoslash-queries“ 👍 marketplace.visualstudio.com/items?itemName=Orta.vscode-twoslash-queries
@@tngerik14 Just a quick update. I've added the possibility to use it in Vue Scripts and sent it to Jetbrains for review. Will give an update as soon as it's available. Or just install the current version and get the update with vue support automatically. :)
@@Typed-Rocks Terrific! I looked into the repo for the vscode extension and there is an open issue to this topic too. But seems like there are some limitations and it can't be supported right now. Unfortunately I use vscode more often but your extension is even better. Less laggy, shows more characters...
Dear lord, just use an interface. This is why Typescript code bases become unreadable. It's good information, don't get me wrong. But it isn't a great example of how to apply this.
Thanks for your comment. How would you do it? A type is basically the same as an interface. Could you provide me an example how you would do other? I would love to get ideas 😎. This is an example similar how typescript itself shows by the way. www.typescriptlang.org/docs/handbook/2/template-literal-types.html
Maybe it depends on the context 🤔. Based on the example, it seems that events is more of a collection that has operators. Each operator has a name "add", "remove" and a action "onAdd" etc. Maybe it's best to make an operator interface that has a name and action method and then inject or instantiate that into the events type/class. Then we need not worry about the names 🤔 Cool example tho.
It looks like an anti-pattern in typing. You are writing code in types. Types should describe the data, not the process of acquiring it. Use “if” and generalization in code, not in types.
But then we cant make our code typesafe that easy. We would need to check if every „on“ method exists and there would be no way in adding things like auto completion
@@Typed-Rocks You just need to maintain the OnEvents type manually. This can be a bit annoying, but your types will be simple and clear. Also, in your case, adding a move property to the Event will force you to implement an onEvent method, but you may not need that
If its optional then you could make the mapped typed with a „?“. For me personally I would rather have the type generated and dont have to change types everywhere when I change the basetype. But it depends on the taste :)
The mapped type might be more succinct and useful if it didn’t have an “extends” in the keys and the original types were actually used. For example:
type MyType = {
[K in key of T as `on.${Capitalize}`]: (value: T[K]) => any
}
When you iterate over the keys of some generic object, TS assumes that it’s “symbol | string | number”.
While these types aren’t strings, they’re still “string able”, i.e. you can use them in template strings like `prefix.${string | symbol}`. You could also “assert” that the key should be a string by using extract, e.g. Extract. This automatically “returns” never if the key isn’t a string. It’s just a bit neater than having a nested extends directive; those should probably be reserved for omitting keys based on the original value.
Looks great
Great video! Short and interesting, very valuable knowledge. Subbed! :)
Waiting on the definitive `never` video...
Thank you 🙏 Working on it
@@malvoliosf its there 👍. Thanks for the suggestion
와! 너무 재밌게 봤어요. 구독 완료하였습니다.
Fascinating video. I'm really looking forward to learning more.
Amazing explanation.
Great interesting video and really well explained. But also this is why I think typescript is awefull and can become extremely hard to read. In a fully typed language you would just have a class for every event inheriting from a common parent class. You would have a service which has an overloaded onEvent method for each Event and you are fine.
Nice video with great explanations. By the way, what IDE do you use?
@@TimaGixe Thank you, I use IntelliJ
Extract does the same as the extends and doesnt need the ternary. Makes it a bit cleaner, credits go to ChatGPT ;-)
You can also do "K in keyof T & string".
Interesting. Will check it out 👍
Nice video. First time watching you. Thank you algorithm.
PS: what's the blue concentric circle with red up arrow in your editor?
Replying just in case someone responds
This points to the type where this property has its type origin. When I click on it it redirects me to the type.
Amazing!
Cool! What if one of the properties Events are optional?
Then your on type will also be optional 👍😎
Amazing content.
I'd like to know how did you setup that " // ^? " functionality to see type information permanently in the editor. You used it in previous videos. Is it a plugin? I can't find out anything about it and it doesn't work in VSCode and IntelliJ
@@tngerik14Thank you. I‘ve created a plugin called „WiTT“ and you can download it from the Marketplace in IntelliJ.
plugins.jetbrains.com/plugin/23294-witt--typescript-type-hints-like-in-the-ts-playground
For VSCode there is a plugin called „vscode-twoslash-queries“ 👍
marketplace.visualstudio.com/items?itemName=Orta.vscode-twoslash-queries
@@Typed-Rocks Thank you! But there is probably no way it can work within Vue's script section, right?
@@tngerik14 Currently not. But I will check if I can support it. Great idea 👍
@@tngerik14 Just a quick update. I've added the possibility to use it in Vue Scripts and sent it to Jetbrains for review. Will give an update as soon as it's available. Or just install the current version and get the update with vue support automatically. :)
@@Typed-Rocks Terrific! I looked into the repo for the vscode extension and there is an open issue to this topic too. But seems like there are some limitations and it can't be supported right now.
Unfortunately I use vscode more often but your extension is even better. Less laggy, shows more characters...
Good video
nice, subbed.
DRY codes are awesome
Dear lord, just use an interface. This is why Typescript code bases become unreadable. It's good information, don't get me wrong. But it isn't a great example of how to apply this.
Thanks for your comment. How would you do it? A type is basically the same as an interface. Could you provide me an example how you would do other? I would love to get ideas 😎. This is an example similar how typescript itself shows by the way. www.typescriptlang.org/docs/handbook/2/template-literal-types.html
Maybe it depends on the context 🤔.
Based on the example, it seems that events is more of a collection that has operators.
Each operator has a name "add", "remove" and a action "onAdd" etc.
Maybe it's best to make an operator interface that has a name and action method and then inject or instantiate that into the events type/class. Then we need not worry about the names 🤔
Cool example tho.
It looks like an anti-pattern in typing. You are writing code in types. Types should describe the data, not the process of acquiring it. Use “if” and generalization in code, not in types.
But then we cant make our code typesafe that easy. We would need to check if every „on“ method exists and there would be no way in adding things like auto completion
@@Typed-Rocks You just need to maintain the OnEvents type manually. This can be a bit annoying, but your types will be simple and clear.
Also, in your case, adding a move property to the Event will force you to implement an onEvent method, but you may not need that
If its optional then you could make the mapped typed with a „?“. For me personally I would rather have the type generated and dont have to change types everywhere when I change the basetype. But it depends on the taste :)