Advanced TypeScript: Let’s Learn Generics!

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone. And welcome to another episode of Learn with Jason. Today on the show we've got Matt Pocock. How are you doing?

MATT: Doing well.

JASON: Great. I feel you have rocketed up in in the TypeScript space You have a course coming out with wizard illustrations. It's special. But you're brand new to the teacher thing, not the teacher thing, the JavaScript thing. Let's maybe have a little bit of a background for folks who are just becoming familiar with who you are.

MATT: Sounds good. So, my weird background is that I was a singing and voice teacher for 6 years. Before I became a Dev. That's kind of where -- I don't know it's where my heart is. But it's definitely where the bulk of my experience is. I have been a teacher for a lot longer than I have been a Dev. I think I started building applications for my students, building these sort of weird voice apps that would tell you the quality of your voice and all this crazy stuff using web audio APIs. That was the my first JavaScript app, diving deep into the web API, and doing form transforms. And I realized I could probably get a job as a junior Dev. So, I got a job as a junior Dev. Then my next job, mid-level Dev, next job, senior Dev. And now I'm here. I'm working at Vercel. It's kind of mad, really. It's felt a bit like a rocket ride. And I think a lot of that is just being able to blag my way into situations that I have no business being in. And I think the accent helped as well.

JASON: I think we have proven that you sound 20 IQ points smarter whenever you have a British accent.

MATT: I think you sound more charismatic as American. That's my take.

JASON: Yeah. No, the thing that I've noticed, there really is a musician to engineering pipeline. Because that -- I think it's a similar problem solving space, right? Like you -- you're looking at patterns, you're looking at ways to combine old patterns in new and novel constructions. And that's what makes things interesting and exciting. And so, what I found, I've made this joke before. When I was a musician, when the band broke up, I learned that the only thing about being a musician that I wasn't good at was making music. All the other parts, the booking and like all these things that were business skills, right? How to go on tour. And also the construction parts of music. Like understanding patterns and all those other things, that all felt good to me. So, when I moved into a Dev, oh, man, like 95% of these skills crossed over. It's really interesting to see how that works.

MATT: It feels in many languages that Dev is a more limited language than music itself. Music feels a lot more broad in terms of the genre and just the stuff you have available to you. It feels like you could go massively into depth in terms of harmony and scales and stuff. And JavaScript, its API surface is tiny in comparison to music itself.

JASON: Yeah. And we're seeing like a couple really good comments here. Music is the original programming language. That's true. Because if you think about it, when you write sheet music, you are providing a set of instructions to a future -- I mean, to a machine. The machine was hand-operated. Like a piano or a violin. A set of machine instructions. That's fascinating. Math is the OG language. Yeah, you're probably right. But really, this stuff is so fascinating to me because it really is -- it all just comes down to patterns, right? How do you communicate somebody else what you wanted -- what you intended? And so --

MATT: To me, the other thing too, the problem solving element of teaching was something I just got addicted to. Especially with like a singing teaching and voice teaching. Someone comes to you with like a specific problem. Like I can't hit this note. And it's like a mechanical thing. You know? Often it's an emotional thing too. Like you have a sense of the person feels like they can't get there. And so, their body tenses up and all this sort of thing and you get this tension. It's correcting that mechanically. So, interesting and there's so much in-depth knowledge out there. And so, coming to Dev, it felt like, oh, this is -- we have this very complex system that we're building. And it actually felt much easier than voice teaching, weirdly. You can't componentize the voice.

JASON: Sure. Yeah. That is actually something that's interesting. Like you can't -- you can abstract certain things, right? You can go out and get a drum machine and something and play loops. But it's not the same as when you componentize code. There's some really interesting stuff you can do with abstractions in code and all that. But that maybe is a slightly clumsy segue into what we're talking about today, which is TypeScript. Which is a layer of abstraction on top of JavaScript that adds typing. Right? And so, this has been the sort of thing for a lot of JavaScript Devs, myself included, TypeScript is a source of a lot of anxiety. It's just JavaScript, except it's definitely not and you get mystery errors. And there's sort of a programming language itself within TypeScript. And so, I get certain things. Like if I'm just gonna write a type and say, you know, I've got like a book and the book needs an author and a title and a publication date and I can just say, okay. Well, you know, the title is a string. The author is gonna be a string. Or maybe an author object if we've got more details. That all makes sense to me. But then you start getting into stuff that is absolute just so out of my comfort zone. Like why does this say, like, angle brackets T? And then there's like, you know, this -- all these other things that are happening. What is that? Why does that exist? That's kind of what we want to dig into today. We've talked about the early layers of TypeScript on the show before. We've had several great episodes. I'll make sure those show up into the show notes for folks. Actually, you know what I'm gonna do? I'm just gonna link to the whole TypeScript section on Learn with Jason. We're got all kinds of stuff in here. More episodes than I thought. Six episodes that I dig into TypeScript on Learn with Jason.

MATT: Nice.

JASON: Most stayed away from the advanced topics. We were building the foundational knowledge. If you are watching this today, if you have never used TypeScript before, you want to watch the video on demand. What are types and how you set up a TypeScript repo with the TS CLI and stuff like that? So, Matt. Why would someone need this, like, really advanced TypeScript?

MATT: Yeah. So, it's being interesting. Because TypeScript is like -- it's just JavaScript. It's JavaScript except there's -- I kind of like to think of it as it's kind of like you're speaking English. Except it's almost like you have your English teacher watching over you and with squiggly red lines while you're doing it. A lot of people react badly. This is terrifying. And they get good enough at TypeScript that they can make the red lines go away. That's great. I've mastered TypeScript. I know what my teacher is saying and I can understand that. That's really, really good if you're writing applications and consuming types. Kind of from other libraries. If you think you're building a Next.js app, for example. You might want type checking on get static props, all that sort of thing. And those type definitions that you pull in from a library, they have been crafted by someone. And a lot of that type code is really complicated and it's complicated in a way that it's pulling out different bits of inference and pulling things together. And TypeScript is an incredibly powerful language whether you get into the really deep stuff. And what it allows you food, it allows you to build incredibly flexible APIs that then application developers can consume. What it means, you can be at the top, trickling down all this beautiful inference and knowledge and power down to those below you. It means you can become an enabler to your team. You can become the TypeScript wizard on your team. That can build these simple APIs that are easy to use and consume. But that enable incredibly powerful type checking for free, basically.

JASON: Yeah, yeah. And so if I kind of grossly oversimplify what you just said, when we're talking about libraries, libraries are dealing with a lot of unknown inputs. And so, TypeScript gives you that really advanced capability to do the inference and everything you need so you're using typing as you're using the code. That's a really good use case for advanced TypeScript. If you're writing a library yourself and you know what the inputs are and you're not taking a bunch of arbitrary user line code, you may not ever need this. Is that a fair assumption?

