React and TypeScript, v2

TypeScript Utilities Methods

Steve Kinney

Steve Kinney

React and TypeScript, v2

Check out a free preview of the full React and TypeScript, v2 course

The "TypeScript Utilities Methods" Lesson is part of the full, React and TypeScript, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve introduces a few utility methods to facilitate common type transformations. The Partial utility method creates types from a list of keys from an object. This is useful when updates to an object should match the object's keys, but not all properties are required.


Transcript from the "TypeScript Utilities Methods" Lesson

>> Now, there are some things that we can theoretically do to make this a little bit better, but they're all kinda nice to have, this kinda gets to the main point. But we're gonna do something first, which is, did anyone see the bad thing that I did that I hid in there for you to find?

It's the same bad thing I keep hiding everywhere. Hey, let's look at the context. Yeah, right, I think maybe I'll stop the editor, right? No, there it is. What? Any.
>> Any, right, which means this can be any, which means update. Who knows the ways this can mess me up?

But this creates a somewhat interesting problem. So the way that update works is it takes an object that has the keys available in an object, and then it just kinda replaces the current ones, right? If I turn this into Item, well, that's gonna be problematic, because theoretically, I also have to change it here.

Yo, I fixed it in my actual implementation, but you know why not blowing up? Cuz they spread. Look, now is angry at me, one any. All it takes is one any, you saw it with my action earlier. And the way this works is we're only replacing one property, right?

Over here, we're just replacing the name, we're just replacing path, right? And so I want the situation where any keys you give me better be on item, but I don't need all of them, right? I don't wanna replace the ID of an item, kind of person would do that.

I just wanna say, optionally, I wanna be replaced anything on an item, right? And this is where utility types, which is just pure TypeScript come in helpful, but in a very specific React use case. So what would this look like? So let's go back into our context. And you might say that, hey, Steve, if you had magically derived this, or if using useDispatch, you wouldn't have to do this in two places.

Yeah, you're great? But this is the point we see with use state and some of the trade offs. So one of the things I could do is a Partial. What partial does, Partial is a utility method, right? You can see it by hovering over it, and if that stresses you out, that's okay, it stresses me out.

But basically, it takes all the keys in the object, it makes them all optional. It's basically taking everything and dynamically putting a question mark in front of all of them. It's built into TypeScript, I don't have to do anything, I don't have to write it, it's been there for a while.

Each new version, not each new version, new versions of TypeScript very frequently have more and more of these. There's a one that I really liked that came out. It's either coming out in 49, or came out in 48. I think it's coming out in 49, which is awaited.

Which is if you use a weight, it's like this is either the promise that we're awaiting or is the value. And it just does all of that for you. Cuz previously, I think even when we did a previous version, of course, figuring out whether or not something was a promise, you had to check for then method and stuff like that.

It was not easy, and there's been a lot of abstractions that make that a lot better. I have a custom one in my code base that I hate, and I'm waiting until we upgrade to 49, yeah, that's what it is, before I can use it. So this makes them all optional.

But what if you wanted to say, all of them optional but I better not see an ID in there, right? This is where more utility types come in handy. So we could say Omit. And if I just put it around Item, it would just take it out Item.

But this is omitting the partial one, right? So I can say Omit, and I can say id. And if I grab this real quick, we can see kind of break it out so we can just hover over and see. So we'll say, PartialItem, We'll just grab that first part.

And it will say type Partial, Omit. This is great way, is like not re-type stuff all over the place, PartialItem, and then but don't include the id. So if you look at PartialItem, these can all be either a string or undefined versus the regular item, that was not the case for, they all had to be there.

And WithoutId, it says, but not the id, right? There's a bunch of these. It is not the best use of our time in a workshop on how React and TypeScript play together. They have it written up, you can go take a look at it on the documentation I put for this workshop.

Absolutely, do I remember all of them all the time? No, is it important? Or if you're doing something squarely or copy base, it'd be like I should see what the latest set cuz they do update a lot, right? There are new ones in many of the point releases, not just 3.0, 4.0, 5.0, but like in each new release, some new ones come out that solve a lot of common problems.

So in a lot of these cases, if you need to do something special like that, you can reach for some of these to kind of create new types on your behalf. So what I'm gonna say is cool, any of the properties that are on an item but not ID, I should be able to use this now in both places.

Yep, cuz it's not getting the right thing, so I just gotta swap it in here. And my code compiles, and now it's a lot safer, I don't have that any infecting everything. But I also didn't have to go and statically make another type again, cuz you can imagine that's well and good in a stupid little example app, totally.

All of a sudden, one thing changes, and you've hard coded all these different sets of values everywhere. It's not great, right? So letting the type system, and you'll notice that React has done a bunch of this for us. It's how props with children works, right? It was like, cool, take whatever it had and jam on children.

That is React.ReactNode, right? We used these already in prior examples, we just didn't really talk about them, right? And having some of those variables being able to pass in, right, it's kinda what set state was doing. It's like, hey, OU state, right? It tried to derive the value, if not, we could pass one in.

That's very much what we're doing with our Partial, right? We're making a new type based on some other information.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now