The Lies We Tell Ourselves Using TypeScript

Hi, welcome to my talk, Lies We Tell Ourselves Using TypeScript. It has been a fantastic TypeScript congress so far. You have seen lots of fantastic speakers, people that I wanted to meet for such a long time, people that I've engaged with on social media, and who are the best of the best in TypeScript.

Now, I need to tell you that I'm sorry. I'm sorry because you had fantastic talks from fantastic speakers. Now, I'm going to crush your dreams and destroy your hopes because this is not going to be a fun talk. I've done a fair share of TypeScript development. I've written two books about it, one which is TypeScript, the good parts. This is how the type system works for types for JavaScript developers. The other one TypeScript Couple where they have 100 actual problems that we are going to solve together.

And throughout my journey, I always start with this example where TypeScript is absolutely perfect for. I have this JavaScript codes. Don't worry about what it does, but it's just JavaScript. The browser executes it. It just doesn't work. There's no error that's being flown. Nothing tells you what's going wrong. It runs, it doesn't throw any errors, but it does not produce the right results. And for examples like that, TypeScript is fantastic because TypeScript, just when I activate it, finds about, I don't know, 10 errors in 15 lines of code. That's what we're here for. That's TypeScript's purpose. But this is not what I'm talking about today.

Today, I talk about the total opposite. I'm going to show you an example that TypeScript is totally happy with. We're just fetching some data from some API and concatenating it with something else. And TypeScript says, well, the types check out. This is good code. It compiles, you can ship it, and it will most likely crash at runtime. You know, at runtime, those things that TypeScript is supposed to prevent. Let's go through the code step by step.

The first function fetches data. We call it list entries, and you have two ... you have two function overloads that define an API for you and your users. If you get a kind of species, then you're getting a promise of species in return. If you're getting a kind of people, then you're getting a promise of people in return. We are accessing the Star Wars API, which is great if you want to do any rest tests. And you have a very tailor made API so that you actually know what you should get back. Then you have the third function overload, which is the actual function implementation for you.

Next, we are fetching data and since it has some meta information, we are unwrapping it. We are just interested in the results. One thing that is very interesting about this line of code is that we are doing some, sorry, that we are doing some error handling. So there's one part where we say, well, that result.JSON call on line three might go wrong. So let's better catch that syntax error. What if we don't get any JSON back? Fantastic. Five lines of code for that function, three lines of type information.

Next is one line. I just formatted a little bit for this slide. Then we are concatenating a promise of an array of people or species to another list of array of people or species. So we're concatenating those two with the part push method of an array. And finally, we are calling so we are creating a new people array and we are pending species to the people array. All right. This is our program. It's about, I don't know, 10 real lines of code, a couple of type information. And I want to ask you if you look at the entire program, do you know what's going wrong or do you know what's supposed to go wrong? So, well, I think everything. And where does it go wrong? Everywhere. And when does it go wrong? Yeah, one by one, because we're single threaded. But don't worry, we are going through it step-by-step. We are now going to look at all our problems. Problem number one in chapter one, a tail of fetch. Let's look at the core of our very first structure.

If you look at it, it's marvelous. We're just fetching some data from the Star Wars API and then we are calling result.json. So we have a JSON object and we are unwrapping it. But there's one little tiny lie hidden in line number three. This type annotation, let data of type matter people, just works because the result.json call returns a promise of any. And you know any. Any is the happy-go-lucky type in TypeScript. Any says I'm not doing any type checking at all. You as a developer, you know best. And since we are assigning any to matter of people, things break. Because TypeScript then thinks that you know best and you know that the result or that the JSON result of result should be matter of people. But this is just done by yourself. No type checker helps you with that problem. And what we're seeing here is TypeScript at its boundaries where the matter of your types, you know, that work well together, you designed how they should be meets the real world. When you have user input, when you have network IO, when you have stuff from APIs. This is something from the outside enters your type world and you need to make sure that those things line up. And TypeScript is a very nice way of showcasing those boundaries or showing when those boundary problems arise. I like to call that unsafe operations.