MATT: Yeah, I think if you're consuming stuff from -- I think the point really -- or the dividing line is, if you're writing an abstraction, and virtually any abstraction, then you're probably gonna need some kind of -- even intermediate to advanced TypeScript to make that abstraction feel powerful. Because in JavaScript you can basically pull anything into a function, return anything out of a function, do crazy stuff like all through it. And if like you're not using TypeScript to its fullest extent, you probably end up with the user themselves having to annotate the code writing, this is this shape, this is this shape. Where if you can get it to a point that it's inferred throughout that, in any abstraction you write, then you're probably going to have a good time using advanced TypeScript.

JASON: Gotcha.

MATT: If you're building a team, they're force multipliers for the team. Doesn't matter if it's an application or -- if you're in charge of the applications, then you can really enable a lot of power to people.

JASON: Okay. So, then a revision, then. If I can kind of walk this back a little bit. Is that where these generics and other advanced TypeScript concepts really start to shine is when you are building code for writing code. Right? Like so if you're building an application and you're gonna ship that and that's what runs in the browser, you probably can figure out enough about how your code works to not need any of these really advanced things. And personally, I'm a big fan of like if you can refactor something to be just a standard type, you probably should, right? Like don't get clever if you don't need to get clever. But as you start writing code that's a layer of abstraction to empower other Devs to build more things. You've found a common pattern and people are gonna wrap all their code with this thing that adds some thing. Then suddenly you have this deeper need to like accommodate for people are gonna do arbitrary stuff. And you want to support that without making them do a bunch of extra lifting.

MATT: Exactly. That's every Dev's code, write code that empowers other Devs. That's why people get excited about open source work, and they're enabling people to work faster. That's what this allows you to do.

JASON: Absolutely. So, I've said the word "Generic" a couple times, and I'm going to do a little confession here. I don't know what that is. In the highest -- like lowest level of fidelity, what is a generic in TypeScript?

MATT: Imagine you have a function. A function takes in something and returns something. A standard type is just a static variable, inference book, user ID and blah, blah, blah. But if you wanted to make different shapes within them? Then in JavaScript, you would create a function, okay, I have my book, and inside my book, I have something else. Imagine in you have like an interface for when you return some data, for instance, from Axios or Fetch. Okay, I've got my data. But I don't quite know what that is. So, I'm gonna make a function which takes in the type that I want to attach to that data. And that is a generic. That's a generic type.

JASON: Okay.

MATT: I can't wait to explain this with code.

JASON: Yeah, I'm actually wondering if we should do that. Okay. But first, we've got one -- I don't even know if this is a spicy question. But it's a good -- it's a good question here. So, big hairy dude, nod for the wonderful username, asks, are generics a work around for the fact that TypeScript has locked you into types?

MATT: No, I don't think so. I think -- I think you might mean has locked you into using types. Forced you make sure everything is correct. I think that's my interpretation of the question. I think.

JASON: Yeah. Because like my gut feel on that is no because the work around is to just mark everything as "Any." Like if you really -- if I have a library and I'm like, I don't want to figure out how to type this thing because you're literally passing arbitrary code, then I would just make an argument called code, and make it any, and you send me whatever you want. That's the work around. Generics are almost the solution for needing that work around.

MATT: Exactly. They let you hack into TypeScript inference and let you kind of build these APIs to allow TypeScript to understand the flow of your code better. That's what TypeScript wants to do most of all. It just wants to understand what your JavaScript is doing. It's really good at that in a bunch of different ways. But it has limits and these allow you to extend those limits outwards.

JASON: Gotcha. I'm with you, I'm feeling it. Okay. So, knowing that the rest of my questions are absolutely going to be easier to explain in code, why don't we just hop into code and make that happen? So, I'm gonna take us over to -- let me get the right things on screen here so that I'm not putting us into the infinite loop. And then I'm gonna take us into pair programming view. And so, first, this episode, like every episode, is being live captioned. We have Amanda here with us today from White Coat Captioning. Taking down all of these words. Thank you very much. If you want to watch that, that is on the home page of the site, learnwithjason.dev. And we are also talking to Matt Pocock on Twitter @-- what did I miss? I added too many names.

MATT: Probably reflected to that, anyway.

JASON: I'll drop this in here. Everybody give Matt a follow. And we're talking about TypeScript which is something you have been working on a lot. You have this Total TypeScript site, that is absolutely gorgeous, by the way. Look at these illustrations. Really there's some good stuff going on in here with --

MATT: I did not do this. My favorite bit is this error message on fire. I said the illustrator, I want the error message to look like it's coming from the depths of hell. And she did an amazing job.

JASON: It's so good. It's so good. No, this is wonderful. So, I love it. I love it. This is -- so, this is really fun. Everybody go check this out. Make sure you get on the -- there's an email list on here, right? And that has a bunch of free resources on it. So, make sure you get there. And with that, I have absolutely no idea what to do next. You had me -- let's see. Let me clear this out. You had me download this repo.

MATT: Correct.

JASON: And so, I've got that. And that's over here.

MATT: So, yeah. This is on -- maybe we want to link this as well. This is the Total TypeScript, what is it? TypeScript Generics tutorial.

JASON: Let me find that. It is here. Go to GitHub.com/total-TypeScript. And then I need this name here.

MATT: Yep. You got it.

JASON: There it is. Okay. Let me throw this to everybody. There you go. Got a lively discussion about generics happening. Thank you all for getting in there. I'm looking to see if there are questions. Doesn't look like there are. We will carry on ahead. We have this repo. This repo is part of the Total TypeScript thing. But we are getting into generics today, which is the advanced TypeScript that I want to learn. And I've cloned it. I have it here. So, what should I do first? Like do you want to do a little tour of the repo?

MATT: Yeah. Sounds good. The repo is simple. If you go into the source directory, what you'll see is a bunch of different problems and solutions. And all you've got to do to complete this repository, to complete these exercises is go through them one-by-one, look at the problem first and then see if you can solve the problem that's in there. Usually that problem is, there's a type error in there or there's something wrong with it. A lot of them are not kind of explained perfectly. Like I haven't gone through and added comments through all of these. This is still a semi-work in progress still. But what we should see it see if you can solve the problem and understand it. And if when you are finished, have a look at the solution or solutions if there are multiple. The solutions are usually telling you didn't ways that you could have solved the problem. And what you can do is when you finish this, you can go in chat as well. We can do this together at the same time. And you can ping me on my Discord as well. There's a bunch of people in my Discord going in this. I should drop a link in the chat.

JASON: Is that in here somewhere?

MATT: It's in the linked there. It's relatively new. I will drop a link in the chat.

JASON: Okay.

MATT: But that's the fundamental stuff to do with the repo. What we should probably do is do an npm install. That's the next step.

JASON: Npm install. Okay. So, there we go. Here's the Discord. I'll go ahead and accept that invite now. I can't, because I don't have Discord open. I'll do that later. But yeah. So, oh, that installed faster than I expected. I thought we were gonna have to kill some time.

MATT: There's not much in here. What we have to do now is run npm exercise-01. Very nice. So, what this is gonna do, then, is it's gonna do -- oh, we finished the exercise. That's unexpected. If you go into exercise 01, what you'll see is that there's a challenge. And there's a comment at the top.

