I love these more advanced typescript videoes, you are my new favorite typescript youtuber. Keep them videos coming! Particularly, I am interested in seeing advanced usage of generics.
This is nuts, just do something simple since you need this code anyways when to map at runtime function toNewType(from: Legacy) { return { // ... } } type NewType = ReturnType (or specify the return type if you don't want the inferred type)
@@shubitoxX i absolutely see your point. The problem with this approach is, that you always have to update your resulting type manually and you do not know when the legacy type gets a new property because it will not show a compile time error. But of course only use the approach shown if it gives a benefit to your code. In my production code I always strive for simplicity instead of making it clever :)
It may seem unnecessary, but if you have bigger projects with hundreds of types and multiple developers it's almost necessary to have some automated guards for changes like type additions. And the cool thing about the proposed approach in this video: It's generic. So once you've set it up it will just work for all your types.
@@aleksander5298 no need to degrade or demean anyone here. We are having, what I hope to be, an intelligent and objective conversation about Typescript types. 1. The point of the channel is to teach typescript type, not the implementation. Therefore he doesn’t show the actual function. I’m sure his implementation would satisfy the type. 2. There is a fundamental difference in perspective and scale that @Typed-Rocks approach is better suited for. The idea behind your types driving development and cross-team collaboration. a. In @shubitoxX’s proposed solution above. If you simply did the ‘ReturnOf’ solution your implementation creates the types, which can be useful, but less so if you’re trying to maintain a contract. Anyone could change the implementation and alter the types. b. If you have multiple teams, some doing a legacy refactor and some still implementing new features in the legacy system (a business needs to keep the lights on). Then this approach would allow for contract synchronization between multiple teams/types. I personally haven’t encountered this level of collaboration so I typically opt for declaring a second type. Keep up the amazing content @Typed-Rocks Have a good day 😊
I'm torn on this. I definitively see the value of having the [new and old] types be "linked". And I don't think it's nearly as complicated as some of the other commenters make it out to be. What would bother me, however, are two hypothetical scenarios: 1) What if they just never update it again? Then having a generic kinda complicated solution just becomes a potential source of bugs. 2) What if they update it a lot? Will my initial assumptions and understanding of the problem hold? How much can it grow before getting out of hand? Do I have a way out if that were to happen?
@@VonCarlsson 100% true, these things I‘m showing are maybe sometimes too complicated for simple problems. I just want to show that it is possible to do such things. I would also only choose this approach in certain specific cases.
@@Typed-Rocks It's fine as an example. I didn't mean to discourage the use of more sophisticated types. As I said, the new and old types being "linked" is genuinely valuable. Getting an error at compile time is exactly what we want and definitively worth having a bit of extra complexity for! I'm just wary of it getting out of hand, because I've been there myself on more than one occasion 😅.
Excellent video. Would it be possible to generalize the "SearchAndReplaceAll" so we can pass different mapping functions instead of just "SearchAndReplace"?
Great demontration of TS power and great explanation as well. But wouldn't be easier to just define a new type for new api since it will probably be developed independently?
Wait, why does `DeepReplace` work for the types that aren't objects? How come you don't need a check for it being an object or being anything else? Shouldn't the mapped type fail when it sees the `string` and `number` types?
I think the solution itself is cool because it showcases typescript generic magic. But example with converting APIs brings bad feelings about usage of such complicated approach in such important place. I really love doing complex types with generics and nested logic, but I think in such cases all this magic will create more problems than it solves
i would hate you so much if I worked with you, overcomplicating instead of making an effort of cleaning up things even if takes a bit more time initially, this just adds to shit complexity and shit decisions made when the "legacy" thing happened
Dont‘t worry. In my daily life i strive to simplicity, so we would not have any problems for sure ;). Your idea with the cleanup would be my first approach but if the type definitions come from external sources which we cannot change, we often don‘t have the ability to do that.
Interesting, but why did it decide that the resulting id should be a a string and not a number? The legacy had one of each. Does this approach give any way to control this?
@@Typed-Rocks Ah thank you, looked at bit closer and saw that the auto complete suggested a number, but the model accepted a string (timestamp 12:48). Might just be auto complete that could be improved.
This is the type equivalent of a spork, it's kinda neat, you say that you're going to use it, but you wont. And if you do you'll regret every second on it!
Absolutely fair point. I will also do this almost never in real projects but it shows the power of typescript. With great power comes great responsibility 😜
This is ridiculous, if you're stuck maintaining a crappy app, propose a rewrite asap, or get the hell out of there. No program should be this convoluted
Hahaha, that’s nuts. Somebody told me that Typescript typing is itself Turing-complete but I never thought about the consequences.
I have to cross my finger and pray i won't ever use this on my entire life, what a beast 😂
I love these more advanced typescript videoes, you are my new favorite typescript youtuber. Keep them videos coming!
Particularly, I am interested in seeing advanced usage of generics.
This is insane, i feel like if i used this i would hate myself for it 3 weeks later 😂
This is nuts, just do something simple since you need this code anyways when to map at runtime
function toNewType(from: Legacy) {
return {
// ...
}
}
type NewType = ReturnType
(or specify the return type if you don't want the inferred type)
@@shubitoxX i absolutely see your point. The problem with this approach is, that you always have to update your resulting type manually and you do not know when the legacy type gets a new property because it will not show a compile time error. But of course only use the approach shown if it gives a benefit to your code. In my production code I always strive for simplicity instead of making it clever :)
It may seem unnecessary, but if you have bigger projects with hundreds of types and multiple developers it's almost necessary to have some automated guards for changes like type additions. And the cool thing about the proposed approach in this video: It's generic. So once you've set it up it will just work for all your types.
@@aleksander5298 no need to degrade or demean anyone here. We are having, what I hope to be, an intelligent and objective conversation about Typescript types.
1. The point of the channel is to teach typescript type, not the implementation. Therefore he doesn’t show the actual function. I’m sure his implementation would satisfy the type.
2. There is a fundamental difference in perspective and scale that @Typed-Rocks approach is better suited for. The idea behind your types driving development and cross-team collaboration.
a. In @shubitoxX’s proposed solution above. If you simply did the ‘ReturnOf’ solution your implementation creates the types, which can be useful, but less so if you’re trying to maintain a contract. Anyone could change the implementation and alter the types.
b. If you have multiple teams, some doing a legacy refactor and some still implementing new features in the legacy system (a business needs to keep the lights on). Then this approach would allow for contract synchronization between multiple teams/types.
I personally haven’t encountered this level of collaboration so I typically opt for declaring a second type.
Keep up the amazing content @Typed-Rocks
Have a good day 😊
So great. Please release more videos like this
Never knew Typescript could do that. This video is the conversion portal of your viewers to subscribers.
I'm torn on this. I definitively see the value of having the [new and old] types be "linked". And I don't think it's nearly as complicated as some of the other commenters make it out to be. What would bother me, however, are two hypothetical scenarios: 1) What if they just never update it again? Then having a generic kinda complicated solution just becomes a potential source of bugs. 2) What if they update it a lot? Will my initial assumptions and understanding of the problem hold? How much can it grow before getting out of hand? Do I have a way out if that were to happen?
@@VonCarlsson 100% true, these things I‘m showing are maybe sometimes too complicated for simple problems. I just want to show that it is possible to do such things. I would also only choose this approach in certain specific cases.
@@Typed-Rocks It's fine as an example. I didn't mean to discourage the use of more sophisticated types. As I said, the new and old types being "linked" is genuinely valuable. Getting an error at compile time is exactly what we want and definitively worth having a bit of extra complexity for! I'm just wary of it getting out of hand, because I've been there myself on more than one occasion 😅.
That is amazing! One way to automate things. Imagine have hundred of legacy properties, it is time saver!
Great video, very well explained. I'm not a web dev, so I had no idea Typescript's typing system ran so deep.
Thank you, really appreciate it. Especially coming from a non web dev 🙏
But this doesn’t solve the problem of receiving the old api data and converting it to the new type. 😢
Excellent video. Would it be possible to generalize the "SearchAndReplaceAll" so we can pass different mapping functions instead of just "SearchAndReplace"?
Thank you 🙏 and regading your question: It should be possible but I would create a new type for that to keep it better readable.
Thanks for Video 👍
Your channel is awesome 🙌🏾
Instantly subscribed.
Great demontration of TS power and great explanation as well. But wouldn't be easier to just define a new type for new api since it will probably be developed independently?
Absolutely possible. If the legacy api is still evolving than it might be good to have a generic approach but otherwise 100%
This was new to me, subscribing!
wow that's cool, subscribed ❤
Wait, why does `DeepReplace` work for the types that aren't objects? How come you don't need a check for it being an object or being anything else? Shouldn't the mapped type fail when it sees the `string` and `number` types?
@@vdvman1 Excellent point. This is some TypeScript magic. It will only loop over the object types using the mapped types
@@Typed-Rocks oh so that's just a thing with how mapped types work? Interesting 🤔 thanks!
I think the solution itself is cool because it showcases typescript generic magic. But example with converting APIs brings bad feelings about usage of such complicated approach in such important place. I really love doing complex types with generics and nested logic, but I think in such cases all this magic will create more problems than it solves
i would hate you so much if I worked with you, overcomplicating instead of making an effort of cleaning up things even if takes a bit more time initially, this just adds to shit complexity and shit decisions made when the "legacy" thing happened
Dont‘t worry. In my daily life i strive to simplicity, so we would not have any problems for sure ;). Your idea with the cleanup would be my first approach but if the type definitions come from external sources which we cannot change, we often don‘t have the ability to do that.
Interesting, but why did it decide that the resulting id should be a a string and not a number? The legacy had one of each. Does this approach give any way to control this?
It should create a union of string|number
@@Typed-Rocks Ah thank you, looked at bit closer and saw that the auto complete suggested a number, but the model accepted a string (timestamp 12:48). Might just be auto complete that could be improved.
I wouldn't fix unmaintainable code with more unmaintainable code. But I guess that the options exist
Exactly. It always depends when to use it.
@@Typed-Rocks usually you write unit tests and e2e code to migrate code. I wouldn’t rely on type checking alone.
This is the type equivalent of a spork, it's kinda neat, you say that you're going to use it, but you wont. And if you do you'll regret every second on it!
I know exactly what you mean 😁
what is your font in VS?
I‘m using IntelliJ but there I use Jetbrains Mono NL
As someone who has mostly worked with java, kotlin an dart, i wanna say, what sorcery is this?
It's really cool. I also started back with Java 5 and it's crazy what is possible with this language.
ah yes TypeScript, purely functional language.
I thought I knew typescript
wizard
oh god! this is fucked up haha
🤘🏻
go grab a beer on me
Cool
What is this shi**** my friend, stop using typescript, this is madness
@@حاتمأمحمد-د6د stay tuned for more 😁
😂
Negative I'm Pythonic
ts was a mistake 😭
All this effort, just for a freaking Type that is completely useless in the browser 🤣
I use TS in my job, I do types...but, that kind of types...sorry I'm not into that LOL
Absolutely fair point. I will also do this almost never in real projects but it shows the power of typescript. With great power comes great responsibility 😜
This is ridiculous, if you're stuck maintaining a crappy app, propose a rewrite asap, or get the hell out of there. No program should be this convoluted