Hasty Treat - TypeScript Utility Types

Welcome to syntax.

In this Monday, hasty treat. We're gonna be talking about s. T u t, tut tut, TypeScript utility types. I don't think anybody says t u t, but we're gonna be talking about TypeScript Utility types, what they are, why you might use them, why they exist, all of those things and more. If you are a TypeScript fan or TypeScript curious, This is the one for you. My name is Scott Talinski. I'm a developer from Denver, Colorado, and with me as always is the West Boss.

Hey, everybody. Excited to Talk about utility types.

Yes. So before we get into it, let's, introduce a couple of our sponsors today. We have Linode, which cloud hosting, and LogRocket. Wes, do you wanna talk about Linode, and I'll talk about LogRocket?

I do.

Linode, there's cloud hosting developers trust. They have award winning support 247, 365.

On Christmas morning, I'm gonna call them about it it would be very unfortunate to have to call them on Christmas morning, but They have somebody on just in case that type of thing happens.

It's got ease of use and setup. It's clear why developers have been Seeing, you know, Linode for projects big and small since 2003.

They're probably most well known for their Linux servers that you can just Quickly spin off a little box. You can SSH into it and start running your node apps or whatever it is, but they also have, block storage, Object storage, you can host your your images on there. They have node balancers. They have bare metal, Kubernetes, GPU, high memory, You name it. And listen to this. Linode is gonna give you a $100 in free credit when you sign up atlinode.comforward/syntax.

So you got that node app you wanna host? Throw it on Linode.

They're pretty sweet. Check it out. Thank you, Linode, for sponsoring.

Sick. This episode is also sponsored by Log Rocket, f.

Logrocketlogrocket.comforward/syntax is the perfect place to Log your errors and exceptions and see them happen in a scrubbable video replay.

So many other Tools like this type were built for, you know, the back end developer who's used to reading giant code stacks. But, you know, us Front end people will and the web people, we're used to working visually. Right? When we write our code, we got our browser open. We're refreshed, and we're seeing that browser. We're always in that browser.

And LogRocket works with that browser in a visual way, giving you a scrubbable video replay of your site as the error is happening. And with that, you get the console, you get the network tab, you get all sorts of things from your dev tools, even your Redux store if you are using Redux.

So it is so very cool. There's an on premise or a hosted version. You can check it all out. You can get 14 days for free by signing up at logrocket.comforward/ syntax.

Thank you so much for LogRocket for sponsoring.

Alright.

TypeScript utility types.

Wes, You wanna give a high level overview of this stuff?

Yeah. Yeah. So when I think about TypeScript devs, I like to think of it as, like, 3 different levels of being a TypeScript dev, and these are not necessarily you have to ascend to the 3rd level. It's just that there's different types of of devs that are use TypeScript in different ways. So at the very basic not very basic, but, the first level, which I would assume is most of us most of us regular developers is just use TypeScript to type all of your code. You create your interfaces and your types and, your return types, and you pass in your your variables, and you just type all of your code. And then at a second level, you can get a little bit more dynamic Using the utility types in JavaScript, meaning that you can write functions. You can make things a little bit more dynamic. If you have some libraries that you need to type, The utility types can become handy in there, so you're not repeating yourself over and over again as well as things are not as rigid, as they would be, they can they can we'll talk about some examples coming up. And then 3rd is you can create your own utility types, which I was Kind of amazed when I saw this. So TypeScript is a language in itself.

And that's not to say TypeScript is JavaScript with types added on top of it is TypeScript is literally a language that you can create your own utility function Using things like the infer, key of, extends, turner turn ternaries.

We still can't say that word.

It's really weird because if you wanna create custom utility types in TypeScript, you can't just use JavaScript. I kinda wish that was the case. You have to use the very rudimentary bits of TypeScript to make your own. And if you ever go to this GitHub repo called type challenges and look at the answers of some of these, especially if you go to the hard or extreme ones and look at some of the answers.

It's just like I look at it, and my eyes gloss over and go, I have no clue what this type of of thing is doing. It's very, very terse and whatnot, and that's not the stuff that most developers are going to be writing.

That's the type of stuff that Library authors are gonna be writing so that Scott and I can use the generated values in our code, And it all just works really, really nicely.

This repo is really cool. I have never seen this, and I love stuff like this, These little challenges because you can just start at the hello world and and warm up or whatever and and work your way up. And this feels like this feels like Fun. It feels like a little game. I'm gonna try some of these out because this looks neat.

Yeah. It's fun until you get into some of the Hardin.

The medium ones are are kinda nice. Like, they ask you, make a kebab case utility function, make a A permutation function. Make a capitalized function, although we have that.

Make an any of function. Those ones are are kinda neat.

The code behind it. I always wonder that. Like, why didn't they just use JavaScript Mhmm. For these types of things? But they it is like, look at some of the answers. It's much, much more terse, And that's the type of language that the people that are writing TypeScript are doing it in. Cool.

But we're not talking about that today. We're talking about the second one, which is utility types. TypeScript has a bunch of utility types built in that are very handy when you are writing your code. So you're either not repeating yourself over and over again Or you are not making your functions as rigid as they could possibly be, and then you change one thing, and you have to go update that in 6 or 7 different places.

So let's go through some of the more popular ones that are out there, and you can take a look at all of the utility types that are built into TypeScript in the docs. We'll link that up as well. 1st one we have here is just partial.

So if you want to make a type of Part of another type, you can use partial angle brackets and pass the type. Where this is most most handy, and I use this a lot, is If you have a type of, let's say, a food, and that food has a name and expiration date and, a list of toppings and an ID, and you wanna update part of that food. You generally have a function that's called update food, And then that will take in, generally, not the entire thing. It will just take in part of that type. So you can say this function will take in a partial of food, and then any of the past values have to still be part of food, But it doesn't have to be all of them.