JASON: Okay. So, we are -- all right. Let's take a look here. How do we refactor these to reduce the duplication in the data declaration? So, we've got user data that has data. We have post-data that has data. Comment. All right.

MATT: And then this stuff at the bottom is basically a bunch of tests. It's testing that the types above it are what they say they are. So, if you comment on the line 24, for instance, on that comment and just remove that, then we're going get a type error down the bottom.

JASON: Oh, and it's running as we go. Oh, perfect. Let me pull this over here. And then I'm gonna close this up. And then -- we get an error down here, nice. Okay. Great.

MATT: So, here, our challenge is, we've got these three objects and they all specify a data attribute. It's kind of what I was describing before, actually. And so, there's an opportunity to dry up this code. We can take these post data, comment data, and the other data, what is called user data, and we can -- there is a way using TypeScript that we can dry them up. So, with your --

JASON: Okay.

MATT: Extensive knowledge of Generics, Jason, take us through how we do that.

JASON: Here's my guess. If I wanted to pseudocode this, I wanted an interface for like a data wrapper. And that will take one field of data. And then that needs to accept options. It will take a user. It will take post. Or it will take comment, right? And so, that would be my -- my gut. And then you're making it sound like this should be generic. So, the data should take a generic. Okay. So, if I do -- let me see what I can figure out. Again, I haven't actually written one of these before. So, I'm going to say interface Data. And then generic is the T, that's right?

MATT: That's correct.

JASON: I put a T in. And then in here, my new user data would be like export interface UserData extends? Implements? No, what is it? Something. Data, right? But then it's still gonna be -- okay. I've -- I now need to know more about how this works to start. Because if I was gonna do it this way, I'm already -- like all I'm doing is saying, oh, this should be data. And that wouldn't work. So, I would instead want it to be interface user, which would be these. And now I don't know what I'm doing.

MATT: This is fascinating.

JASON: I need to get this into here.

MATT: What I'm seeing, you're approaching it from an object-oriented thing, it needs to extend from this. When I think you should be thinking it in a more functional way. Why don't I drive. You are super-close. You can see my cursor, right?

JASON: Yep.

MATT: We're using live share to pull me into this as well. I'm not magically hacking into Jason's stuff. This data thing here, call it dataWrapper. That's a perfect name. What we want to call here, we have a function, dataWrapper. Imagine writing this in JavaScript. We have a dataWrapper, and take in the thing, which I just call any, and we return data, which is the thing. That's the kinds of mental model we need to have here. Which is we now need to create this on the type level. Because this creates actual runtime objects. But we actually need to put this into the type world. So, our dataWrapper here needs to somehow take an argument. That's the thing. And the way that argument works is with this syntax.

JASON: Ah, okay. All right. So, we've just touched on two things that have always confused me. First, is the inclusion of these angle brackets. And the second is the letter T. So, T, we've decided, is generic. It's a place holder for whatever type comes in. Right? And angle brackets are the equivalent of a function call in a type, is that correct?

MATT: Exactly right. They're the equivalent.

JASON: Okay.

MATT: If we could write them with parentheses, weld. We would write dataWrapper T. Like this.

JASON: Okay.

MATT: This is the syntax that TypeScript has is chosen. We can call it anything. We can call it Tdata, TJason, we can call it thing. T is just a convention. We can add as many as we want. T1, T2, T3. It's just function arguments.

JASON: Got it. Okay. Well, that's I would say the first major lightbulb moment of the day is demystifying what the heck these are in TypeScript. And to all of you who already know, congratulations. To everybody who just learned along with me, you're one of today's lucky 10,000!

MATT: So, here then --

JASON: And if you don't know that one --

MATT: I do not know that one.

JASON: It's a comic from XKCD about learning things. Very good. Let's --

MATT: I can't just read it live on the stream. That's not good entertainment.

JASON: No, it will be in the show notes.

MATT: We've now got the function that turns in the T data and returns a wrapper with T data here. We can delete this dataWrapper because it's doing the same thing, but on the type world. And now we have an issue. Which is our user -- we've got our user data down there. And we need to somehow like call this function to return and you type.

JASON: Right.

MATT: So, the way that we do that is we would say, let's say we have type, whatever. And I find myself doing this a lot in TypeScript by the way, just creating these sort of dummy variables. And I'll show you why in a second. We can say now dataWrapper. And we can call it with whatever actually whatever we want. Let's just call it with a string. A string like this. And now if you, Jason, if you hover over this whatever thing, here. You'll see, it's typed at dataWrapper string. Now, let's actually create a variable called const whatever. And we're gonna give it a type of Whatever. Now, inside here, if you hover over that error, what's that telling you there?

JASON: Property data is missing. But required. Okay. So, then if I come in here and I add data. And I want to do one of these. Now it's mad at me. Because it wants a string.

MATT: Exactly.

JASON: Now we've got some useful stuff happening.

MATT: Yep, definitely. And actually --

JASON: I think I can take over from here. I think it just clicked for me. What I want is I want my type of user data to be a dataWrapper of user. And then I want this here. Because now what I get is if I do a user -- user data. And then I have my data. It autocompletes with my stuff.

MATT: There you go.

JASON: Wait. But it wants it to be a string, doesn't it? There we go. Okay. So, is that how you would have done it?

MATT: Well, let's check the solutions.

JASON: Okay. Great. Let me comment this out. So, it's not yelling at me. And then we'll open this up. Let's look at the solution. Blow this out a bit. Okay. We have the dataContainer, that's what we did, user data, comment data. Oh! Oh! I see! You abstracted it even further.

MATT: I didn't --

JASON: You de-abstracted it.

MATT: Yeah, I didn't declare the other interface. I just went in and put the object primitive in there.

JASON: Got it. I didn't know you could do that. That's really handy. We have a second solution here. That an alternative approach?

MATT: That's right. Alternative approach.

JASON: Okay.

MATT: And that one I think is declared data contain we are a type instead of an interface.

JASON: Oh, with a type instead of an interface. And so, in this instance, does it matter? What's the difference between a type and an interface?

MATT: Types can represent anything. Whereas interfaces can only represent objects and functions in some cases. That's the thing I get asked most of all. Should you use a type or an interface? And the answer is, you can use whatever you like. Basically. As long as you're consistent, it doesn't really matter.

JASON: Okay. Okay. Cool.

MATT: We are finished.

JASON: We did it. We did a TypeScript. So, yeah. This is -- this is really, really good. Oh, my goodness. My middle name is Danger read my book, Untethered. I forgot that book existed. Yeah. That's a blast from the past. I have not done that -- let's see... in like 2014 I lived out of a suitcase for a couple years and I wrote a book about some of the stuff that I did. Like how I made that work to get out there. That's what that book is. It's self-published on Amazon. I think a lot of it might be outdated. and it's definitely gonna be a surprise what this stream is about if you came looking for Untethered content.

MATT: I should say my wife is writing a book as well on -- identification.

JASON: Oh, that's gonna be a lot of interest to my partner. All right. Let's do another one. Should we just do these in order? Or what you want to highlight. I don't think we have time for all of them today.

MATT: Number 2 is a banger. Let's do number 2.

