Ugly TypeScript Code Is Actually Good (Sometimes)

Key Takeaways

I recently released an advanced TypeScript video talking all about like the extends keyword, how you can use infer, as well as quite a few other things to create really complicated TypeScript types. And I received a ton of comments saying code that looks like this is incredibly complex, overengineered, and just bad code in general. And I think that those people are both right and wrong. And I want to talk a little bit about why that is. First of all, yes, this code is very difficult to read, especially with how zoomed in my screen is. If I zoom it out to a more reasonable screen size, you can see it's a little bit easier to read. But overall, it's still incredibly complicated code with lots of nested turnaries and so on. And that's a little bit of a side effect of TypeScript. When you start to write more complicated code, the only way to do an if statement inside of TypeScript is a turnary. So you end up with tons and tons of nested turnaries, which gets rather difficult to read unless you're familiar with TypeScript and how they actually use these turnaries for if statements. And generally when you're writing applications with TypeScript, your code is going to look something more like this. You're going to have a basic type. You're going to have something that uses that type. And that's pretty much all the TypeScript in your code. So 99% of the time you're going to be working with very simple types with for example very basic unions. But as soon as you start writing code for libraries that's when you need to start using these advanced TypeScript features. And the reason I needed all these features is because for example I was creating a translation app and I wanted to be able to translate for example what all my translation keys are. So I can see all my different translation keys. I also can give myself errors saying hey I actually require a second property on here that requires me to pass in a bunch of additional information. For example my name and so on. So I need all these additional TypeScriptbased features that I wouldn't get by just doing this purely inside of JavaScript. Same thing here. I get an exact perfect TypeScript representation of the only two values that I can pass along as the hobby property. These TypeScript types are actually so powerful that when I actually create a type down here, for example, I can specify exactly the parameters of what I want and it gives me full type safety for that. For example, here I said a hobby is an enum. And now inside my enum I have a key of hobby. And if I remove this, I'm going to get a TypeScript error. And I'm going to need to pass in hobby, which I have TypeScript safety for. And I need to pass in specific values for that, like I did here. And if I go ahead and I rename this to hobby 2, I'm going to get an error cuz this must be called hobby 2. So again, all of that extra TypeScript code that I write is implementing these features so that when you use this library, it's very easy for you. And as you can see, I didn't have to write any TypeScript inside of here to write my actual code because the library took care of all of that behind the scenes for me. And this is something you'll see in almost every TypeScript library. For example, I copied down the types for a very popular TypeScript library for internationalization. And as you can see, the types inside here are very similar to what I showed my application. We have lots of extends, we have lots of infers, lots of complicated nested turnary statements that are very difficult to work with and read. But that's just the reality of writing complex TypeScript for libraries. Usually the easier to use a library is, the more complex the types are behind the scenes. And sometimes in cases of like my application here, I actually have one to one TypeScript code to JavaScript code. So for every line of JavaScript code, I have a line of TypeScript code that is making that work behind the scenes to make it really easy for you to use that in your own application.