And we have keywords for that. We have, for example, a type assertion. So instead of doing a type annotation, we can say well, result.json should be meta people and this is an explicit type assertion from us where we are bending the type system. The same thing with function is dice where we say, okay, if I'm getting a number in and it is from one to six, then I know it's of type dice and I can bend the type system. I can say type system, I know better than you do. Same with assertion signatures. And all those keywords. For us, signal that we are bending the type system to our will.

So if I ask you what of those two things actually shows better that the type system is being bent a little bit, it's number two, because you can do a full text search for the keyword as, and you find all the positions, all the places in your code where you are bending the type system to your will. Number one is just a type assertion. You're never going to figure out that you're having any on the right-hand side. And it suddenly becomes a matter of people on the left-hand side. So what we want is actually number two, but the problem is that type annotations with any just work and nothing keeps us from doing that. TypeScript is totally happy with it.

What would be better in that case, if result.json wouldn't produce a promise of any, but rather a promise of unknown because unknown is the cautious sibling of any. Unknown is the cautious sibling of any. Unknown tells you, please check everything before proceeding. And we can tell TypeScript to use unknown instead of any. With a little thing called declaration merging. No interface in TypeScript is ever closed. You can always add new methods to it. This is, first of all, for keeping track of the ECMAScript versions, fantastic. Second of all, also for you to patch stuff according to your browser's needs or to your environment's needs. This is how gQuery handles plugins, for example. And how TypeScript works with the object constructor and whatever. And you can tell TypeScript, the body interface, which is the one interface that our result gets its methods from, has another trace method of promise unknown. And since it's the last one, since you added the last position, this overrides the other ones. You have another function overload that now returns a promise of unknown instead of a promise of any. And if you add those three lines of code, then suddenly you're getting an error. You're getting an error and TypeScript tells you, wait a second, the type unknown is not assignable to the type meta people. Unknown is the cautious type, the cautious type of any same set of areas, but very cautious. And this is where you need to do extra checks. Either do a type assertion or maybe use something like salt and make sure that the data you get is actually the data that you're looking for. Cool. Problem one found. Problem one solved. Let's look at problem two. The theme is dark and full of errors.

This one is so interesting. This line of code, we are catching for syntax error. The developer was very clever because they thought that result.json might might throw a syntax area and they're right. If you don't get any JSON back, it's a syntax error and then you can catch the error and maybe return an empty, empty array or whatever. Use something to mitigate that error.

I'm just throwing another error. Who cares? But, you know, we want to make sure that we are catching that syntax error. The problem is that in JavaScript, anything can throw everywhere. Errors can happen all the time and this is why the developer added any to a union. Again in JavaScript, everything can throw. You can throw the number two, you can throw undefined, you can throw tantrums like my two-year-old. Basically, JavaScript and my two-year-old are the same thing. In JavaScript, everything throws and I don't know where it's coming from. My son throws tantrums and I don't know where they're coming from. But anyway, if you look at that line, the little any in the union of a syntax error, should tell us that this is what's actually happening. You either have a syntax error or you have any error. Because, you know, just have somewhere a syntax error, or somewhere type error or whatever and your program crashes.

So it's true. The statement here is absolutely true. The problem is that if you put any to a union with something else, you are getting any again. You know, the happy-go-lucky type that, you know, deactivates type checking for you. So we are basically catching for any, which means that if you access e.message at this point, that might go wrong. So just print undefined now, but what if you do something with the message, like to uppercase or you send it somewhere that expects a defined value. And you can again solve this with a little compiler flag called unknown in catch clauses and you do instance of checks later on. So you activate the flag, use unknown and catch variables. Then your error is unknown by default. So you don't need to catch for a syntax error or for any or whatever. It's unknown by default. And then you can do checks, instance of checks on syntax error to get to the actual properties of a syntax error. And this is how you mitigate this problem.