JASON: Number 2 is a bang -- all right. So, this one doesn't have a comment on it. So, let's just look at what's going on. So, this one -- let me do two. It's mad. It says type false does not satisfy the constraint: True. Okay. That makes sense. And let's go and look. So, return what I pass in, unknown. It returns it.

MATT: Yeah.

JASON: Why does that happen?

MATT: Yeah. You think that -- because really what we want is if you hover over, on Line 7, hover over 1 there. You would expect this to be of type 1. That's what you've put in there, right? You've put in the literal number 1, and you would expect it to just be returned there. But actually, it's typed as unknown. And the same is true for Matt down below.

JASON: Right. Oh, and I see, down here we're saying type of 1, 1, type of Matt, Matt. We're not getting that. That's where the false is coming from. Okay. Now I understood how these tests work. So, I can then up here we need to figure out how to do --

MATT: Don't look at chat. Someone's already got it right? Chat.

JASON: All right. Chat, shield my eyes. All right. I'm gonna do an interface. And I want it to be... I mean, should it -- is it... is it just like... wouldn't that... nope. That's not right. How do you return something from TypeScript? Because what I'm thinking is if we did it at a function, right? It would be you get a type. You literally just want to return type.

MATT: Right. One way you can express that is with a type itself. You can say type Fn. You go from there. I'll let you drive.

JASON: Yeah. Okay. So, I do a type of Fn. And then I need to pass it in. A T type generic. And then I need it to return. And what I don't know is what's the -- like you can't just do one of these, right? So, what's the syntax here? Is it -- that's not right either.

MATT: I'll give you a clue. Which is you're entirely -- well, you're on the right track conceptually, but syntactically you're in the wrong place.

JASON: Yes. Okay. So, if my type is like this, and it needs to return something. The thing that it returns is one of these, right? But I still don't know... wait, I know I can't just do that.

MATT: I'll give you a clue, it actually needs to be --

JASON: This is where my syntax falls apart.

MATT: There's a few ways that you can express this. But the way that chat is pointing to is -- it actually needs to be sort of inside this function declaration here. So, it's -- we're actually going to inline the generic here. And the way --

JASON: Okay. So, I need to do something like... this and then this?

MATT: You're like --

JASON: And like that.

MATT: You're so close. I'm going to leave this so chat tortures themselves for a second.

JASON: Come on, that works. What are you doing?

MATT: It's really close. Let me show you. So, you were dead close with this, but syntactically, what we have to do is just move this to the other side of the equals. So, this now declares it as a generic function instead of a generic type.

JASON: Got it.

MATT: So, what's going on here, and actually, you were thinking, how do I say -- how do I return this? Well, in TypeScript, you can declare function return types using this colon here. If I say I want it to return a string, I would do this. But actually, let's say we go to TItem here. And TItem here too. And actually here we're going to return TItem.

JASON: Right. So, that's a lot of repetition here. Does that dry out at all? Like because I guess the thing that I notice here is that we've got like, okay, so, we're passing an argument to our type. We're passing an argument of the type to our function. And we're returning our function. So, there's not a way for this to like infer where if we were to drop this entirely, it would still work? Clearly not.

MATT: Yeah, if you do that, it looks for a type in the above scope of the TItem. With the name of TItem.

JASON: Okay. Gotcha.

MATT: This is a type declaration. And this is available for the rest of the thing. We have to add it here. Because we have to then assign that to an argument.

JASON: Right.

MATT: So, that's the reason that's there. We can actually drop this. Really cool thing about TypeScript is that it knows that if you hover over this T just here, you'll see that it's actually typed as TItem. It knows this is the thing we're inferring from. So, this is the thing that we pass in.

JASON: It can do inference. But you have to make sure that it's got the right places to work. So, this is the type declaration and this is saying where the function uses that type declaration. But if we're just returning it directly, then TypeScript is smart enough to know -- got it. I understand.

MATT: Exactly.

JASON: Okay.

MATT: So, that's the type declaration. And that is the type assignation.

JASON: Now if I save this, our test should pass.

MATT: Yeah.

JASON: It did. Great! And so, you've got a couple options in here. So, this is like a hard --

MATT: Well, this option you'll notice that there's no T happening here. This is using a technique called function overloads. And function overloads allow you to actually make the tests pass here. Because what we're saying is on Line 3, got return what I pass in. If we pass in Matt, return Matt. Up here, if we're saying if we pass in 1, return 1. And then down here, we say, we actually implement the function and we say, return what I pass in, which is unknown. And we return the T. And so, this does make our test pass.

JASON: So, this one feels a little bit like when you write a function like is odd. And then you start doing like if...

MATT: Yes.

JASON: Yeah, like one of these.

MATT: That's such a great way of putting it. Yeah. That meme from whomever posted it. Right.

JASON: Right. And you find yourself writing all of these like. Ope. Better do another one. Ope, better do another one.

MATT: The thing I remember, it was such bait for the mansplainers. Did you use the module? So good.

JASON: What was that? Cat Maddox? Such a good post. I'm not going to be able to find that actual post. But I am gonna kind her Twitter because it's amazing. It is full of -- full of good information. Cain. Oh, Cain now. Okay. Yeah, Cain is freaking hilarious. So, all right. So, and then what we've got here... is the generic. So, I'm gonna undo my work in here so that we don't get... all right. Oh, here's our -- here's our generic. Great. And that's what we ended up doing. So --

MATT: Yeah. There's one thing to note in here before we continue too. Which is that TypeScript give use like really good -- oh, trash is raiding. What's up, trash?

JASON: What's up, trash. Thank you for the raid. Welcome, everyone.

MATT: He considered himself an acolyte wizard, going through the challenges. Like a Hogwarts first year.

JASON: Gotcha, gotcha.-

MATT: He's passed his AWLs. He's smashing it. Roll through this stuff.

JASON: Great, great, great.

MATT: So, the thing to look at here is that if you hover over -- sorry, let me get back to the file of mine. Oh, we're in the solution 2, aren't we?

JASON: Do you want me to move back?

MATT: No, if you hover here. Return what I pass in. You'll see that you get the generic actually get locked in there. Which is super-duper useful.

JASON: Yes.

MATT: And create another one of this, const obj, returnWhatIPassedIn. And 32 -- I don't know why GitHub Copilot thought was 32. And then you pass in, so, TypeScript is really good at giving annotations to tell you what generic has been locked in at what time.

JASON: Sorry, the chat is just giving each other crap and it's making me laugh. And this is the stuff that I think is really useful here. Because this is the piece that's magical, right? Because later, when we go to use this, it autocompletes for me based on what we're using, right? And so, that -- that's the part where... like early on when people were telling me about why I should care about TypeScript and they would talk about, oh, you want like compile errors early and, you know, you would want to have that type safety. I don't care. I don't care. I don't care. I'll fix that error. When the bug happens, I'll fix it. I understand academically, eat your vegetables, write your tests, declare your types, all those things. But also, I'm under deadlines and I don't want to do it. Then someone showed me autocomplete. And now I care about TypeScript. The idea that if I write these types, I don't have to go look at the code declaration to use it. Absolute game changer. That's the part where I started including first the JSDocs syntax, defining my params to get type completion. And then I saw, that's not going to bed a flexible as you need, I took it one step forward. I started writing actual types. If I'm writing something I'm gonna share with somebody else. I do it in TypeScript. Not because I care about type safety, but because I care about this autocomplete. I want people to use it without having to think about it. That to me was the real killer feature.

