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.
@@Typed-Rocks but the problem with your approach is, you just have types, and you don't have mapping function, so you write magic types and you don't validate in any way your data :) proposed solution is way better, but yeah, you are just youtuber and never was in real project with real problems :)
@@1879heikkisorsa So you're saying you've never worked in enterprise solutions? No self-respecting developer would use a magic mapping function to change the schema in such a way, there are so many possibilities for bad mapping here that only an idiot would do it, or someone who thinks he is a smart developer, but in truth only creates confusion in the project, pathetic :)
@@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 😅.
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 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.
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?
Excellent video. Would it be possible to generalize the "SearchAndReplaceAll" so we can pass different mapping functions instead of just "SearchAndReplace"?
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
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?
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.
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
