The Lies We Tell Ourselves Using TypeScript

Rate this content
Bookmark

How safe is TypeScript's type safety? How much can you trust your statically typed code? Can you even consider TypeScript's type system "strong"? In this talk, we look at situations where TypeScript fails badly and learn why things have to be that way. We talk about trade-offs, workarounds, and ultimately solutions for all the damn, terrible lies we tell ourselves when using TypeScript.

28 min
21 Sep, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The Talk discusses the limitations of TypeScript and the lies we tell ourselves about its type safety. It explores examples of unsafe operations and bending the type system using keywords like type assertion and function is dice. The Talk also covers catching syntax errors, type mismatches, and the complexity of conditional types and generics. It emphasizes the importance of understanding TypeScript's limitations and making well-informed decisions as software engineers.

Available in Español

1. Introduction to TypeScript and Its Limitations

Short description:

Welcome to my talk, Lies We Tell Ourselves Using TypeScript. It has been a fantastic TypeScript congress so far. Today, I talk about an example that TypeScript is totally happy with. We're just fetching some data from an API and concatenating it with something else. TypeScript says it's good code, but it will most likely crash at runtime. Let's go through the code step by step.

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.

2. Fetching Data and Handling Errors

Short description:

The first function fetches data from the Star Wars API using function overloads. We unwrap the fetched data and handle any potential syntax errors. Then we concatenate arrays of people or species using the push method, and finally, we create a new people array and append species to it. This program has about 10 lines of code and we will now address the problems step-by-step, starting with the core of our structure.

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.

3. TypeScript's Boundaries and Unsafe Operations

Short description:

We're fetching data from the Star Wars API and unwrapping a JSON object. However, there's a lie in the type annotation. TypeScript's any type allows us to bypass type checking, which can lead to errors when assigning any to a specific type. TypeScript exposes the boundaries between well-designed types and the real world, where external inputs need to align with our types. These unsafe operations highlight the need for careful handling of user input, network IO, and API data.

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.

4. Keywords for Bending the Type System

Short description:

We have keywords like type assertion and function is dice that allow us to bend the type system to our will.

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.

5. Bending the Type System

Short description:

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. What would be better in that case, if result.json wouldn't produce a promise of any, but rather a promise of unknown. Unknown tells you, please check everything before proceeding. The type unknown is not assignable to the type meta people. This is where you need to do extra checks. Problem one found. Problem one solved. Let's look at problem two. The theme is dark and full of errors.

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.

6. Catching Syntax Errors and Handling Unknown Errors

Short description:

This line of code catches syntax errors, but in JavaScript, anything can throw errors. By adding 'any' to a union, we catch any error, which can lead to potential issues when accessing specific properties. To mitigate this, use the 'unknown' compiler flag in catch clauses and perform instance of checks. This ensures the error is unknown by default and allows for proper handling of specific error types.

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.

7. Function Overloads and Type Mismatch

Short description:

The problem with function overloads is that the types may not accurately reflect the actual returned values. In this case, the types indicate that we get species, but in reality, we only work with people. If the types and the actual returned values are different, it can lead to accessing non-existent properties.

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.

8. Functional Models and Type Checks

Short description:

Let's dive into functional models. There are two type checks happening: one for usage and one for implementation. The usage checks ensure that everything in the usage section is covered in the implementation section. The implementation check validates the function body against the implementation signature. However, there is a disconnect between the function body, implementation signature, and usage signature, which can lead to incomplete coverage. Conditional types can be used as a solution, but they introduce complexity and require extra checks.

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.

9. Type Assertions, Unsafe Operations, and Generics

Short description:

Now I need to do type assertions and unsafe operations. I highlight a potential problem in my code. I concatenate two arrays, but the type of the list remains the same even after adding species to it. This is because the original list is mutated, and TypeScript doesn't highlight these mutations. To solve this, always add generics. Generics lock your type into something concrete. By using generics, TypeScript will correctly infer the type of the list based on the input.

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.

10. TypeScript's Limitations and Solutions

Short description:

So it locks it to the subset. And the moment it locks it to the subset of array of people or species, it figures out that what I'm getting here is not of the same type as list. This is an error. Now we can act. Everything mitigated. Every potential problem now has a solution. Lies, damn lies, and TypeScript. We've found four problems and four mitigations. Interface declaration merging is fantastic, unless you accidentally merge with globals.

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.

11. Class R, Class B, and Instance Checks

Short description:

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.

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.

12. TypeScript's Structural Type System

Short description:

TypeScript's structural type system allows objects that resemble instances of a certain class to pass type checks, even if they are not created with the 'new' keyword. This can lead to unexpected behavior when passing these objects to functions. TypeScript may incorrectly infer their type and cause issues. It's important to be aware of this limitation in TypeScript's type system.

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.

13. Complexity of Conditional Types and Generics

Short description:

Yep. Third problem. Conditional types are great unless they become too complex. They require extra documentation, care, and thorough testing. It's important to double-check their implementation, document everything, and write test cases. Generics can also cause issues if the generic type parameter is not explicitly annotated. So, remember to handle conditional types and generics with caution.

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.

14. Epilogue: Lies We Tell Ourselves

Short description:

I love TypeScript. It's the second best language I've worked with and makes me productive. We tell ourselves lies about TypeScript being 100% type safe and that it has our back. As software engineers, our main task is to make decisions and validate trade-offs. TypeScript is just a tool, and we need to know what's happening underneath. The TypeScript team is good at making those decisions and trade-offs.

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.

15. Trade-offs and Pragmatism in TypeScript

Short description:

A non-goal is to apply a sound, approvably correct type system. Instead, TypeScript prioritizes productivity. TypeScript's popularity stems from its focus on productivity over a provably correct type system. If you use TypeScript, love it, but be aware of the trade-off. It's your duty to learn the type system and make well-informed decisions. Be pragmatic, question everything, and choose what works best for you and your team. Thank you for listening!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
I'll dive into the internals of Nuxt to describe how we've built a TypeScript-first framework that is deeply integrated with the user's IDE and type checking setup to offer end-to-end full-stack type safety, hints for layouts, middleware and more, typed runtime configuration options and even typed routing. Plus, I'll highlight what I'm most excited about doing in the days to come and how TypeScript makes that possible not just for us but for any library author.
React Advanced Conference 2021React Advanced Conference 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Top Content
Why are we devs so obsessed with decoupling things that are coupled nature? tRPC is a library that replaces the need for GraphQL or REST for internal APIs. When using it, you simply write backend functions whose input and output shapes are instantly inferred in your frontend without any code generation; making writing API schemas a thing of the past. It's lightweight, not tied to React, HTTP-cacheable, and can be incrementally adopted. In this talk, I'll give a glimpse of the DX you can get from tRPC and how (and why) to get started.
TypeScript Congress 2022TypeScript Congress 2022
10 min
How to properly handle URL slug changes in Next.js
Top Content
If you're using a headless CMS for storing content, you also work with URL slugs, the last parts of any URL. The problem is, content editors are able to freely change the slugs which can cause 404 errors, lost page ranks, broken links, and in the end confused visitors on your site. In this talk, I will present a solution for keeping a history of URL slugs in the CMS and explain how to implement a proper redirect mechanism (using TypeScript!) for dynamically generated pages on a Next.js website.

Add to the talk notes: https://github.com/ondrabus/kontent-boilerplate-next-js-ts-congress-2022 

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.