MATT: It's a way of passing on the DX bat to your friends. You get to say, hey, I built this cool thing. You don't really need to looking at the docs to know how to use it. You can just figure it out. Anything you get from it is going to make the rest of your codebase better, easier to use, safer too.

JASON: Yeah. And that -- and there are like, I felt all the benefits of like you write your types and then you change something and then get a type error, oh, I forgot to update that piece of code. I'm not saying you should not care about that stuff. You should. But where it emotionally struck home for me was autocompletion. This is why people care. This is the magic.

MATT: It's the feeling of, oh, my teacher wants me to do well. Sure, they were being hard on me amount the start, but actually they do really know what they're doing. And thank you.

JASON: Yes. Absolutely. Okay. All right. So, what should we do next? Which one should we tackle next?

MATT: Let's have a look. Yes, let's go on to number 3. Number 3 is a good one to introduce some nor generics stuff. Let's expands on what we've got so far.

JASON: This one is absolutely riddled with errors. So, let's take a look. It's expecting that our string set will be a set of strings, set of numbers, unknown set of unknowns and we are seeing -- let's see. We get... we create a set and that's supposed to be a set of numbers. This says we want to pass in a number. So, here. I want this to take a set of numbers so it should return -- okay. I think I have an idea. So, we -- we are passing in our generic here. So, we'll say type. Right? And then what we want is to return. And I'm making a guess... did I do it on the first try?

MATT: Whoa!

JASON: Did I just learn TypeScript? What up, chat?

MATT: Trash, this is how you do it. Trash, by the way, this is how you do it.

JASON: Okay. That's -- okay. All right. I'm just gonna take this little clip, I'm gonna put it up on my wall.

MATT: Can I say you not only -- you not only do it first try, but you actually found a solution that I haven't included. so, there we go.

JASON: Okay. So, here was the guess that I had to take. If I tried to use set, it would have a built-in type. That was -- all right. So, maybe let's walk through a couple other ways that we could do this. Because I apparently found something that you didn't do. So, should we look at the solution or do you want to talk through another one?

MATT: Let's look at the solution.

JASON: All right. Here we go.

MATT: The solution is too. What's didn't between this and your solution?

JASON: Ah, so you dropped it in here. Here we're telling the set itself to accept the generic.

MATT: Yes.

JASON: And we're saying what's returned will return the generic?

MATT: TypeScript can do it either way. Refer the return type, or refer it from the return type from what your code does.

JASON: Both of these look pretty clean to me. I think this -- yeah. I... I don't -- I feel like I would have gotten here eventually. But here's the other thing. If this wasn't a built-in type, if VSCode didn't just know what a set was, this would be way easier than trying to figure out how to get a type from the set.

MATT: Yes. There's a couple of wrinkles with this whole setup -- setup. Which is that if you notice that T type here inside -- yeah. Where are we? Yeah. Here we're not actually using it in any of the arguments of the function. So, it's not actually being inferred anywhere. If we were to pass like ATType here. We could actually remove and say a, as string. Hello. And now it would infer string from the argument that's being passed in. So, because we're not passing an argument, we're actually using this generic slot as a kind of -- a slot where you can pass in a type yourself.

JASON: Right and so, what we're saying is you have to decide here.

MATT: Yes. That's it.

JASON: If you don't use it, it will be unknown.

MATT: This is similar to if you have used React. It is similar, you have a use state here, ID, set ID. And you would have to manually pass in here that it's a string. So, generics are interesting. They can be inferred from TypeScript itself. And from just like the call. But you can also override them at the call site and manually pass in your own stuff.

JASON: Gotcha.

MATT: And Jason, dunk on Trash. Yes.

JASON: I was dunking on the entire chat, Trash, not you specifically. But I mean, I'll -- yeah.

MATT: I got you, man. You're gonna raid us, you got to be prepared for this stuff, you know?

JASON: If you hover over set in the code, it will show you the generics available?

MATT: Yep. That's true. If you -- yeah, command -- and here's something crazy you can do. Try command clicking on set.

JASON: Command clicking onSet. Here we go, here we go.

MATT: Double click inside there to open it up. Yeah, perfect. We are now in lib.es2015.collection.d.ts. They cannot follow you, you are in the deepest, darkest dungeon of TypeScript. These are the type definitions for the JavaScript language itself. We're down with the Balrogs and down with the scary beasties. And we can see here all of the methods that are implemented on set. We have set add, set clear, set forEach. And here's what's crazy. We can comment these out. Comment out lines 59 to 64 or whatever. Come on, let's break it. Let's break JavaScript. And now try and go back to the problem.ts file, the one just in the tap over there. And now try to do anything on these string sets or number sets you'll see stringset.has, foo. And set doesn't exist anymore.

JASON: I hate it. Okay. Then it comes back. So, if you ever want to, you know, if you do end up being one of those folks who works in an office. I guess the 70% of who are not -- well, not me. I don't work in an office. If you are back in an office and you want to ruin your coworkers day, Matt Pocock has provided the solution. When they retaliate by trying to ship their enemy's glitter, give them Matt's address.

MATT: Come on. I hate getting glitter in the mail. Really rough. Sequins in the post.

JASON: I don't know if there was a service -- there was a service for a brief moment called Ship your Enemies Glitter. They would send an envelope completely full of glitter. I think it was something where when you opened it, it would make the glitter come out of the package. Yeah. It's a full rough.

MATT: But yeah. Well done on Number 3. You smashed it.

JASON: Smashed it! All right. Now -- should we just keep going on 4, 5? Where do you want to go? We've got -- time checking, we've got about 35 minutes left, so, if there's anything you really want to show, let's get there.

MATT: This is lame, but number 4 is good to go to next.

JASON: Okay. Fetchers is an object that you can optionally set keys for the route names. This is the route names, how do but prevent the user from passing fetches that are don't exist in the routes array? Oooo... okay. I've seen a thing in TypeScript that I only lightly understand where people do things like pass in key of or value of. Is that the direction you're trying to go right now?

MATT: I'll give you a clue here. The thing that the question is asking you for is impossible.

JASON: Oh, interesting. Okay.

MATT: What's it's asking you to do is try to find a -- an API that would handle this. Because if we think of a generic, a generic has to exist in the context of a function, right? It has to be something that either you pass in or is inferred and then returns something else. And there's like -- I'm expecting you to the to be able to solve this one, by the way. So, we can like shift over to the solution. This is like an extremely tricky one. This is interesting.

JASON: Wait, wait. No, we can do it. We can do it. If we pass in -- can have MATT: I'm just gonna shake the window.