So problem number two, error handling solution to instance of checks. Problem number three, the metrics overload. Now let's look at those function overloads again. We have three function overloads. Two are for the interface for your users like kind of species returns promise of species, kind of people returns promise of people. And then you have the broader implementation signature, you know, one that you can actually work if you get either kind of people kind species of people or you, and then you return the people array or species array. One of those array of people or species. Good. The problem here is that if you look at that line of code, the only thing that I return are people. I'm not returning species, but the types tell me that I get species. The code tells me that I just returned people so I can request species in my code and the type system tells me, well, everything is species, but in reality, I'm just working with people. And if those two types are different, well, then you have a big problem because then you're accessing properties that don't exist.

All right, so let's look at those functional models in detail. We can split it up. So if you have functional models, two always for the usage and the third one is for the implementation. And there are two type checks happening.

First of all, all those usage checks check if they are being covered by the implementation. So you can't write anything in the usage section that is not being covered in the implementation section. This is what's happening here. So if I add species and people to kind, then I also need to make sure that the implementation signature takes care about both as well. You either use a union or use a variable type like string. And the same with the return type. Same thing. This is the first type check.

The second type check is between the implementation in the function body. So then you look at the implementation signature and everything you write in the function body will be checked against the implementation signature. So those two worlds will be checked but nothing checks if your implementation actually covers all the usage entries. Nothing checks it. And this is the big problem with functional overloads.

So, first of all, great, you're getting a tailor-made API. The problem is that, well, there's a disconnect between the function body, the implementation signature, and the usage signature because it's not checked everything. They're just two different type checks happening. A solution for that is doing conditional types. Conditional types, you know, you can basically define a similar API. I'm now having here return type where I say, well, if I'm getting species, then return species. If I'm getting people, return people. Otherwise, never, this will never work. Don't use anything else other than species or people. And then I can use generics, use my conditional type, and suddenly I'm getting an error because conditional types are very complex. The function body can't be validated against the return type of a conditional type, or the conditional return type. So, I'm getting an error where I say, people are species arrays not assignable to return of T. Now I need to do extra checks.

Now I need to do type assertions. Now I need to do unsafe operations. Now I highlight a potential problem in my code. I'm getting an error, and this is what we are here for. Now, to my favorite, chapter 4, the unexpected virtue of ignorance. Let's look at this single line of code, and the type signature around it. So, I'm getting two parameters. One is an array of people or species. The other one is a promise of an array of people or species. Then I concatenate the two of them. Fantastic, that's all that's happening. I just take two arrays, concatenate them. Beautiful. Then I'm creating a people array, and then I'm calling await the append entries of list and list entries of species. So I'm concatenating the people array with the species array. What's the type of list after append entries? It's still people. The type of list is still people, even though I'm adding species to the array. So this is, I have no words for that, I'm so sorry, I have no words for that, just animations, but this is beautiful. This is such a beautiful error and it annoys me so much that it happens, but what's happening here is the following, that all the contracts are fulfilled. So if I'm having a list which is an array of species of people, then I can add a people array to it. And if I have another list of array of people, then I can add a species array to it. The problem is that the original list is being mutated and in TypeScript nothing exists to highlight those mutations from for example arrays, or whatever. So the type doesn't change afterwards. This is a problem. But there's another solution for that. If you are encountering things like this, always add generics. Generics are beautiful because generics have a very fantastic feature which is that they lock your type into something concrete. So what I'm doing here now is that instead of taking the broad type of people or species, I'm taking a generic type parameter T which extends an array of people or species then I have a list of T and I have a promise of T. I do the same thing. It's just the same code but now when I create a list of people and I put that list into append entries, TypeScript locks T to array of people.