Next is read only. Now this one's pretty neat because, you know, in JavaScript, we don't often think about things like this as much, and we're starting to where we have properties that are, you know, not able to be changed. We have const, which is not really truly read only, but there is a read only utility type where, let's say, you define your interface And you were to wrap this in a read only. And then if you were to modify one of the properties in that object or in that in that interface, you were trying to modify one of those objects, It would TypeScript would get angry and said, hey. You cannot change this property because it is read only.

Next one we have here is Required.

This is a neat one where you can make the entire every property on a type required, and you can use this In addition to some of the other types, if you wanna make them all required and then take 2 of them off, that's really handy is if you have a type, But none of the values are required. But then you are maybe you're sending that data to a database, and you wanna make sure that When the person sending that over to a database, they give you every single field that you want. So simply just required will take every field of a type and make it required.

There's also one called record for, like, constructing, like, a key value pair where you could have let's say, you have an interface to define an object, And then you have a type where you have very distinct property names. So you have a property name that is You wanna you wanna keep track of very distinct properties in an object. You could then use the record to say, record, Give me all of the following property titles, comma, all of the following property values, and then that is going to say that, okay. I cannot define something that is not within one of these given keys that is available here in the initial type. Yeah. I have an example here in the notes. If you've got A podcast. Maybe the podcast has a name of the podcast, a URL,

show count, and authors.

And you want that info, but only for syntax and Shoptalk.

You can use a a record as, like, an object, but it's much more Restrictive, meaning that you can only provide information for the following 2 podcasts or the following 3 cats. So it's kind of a nice way to just lock down an object to only the the following of data.

We also have Omit.

I find this one handy where if you do have a type let's say you have a item type Or a pro let's let's use product. You have a product, and that product has a a name, a description, a price, some tags, and an ID.

Sometimes you want that same type but without the ID field. So if I wanted to have a create product function, I want all of the inputs for create product except the ID field because the ID is generated by my database. So if that's the case, I'll create a new type. Usually, I'll call it, like, a create product input, and then it's simply just the product, but omit the ID field from that, and then give me everything else. Next 1 is going to be if you wanted to

Create essentially a new type by picking out properties from an other interface. You could use pick. And then, actually, this one's funny because this one n. Is used throughout. We use GraphQL code generator to create much of our complex types. And what's neat about that is that I get a lot of things like pick used pretty heavily in my types Without me having to write it. So I can see it in action and how it's working and understand it a little bit more than if I were to just read the docs or try to figure it out. But what Basically does is, let's say, you had 1 interface, and, this is an example straight out of their docs. They have an interface to do, and that has a title description completed as properties. Then they wanna create a to do preview that's based off of the to do.

So you would use type to do preview is equal to pick, And then you pass in the to do, the initial interface, and then using string values, you just say which properties you want. So Title completed, whatever, and then that gives you the preview, which is a subset of the initial interface.

Another one is return Type, our return type utility type.

Return type utility type will return to you the type That is returned from a function. So if you have a function that is being passed in or you just have a function in general and you want to generate the type That is being returned from that function, not the type of the function, not the type of the arguments, but the actual value that's being returned, You can get that on the fly with the return type, utility type.

Man, look, some some of them feel very abstract when you're thinking about it. Like, I'm sure there's, like, perfect situations where you're gonna hit one of these at one point and be like,

Return types. That's exactly what I need. That's the thing about them is that, you might not ever need them, but when you do, they are there.

Totally. Now, there's some ones also around Just a string manipulation where you can change the the type case. So if you have a type case that's an upper case, lower case, capitalized, uncapitalized, You can wrap it in uppercase, lowercase, capitalize, uncapitalize to manipulate that value. That that's just good for being dry. I know we use The various case types throughout our entire code base for different things that are all generated and stuff. This would be really nice to be able to Just modify these on the fly using any of these things and not having to rewrite it essentially as a lowercase type or inferred from another one or something. I just have another, quick example for this return type. I, I was just going into my my TypeScript course that I'm working on, and I, like, was looking for some of the examples that I have. And I have a function

that called make pizza, and that just returns an object with a name of pepperoni and toppings of pepperoni and cheese, so it's an array of strings.

In that case, that function doesn't have a type. It's simply just returning data. So the type is actually inferred from the data that's being returned.

And then what I can do from there is I can say return type, Make pizza, and what that will do is it will infer the return value of that function and then generate a new type from that. So Sometimes you want to generate your types either from existing data or from what a function is returning Instead of having to type them beforehand, and that's a good use case for that. Yeah.

There's a bunch more little types around this and and whatnot. But, honestly, those are not ones that I've run into using that often. The ones that we have rattled off here are just Ones that I've I've run into, and even then, you probably won't use this every single day. But when you run into situations in TypeScript where you say, okay. I need to

make this type dynamic. I need to generate a type based on this existing data or this existing type. That's where you need to reach for TypeScript utility functions, and they can come in really handy. I honestly think they're a little bit tricky to understand, But once you've written 1 or 2, you can kinda understand what's going on there. I think they're definitely tricky to understand. And if everything we said Kinda goes over your head and you're thinking, I just don't get where I'm gonna use this, then you probably don't necessarily have a use case for it right now, and that probably isn't a bad thing. Yeah. So like what I said at the jump, you know, there are there are levels to this where, you know, most people might not need to dive into all of this stuff all of the time. But it is good to know that it's out there when it's there, especially when you're getting into some complex type stuff. And when you get into complex type stuff, that's when these, utility types really shine.

Alright. That's all for today. Thank you so much for tuning in. We will catch you on Wednesday. Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget to subscribe in your CAS player, or drop a review if you like this show.