JASON: Literally leaving me to my own devices. We're about to learn TypeScript with Jason. I'm gonna make it up on the spot. It's gonna go great. What I want to do is if I want to pass in -- if I want to pass in the routes. And the routes are gonna be one of these... pronounced "Trout." But then I would pass in one of these. No. One of these. No. I'm already lost. Okay. So, let me pseudocode what I'm thinking, because that will be easier for me than trying to write TypeScript since I don't know a lot of the syntax. So, what I'm picturing here is that we're gonna return these objects. And so, like each of these would be -- would be like... routes.map then you get your route. And then that's gonna return back... the... return. Right? So, we get our actual route -- or no. It would need to be like an object. Which would be route. And that passes in this function. I did something terrible here. Oh, I've double-wrapped it. Okay. So, this is my -- this would sort of give us the ability to do this and then if I knew that this was gonna a route... and then each of these... needed to be -- oh, oh, oh. Wait. Ah. Ah? No. Not quite. Not quite.

MATT: What you're building here is really cool because it shows the constraints of the problem. If you think about TRoute here... this declaration, this generic, is only valid for this scope. It's gonna be out of scope.

JASON: Oh, it won't come down.

MATT: Exactly. It won't -- like you can't pull it in from outside the function. So, we somehow need like TRoute to be up here in the top level.

JASON: Gotcha. Okay. Okay.

MATT: This isn't valid syntax, right? So, how are we gonna get around that?

JASON: So, now we need to start identifying a type up here. Or I guess -- whatever -- interface. And then... this would be config. Not would take a TRoute?

MATT: Yeah, definitely something there. You're on the right track. Getting warmer.

JASON: Okay. And then I get my routes... which is gonna be... the array of routes. If I'm right.

MATT: Correct.

JASON: Accurate syntax. And then it would be like fetchers. Would need to be one of these.

MATT: You don't need to re-declare the TRoute again because it's already in-scope.

JASON: All right. So, I'm gonna get my routes. Which would be TRoute, like this. And then that gonna return... wait. Each of these would return back... the... oshsh. My syntax is failing me. How would I declare this that is?

MATT: Yeah, this is tricky. What we want to express --

JASON: But that's still wrong. That would let anything come in. Is there a way to get like what was sent here to pass in here?

MATT: Yeah, like --

JASON: Like a value of or -- because what I would do if I was actually trying to check is like, if, route... or it would be... like route -- would have to rewrite some code here. But... you would do something like that to say like if what you're being passed is included in this route up here, then -- then you can go. Otherwise you would need to throw an error. So, I want to do the same thing by getting whatever the value of routes is and then passing that in here. Which is exactly what you've asked me to do and I'm now unable to do it.

MATT: But like, this is hard. Because what we're doing here is we're saying, this slightly changes the API down here. Right? Because --

JASON: Right.

MATT: Because down below, sorry, in fetches. No longer saying this is an object, it's a function.

JASON: But I'm not allowed to refactor the code.

MATT: You are a bit. But the function is in the wrong place. GetFetchers is no longer needed, basically -- let's, I think. I think if we go to the solution, it's going to elucidate what I'm saying better than I can say it. Because you are super-close.

JASON: K in TRoute! I knew it was possible! Dang it. So, yes. All right. So, this is the -- the value? Is that right?

MATT: This is kind of like --

JASON: X and Y is the -- is a -- is -- so, when you do like an X and Y... right? It would be like that would do the 1, 2, 3, this is the X and this is the Y.

MATT: Yeah, exactly. Sorry if you can hear a storm blowing outside. It's absolutely crazy here. So, yeah. What this is doing is, it's basically creating an object out of the routes. So, if I were to create a type of route, for instance, it's going to be fruits or, sorry, yeah. K in apple or banana and we create a string here. So, we say const Fruit is fruit. And inside here, it's gonna ask me for apple and then banana. And I can add things to this. I can add things to this union. I can say, cheese I know isn't a fruit. But that's the only thing I could think of. And this is basically creating a object from these types here. And TRoute is gonna be a union of the things that we pass in.

JASON: Right, right, right. Okay. So, more practically, what that means is, when we pass this in, right? We get these values. So, what this is becoming... is... this.

MATT: Exactly.

JASON: That also works because of the way that we've defined this code. But it's not flexible because, again, you've hard-coded everything.

MATT: Exactly. So, that, then, if we revert that, that TRoute represents the union of those three thing there is. And we can see, though, that it's not quite perfect. Because if you look down at config objects here. And actually, if I add in a -- in fact, this is gonna blow your mind, first of all. If you go into fetchers and try adding a new one to that object. First of all, you can see all the autocomplete in there. Try adding a new one.

JASON: The autocomplete is already amazing.

MATT: And you see all the stuff we've added in there, it's all in there.

JASON: Beautiful. Absolutely beautiful.

MATT: But it's actually not working as well as we think it is. Because if I add something else to this -- if I go like, not a route. Then it's actually going to yell at me. Because it's saying if you hover over that error, not a route is not assignable to thingy, thingy, thingy. Because we're actually passing in the generics up here.

JASON: Oh. Wait. And we can't just leave that out?

MATT: No, if we leave that out, everything falls apart.

JASON: But we -- what if we do... that?

MATT: Then we don't get autocomplete down here?

JASON: Boo!

MATT: Boo! Yeah, quite. The lesson here is generics cannot exist at the scope of objects. They have to exist within a function. So, let's have a look at solution two because I think you're gonna like that one a bit better.

JASON: Okay. So, we've got fig object, TRoute. Extend string. Okay. And now this -- by extending string, we're saying the route has to be a string. That's what we mean when we say "Extends."

MATT: We're constraining it to be a string.

JASON: Got it. Sets up a route here, and route, and allowing that back, that's fine. That's not really what we're worried about here. Make config object. So, we're doing -- we're passing in the TRoute, extended string. And then we need to get back a config object that gets passed a TRoute. Right?

MATT: We're not getting that back, we're actually passing that in there.

JASON: Ah, right, right. So, I see. We're like doubling up here. We've got -- we've got a generic here. But we have to get that generic into here so we're -- we're kind of doing double duty. Do we need a double... the double extends? Or would this one kind of pass through?

MATT: Try deleting -- let's try deleting this one and see what happens.

JASON: Okay. Now it's unhappy.

MATT: And it's also unhappy on Line 13, which is the more crucial error.

JASON: TRoute does not satisfy the constraint. Okay. So, undo that. Now, if I do this... unhappy. Not assignable to type string or number or symbol.

MATT: Only strings or numbers or symbols can be object keys. And we're creating an object out of TRoute there.

JASON: Okay. So, it won't pick up this inference if you pass through.

MATT: Correct. Yep.

JASON: Okay. So, we've got that there. And then, we have this function to make a config object which is more of what we wanted. Which is then picking up all of these. And if I delete this... now it says: Is not assignable to type -- a little messy. But... it does now give us our autocomplete and we didn't have to hard code those anywhere.

MATT: exactly. And if you add a new route, it is gonna give you more things to autocomplete.