So it locks it to the subset. It's not taking the broader set anymore. It locks it to the subset. And the moment it locks it to the subset of array of people or species, the moment it locks it to that subset, it figures out that what I'm getting here is not of the same type as list. So it tells me, wait a second, the argument of type promise species, uh, promise of species is not assignable to the parameter type of promise of people because list defines the concrete type. You know, this is an error. This is what we're here for. Now we can act.

Okay. Everything mitigated. Every potential problem now has a solution. Please enter the final chapter. Lies, damn lies, and TypeScript. So far we've found four problems and we found four mitigations. We used declaration merging to patch the assumptions made by the standard library. We use instance of checks and unknown to narrow down error types. Great! We use conditional types instead of function overloads to highlight unsafe operations and fourth, beautiful, we use generics to narrow down to specifics. Force problems for solutions and all of the solutions just have more lies. I'm so sorry. I just told you more lies.

First of all, interface declaration merging is fantastic. You can extend the global namespace and add more properties to it if your software needs it, if your libraries need it, if you have Google Analytics in the window interface, well then, you can just add it to the window interface. That's what you do. It's great unless you are defining a new interface that you accidentally merge with the global, like form data here. This has happened to so many people already. I'm constantly getting messages from people on Twitter or Nestled or wherever, where they say, I had exactly the same problem because I was defining my form data with the interface form data, and guess what? It's a global and nothing tells me that it's a global. Suddenly, you're getting more methods like .get, .set. Where is this coming from? Well, it's coming from a global form data interface that I accidentally merged with. So declaration merging is great unless you accidentally merge with globals. Now something that makes my toenails go up, it's hilarious.

I have two classes, class R and class B, both have a number property. One is called A, the other one is called B, and then I have a do something function where I'm getting a union for A or B. So it's either A or it's B. And I'm doing instance of checks. So I'm doing P instance of A, then it should be A. So I'm logging out A and in the else branch it's B. So TypeScript tells me that it's B and I'm logging out P.B. Good. So this is how it's supposed to work. Beautiful. So now I can create new instances of A, new instances of B. I'm having instance of checks. Everything is as it should be.

And then you realize TypeScript has a structural type system and that you can enter an object that just looks like an instance of A and that it will type check. So do something with this object, A42, type checks. But if this object goes into the do something function, it will not be an instance of A. It will not be an instance because it's not being created with the new keyword. It's just something that looks similar to an instance of A. And TypeScript is happy with that. So this instance of A checks falls through. You're in the else branch. Typescript thinks you are B. But in reality, you are an object like A. So yeah, instance objects are great until you realize TypeScript is structurally typed.

Yep. Third problem. Conditional types are great unless... I am so sorry. Seriously, I'm so sorry if you look at that. I have no clue what it does. Um, from the creators of regular expressions comes the SQL nobody asked for. No, I'm so sorry. Um, this here is, I guess it's about occurring, uh, function overloads. Um, I don't know. I've written this type. Uh, so it's, it's done by myself and I, I couldn't tell you what it does because just a week ago I totally forgot what I did. Um, I've written a book about it. So this are part of my book to explain what's going on, but who, so if you use conditional types know about their complexity, they are great because you can do a lot of things with it. They are very powerful. It's amazing what you can do with it, but they require extra documentation and extra care. And you're, you're not here to work for the latest and greatest and for the most, most, um, Code Voodoo that you can do. Uh, there's no magic in coding. You need to work with people. You need to work with yourself or you need to work with your colleagues and if this goes into your code base, double check what's going on there. Document everything, write test cases with it. You can write type test cases. You can do that. Make sure that everything in here is documented and a way label and it tests, uh, extends the tests of time. Um, so yeah, conditional types are great unless you figure out they are actually quite complex and last button. These are generics. I create them to you, explicitly make this, write as it should be. You're always able to explicitly, um, uh, annotate the generic type parameter. And then everything goes, goes boom again. So yeah, four problems, four solutions, former problems.