JASON: We can get rid of the error... it's cool. And in here... do one of these and there it is. Okay. So, this feels extensible in a way that doesn't -- the thing that always makes me nervous about TypeScript is I don't know how to do this, right? So, the way that I would have solved this problem is by literally hard-coding all of those routes in. And then you have that problem where you've got two versions of your hard-coded routes. It just sucks, right? My way of solving is would be just write the code to do that check in here. Make that a function. Like what I started doing originally. This -- this feels nice. Because it does what we expect.

MATT: Exactly. And it actually lets you pull more logic out of your runtime code into your typing code. We're shipping less logic to the browser or to the whatever because it's more constrained within our type code. And now that make config object, that could live in a library. That could be something you distribute across your organization. And suddenly you have this type safe router fetcher thing that's available to anyone who wants to use it. You notice when we use it in Line 16 onwards, there's no type definitions here. Nothing you need to add to it to make it do its thing. It's doing the inference for free.

JASON: I saw a question from the first time chatter, Charles, the way we're typing on the screen, we're using VSCode Live Share. That's a plugin that you can get... here. Where is the actual -- here. So, this is a pretty cool service. If you've never used it before, definitely give it a shot. Tons and tons of first-time chatters. Welcome, everybody, if this is your first time seeing the show. I'm excited to see you. Hopefully you want to stick around. Remember, you can always, you know, subscribe to the channel, follow, all those sorts of things so you know when we're going live. We have two of these a week. It's a lot of fun. Okay. What should we do next? We have about 20 minutes.

MATT: Let's do one that... um... okay. Let's go to number 8. This is a really famous error. Because it gives you a really hard to understand error message. And understanding why it gives you the error message is really crucial to understanding generics itself.

JASON: That was which number? Sorry?

MATT: Number 8.

JASON: Number 8. Sorry. Let's take a look here. We've got object as const. Interesting. Object key of, type of -- a lot going on in there. So, wait, keyof, typeof object. So, this is the object. keyof, typeof would give us the union of ABC.

MATT: Exactly, hover over obj key.

JASON: That's exactly what we did, great, great, great. And we want to get the object key, TKey extends object key. And then A -- A is not assignable to type T key. A is constrainable to the constraint of type TKey, but TKey could not be initiated with a didn't subtype of constraint...

MATT: Yep.

JASON: So, that means this -- this matches technically. But if somebody put in a B, it would break. Because it would match this but this one is being stripped down to just A, is that correct?

MATT: Sort of.

JASON: No?

MATT: I'm gonna let you flail a bit longer.

JASON: Okay. So, let's think a little bit more here... type of 1 by default should be here. But it's not doing it. Okay. So, it's not picking up our default value. And it's not picking up our default value for reasons I don't understand. Because... I actually have no idea. Why doesn't it pick this up?

MATT: This is really brutal. This is like a really hard one. If you hover over one by default there. This doesn't really give you a clue. But it tells you that if we don't pass in our get object key there, it's giving us either one or two or three. Because that's what happening --

JASON: Right.

MATT: If you hover over this part of it, it will show you that when we pass in nothing to this function, the generic gets locked in as the widest it can possibly be.

JASON: Right.

MATT: Because you see here, the generic is extends object key, we're making it get object key. It's assignable to, or you're assigning to, then it defaults to the widest it can possibly be.

JASON: Right. Because we don't actually pass this argument, this assignment doesn't happen.

MATT: Yeah.

JASON: Is that right?

MATT: It doesn't happen -- and it happens at the runtime level, but it doesn't happen at the type level.

JASON: Right.

MATT: And so, hover, Tkey, could be instantiated with either A or B or C. And the different subtype of constraint is basically saying, it could be either B or C, and this default doesn't account for that. So, that's really hard to deal with. And there is a trick to do it, basically. And it will get you out of a lot of tight spots. And this always happens whenever you try to assign a default parameter that is more narrow than the generic slot that it's supposed to inhabit. And I can tell by the tone of your voice that you want me to show you the solution instead of like --

JASON: I'm gonna be honest. I don't even know where to start. Because like what -- because like I know what you're saying. We need the generic here to somehow be more narrow. But I don't -- I don't even know where I would begin.

MATT: Absolutely. So, the way to think about this best is if you actually go to -- I think number 2? And then solution 1. You remember we returned to this idea of function overloads. Which is if you call a function in one way, it's gonna return one thing. If you call a function in another way, it's gonna return another thing. Well, one amazing thing about function overloads is you can actually provide different generic parameters based on each overload. So, you can say, I just sort of scaffold some syntax here. We can say, let's imagine that A, a function gets something. We can say, if you pass in, a is gonna be 1, then you return 1. And I have the implementation down here, which is any. And then return as any just to shut up TypeScript.

JASON: Okay.

MATT: So, if we pull at something. Say const result = getSomething. And then if we say -- if we pass in our 1, if we hover over the result here, that's gonna be typed in as 1.

JASON: Okay.

MATT: Sorry, move out of the way. If we add in another, let's say you pass in, I don't know. A, which is gonna be Matt. B, which is gonna be Pocock. And we're actually gonna return here matt pocock.

JASON: Okay.

MATT: Matt Pocock. And then if we wanted one of these signatures to be generic. Let's say I wanted to add someone new to my family. And I say TName. And put in TName here. And TypeScript lets you do interpolation here. Tname Pocock. And I need to extend string.

JASON: Okay. So, we throw in another name. Like...

MATT: Exactly. And we could end up with Robert Pocock. Where if we just add 1 back in here and hover over it, then it actually doesn't even try to fill the generic.

JASON: And if we throw in just the 1, naw, get out of here.

MATT: It's going to try to make it fit. But it's going to error it here, if we try to say, Nancy Smith or something, then that's gonna error too. It should. Not erroring --

JASON: Or just overloads is...

MATT: That's really weird that it's -- I think we found a bug in TypeScript, actually. That's no good. Well, okay. Let's go with that quickly. But the basic idea here is then we need an overload that -- because there's two different cases here. There's the case --

JASON: Right.

MATT: There's the case where we actually pass something, and the case where we don't pass something and on the type level, those are two very, very different things. So, I'll do some refactoring too.

JASON: Right. So, in this case... we need key A. And that's gonna return A. And then the other one is the generic. But it doesn't like that.

MATT: It doesn't like that. We've kept the default parameter, then.

JASON: Oh, so we can just drop the default parameter.

MATT: Exactly.

JASON: Wait, wait, wait. But don't we need that default parameter?

MATT: We don't. There's actually a slight mistake here. Which is we're trying to look at this one here. And actually, in this case, when we don't pass anything, we don't pass any arguments. We shouldn't put an argument here.

JASON: Oh, you're right. You're right. We should -- oops. We're gonna go here. Okay. So, that's happy. That's A. But now everything else is mad because it wants these. So, I have screwed up our overloading.

MATT: We still need to get rid of the default parameter too. We don't need that anymore.

JASON: And now this is unhappy because, not compatible with its implementation. And that's because?

MATT: That's because the way that function overloads work is each one, if you imagine them stacked up, they have to be compatible with their eventual implementation. And the one at the bottom is where you actually implement the function. The other ones are kind of reflections above it that say, you can do this or this or this.

JASON: Okay.