Let's go for the epilogue. All right, folks. I told you, I'm sorry. This, this was not the fun talk. This was just problems and more problems and lies, and I'm very sorry for that. Um, and you might think, you know, I've written two books on TypeScript. I'm doing consulting on TypeScript. I'm working with lots of teams on TypeScript and I'm creating a TypeScript runtime, um, like, like, like, but, um, but internally, what do I think of TypeScript? What do I think of TypeScript after finding all those big problems? And I have to say, oh, I fucking love TypeScript. Seriously. It's still the second best language I had the pleasure to work with. It's so much fun and it makes me so productive. And you can't argue with that. TypeScript makes you productive. Um, you know, this talk is not called lies that TypeScript tells us, this talk is called the lies we tell ourselves using TypeScript. Um, and there are lots of lies that we tell ourselves. We tell ourselves the lie that TypeScript is 100% type safe. Um, we are telling ourselves the lie that we can, we can forget about our code because TypeScript has our back. Um, and maybe we are telling ourselves the biggest lie that we think that we are here to write code. And I don't think so. I don't think that we are here to write code. I think we as software engineers are here to make decisions. And we're here to validate the trade offs of every decision that we're doing. Um, TypeScript is just a tool in the box. The code that you write and everything that you get, for example, from Co-Pilot or Stack Overflow or wherever. If you put it in your code base, you make the decision that this code is good enough to be put in your code base. And this is what the main task should be about. Um, tools can just help you make decisions, but you still need to know what's happening underneath. And you know, who's really good at making those decisions and trade offs? The TypeScript team. This is one page from the wiki on GitHub, um, which defines goals and non-goals. And I think the non-goals have very interesting, because there's one line that basically tells you the reason for everything that you just saw.

A non-goal is to apply a sound, approvably correct type system. Instead, they want to strike a balance between correctness and productivity. And all those little errors that you just saw come from exactly that line. Um, they put productivity first. And with that, yeah, there might be a couple of patches where, you know, things might not end up as they should be. Um, but still you, you make the decision to put the line in your code. So you are the one responsible for that TypeScript, you just need to know about the trade off.

And there's a big trade off in TypeScript that, you know, stuff might not be provably correct in the type system. And you might say, but, but, well, why, why do we even bother if they, if they're not making it provably correct because the main goal was always to make developers productive. Um, I gave the same talk in front of 4,000 people, um, at the V8 Developers World Congress. And I asked two questions to the audience. Question number one was who is, who is using TypeScript in a room with 4,000 people? Over 90% were raising their hands. And then I asked him, does anybody remember a type system called Flow? And it was three people, three people in 4,000 remember a type system called Flow, which was Facebook's answer to TypeScript. Very similar in syntax, very similar in features, but the Flow folks had the goal of having a provably correct type system and thus killing productivity for everything else. And we see what has prevailed over time. As much as I like Flow and I know people from the Flow team, I know what they worked on and how they approached them. It's a beautiful type system. But this little decision to put productivity first is what made TypeScript so popular in the end. And this is the point of my talk. The point of my talk is that, if you use TypeScript, please love it as much as I do because, seriously, I love TypeScript and it's so great to work with. But be aware of the trade-off that you're making. Be aware that the type system might work differently than you expected and it's still your duty to learn it.

It doesn't take away the responsibility of learning a programming language just because you get such excellent tooling. And this leads me to the one learning that I want to transport to you, which is the one thing that you should take home. Be pragmatic and be aware. Choose what works best for you and your team. And if you don't have a team, you have always future you that you need to work with. You're never code alone. Don't listen to dogmatic advice. You know, it's so easy to make, I don't know, I guess it's TikTok where you have to, I don't know, or tweet or whatever, that gives you this one beautiful, fantastic advice that kills everything else. But then, you know, it's just another decision that somebody else made for you. Don't listen to dogmatic advice. Always question everything, validate it against what you need to do. Be pragmatic, be aware, make decisions, well-informed. And with that, I want to say, thank you very much for listening to me. Thank you very much for meeting me. I hope you had as much fun as I had.