MATT: But the way that we would make these compatible is we would say, you don't have to pass TKey here. You can actually do this.

JASON: And make it optional.

MATT: Make it optional. You know what? I think we need to brute force this a bit. By the way, this return type here, we're not actually returning A. Because we're returning -- we're using the A key to access the 1 here.

JASON: You're right. So, this would instead be a 1.

MATT: Exactly.

JASON: Right?

MATT: And what I'm gonna do instead, I'm gonna just move this one up to here and say this is going to be -- just get this crud out of the way. And the key is TKey. TKey. Then we're going to say, typeof obj. We need to kind of like declare the return type here. I'm gonna call it typeof obj TKey. That syntax there, how scary does that look?

JASON: Looks pretty terrifying.

MATT: What we're doing there, is if we say... let's say we go type whatever equals typeof obj. And pass in key here. What type is that going to be?

JASON: It's going to be a number, right?

MATT: A number or --

JASON: A is gonna be there did -- oh, the literal 2.

MATT: Exactly.

JASON: Got it. Nice.

MATT: How about if we pass in B or C here?

JASON: Then it's a union.

MATT: Correct.

JASON: Okay.

MATT: In this case, we know that TKey extends the object, because it's there. And that means that what does this then mean

JASON: This means that basically whatever is passed here, we expect it to be the number literal that's inside. Okay.

MATT: Exactly. Yep.

JASON: Now, it's still unhappy because... implicitly has an any. Can't be used to read-only. Okay. So, the piece that I'm missing here is that I don't know how -- like because we need this code, right?

MATT: Yeah. We didn't -- yeah. We do need this code. What we... what we now need to do is... let's see. Why is this erroring here? String... ah! The reason here is the key here is typed as if you hover over that word there. Is it's typed --

JASON: Why are you a string?

MATT: Why is it a string? How can we make it more narrow than a string?

JASON: One of these, right?

MATT: Yeah, except we don't -- inside the function signature itself, we don't need to re-declare -- the way that function overloads work, you don't need to -- they get sort of wider as they go down, basically. This TKey here, this one is only relevant for this declaration there.

JASON: Okay.

MATT: And so, actually what we want to do is instead of TKey, we just want to put it to the constraint. Which is ObjKey.

JASON: Okay.

MATT: Which is up here.

JASON: And now it's happy.

MATT: Now it's happy. We have manually gone through and specified all the different cases we have there. Before what we had, on the type level, okay, I want you to think about A or B or C, but by default, only do A. And trying to do that in a tiny syntactical space. And TypeScript didn't understand what we were doing.

JASON: Yeah. This is... oof. Yeah, it goes fast. But yeah. There's like a whole... whole chat going on the side here. I'm just checking to see if there are questions. I don't see questions. And chat, if you are able to -- if you have questions, definitely let us know. Are you able to comment out Line 14 and have it work? No. Because we have to have this base case of no argument. Because this one expects that there's an argument. So, we are -- to just explain this back and make sure I understand it, our function here needs to accept a value. A default value is A. And we need to make sure that that is within the constraints of the object key, which is our union of our available keys. And if we add another one down here, this will expand to include D, right? And then so, when we go with zero, zero arguments. We know that we're gonna default to A. So, we need to return that. Because that's what our function does. Right? So, our type becomes 1. So, in this default case here, we know that we're getting 1. And then for all these other ones, our key, what we're sending, needs to be one of these values. And then we are returning whatever the object contains for that key. And that allows us to then set our deal.

MATT: Exactly.

JASON: Okay. My brain hurts.

MATT: Let me show you just like -- yeah. This is tasty stuff. Like this is -- there's -- this is like solving one of the biggest pain points in TypeScript Generics, right? It's that instantiated subtype thing. When I Tweet out, what's your least-favorite error message to see? This is the one that people reply with. Trying to work around a horrible error message in TypeScript. And we have a repeatable way to do it now. Which is great. But yeah, I think this is a good place to end on. Because this is the really hard core stuff.

JASON: One more question here, why couldn't we just delete the base case and make the key optional? That's a good question. If we take this, and see if we can do this in 1 minute because we're out of time. So, get object key. And that would be TKey extends object key. And that's gonna take the key which is optional now, and that takes a TKey. And it's gonna return type of object, TKey. And we want the default to be A. Okay. The syntax.

MATT: Briefly...

JASON: Okay so, now it's sort of -- sort of happy but it gives us the exact same error.

MATT: This is where we started, basically.

JASON: So, it looks like we have to do this overloading because this inference too hard. Like there's probably a way to make this smart, but like not -- basically, this overload is what makes it all work, right?

MATT: Yep. To answer American250's question too. Another thing you could try and I have tried -- you can actually give -- whoa! No!

JASON: Oh, sorry, sorry, sorry.

MATT: Come on! Is you can actually give this like -- you can give the Generic here -- can you tell I was a voice coach, by the way? Drama. You can give this a default case, right? You can give Generics a default case. Which is really interesting. This feels like it should work. But it doesn't. Because it's still the same problem. You're still coming up against this could be A or B or D or C or D. It's kind of like you're trying to override this with this in TypeScript.

JASON: Hm. Yeah. Okay. So, this feels like one of those cases where like my instinct would be to refactor this instead of trying to -- instead of trying to type it. I would be like, okay. Let's just write this function to be simpler so that we don't have to do this.

MATT: Exactly.

JASON: And, you know, it sounds like we're out of time. I'm going to start signing us off. This is the sort of stuff -- are you covering the like -- sure, you can, but maybe you shouldn't part of TypeScript?

MATT: Yes, absolutely. TypeScript imposes API constraints on you. And mostly those are good constraints because they force you to do more functionally. They force you to do more in terms of designing your API so that inference flows through your app. But sometimes they're bad constraints. And so, there are exercises in my course where we look at something that is impossible, you know? And ways to work around it. But also, you should maybe be thinking about designing your API in a slightly different way to take advantage of TypeScript instead of fighting it.

JASON: Right. Right, right. Okay. Perfect. So, with that being said, I just dropped links to Matt's Twitter, to Total TypeScript which is if you want to be further than this, go sign up here. And to the repo that's full of the -- the challenges and solutions. So, go and run through those. This show, like every show, has been live captioned. We've had Amanda from White Coat Captioning, thank you very much. That is made possible through the support of our sponsors, Netlify, Nx, and New Relic, making this show more accessible to more people, which I appreciate very much. While checking out the site, make sure to go and check out the schedule. We are going to reschedule with Will, but I will be on Thursday. We will do something. I have a couple weeks off, a company All Hands and then vacation. And then back strong with a bunch of new stuff. Not all on here, add on Google Calendar, follow on YouTube, all those things so you get notified of new episodes when they're scheduled. And whenever they have gone live wherever you want to consume your media. Any further words before we're done?

MATT: Thank you. It's been a wonderful chat and wonderful audience. Good view numbers. Everybody getting excited about TypeScript. Love it.

JASON: Thank you for hanging out. We are going to find somebody to raid, chat. Stay tuned -- Ben is live right now. We're gonna go raid Ben D. Myers. Thanks all for hanging out. We'll see you next time!