TypeScript and Vue 3

Computed Properties & Methods

Ben Hong

Ben Hong

TypeScript and Vue 3

Check out a free preview of the full TypeScript and Vue 3 course

The "Computed Properties & Methods" Lesson is part of the full, TypeScript and Vue 3 course featured in this preview video. Here's what you'd learn in this lesson:

Ben demonstrates using computed properties to create a data cache that updates automatically based on other data. Students' questions regarding what information is provided in TypeScript errors and if types need to be added inside the filter function are also covered in this segment.


Transcript from the "Computed Properties & Methods" Lesson

>> And then let's go ahead and go on to some of the popular things that we use inside of Vue is we have computed properties. And so this is one of my favorite properties of Vue, because what you're ultimately doing is you're creating an ability to easily cache reactive data that updates automatically based on another piece of reactive data.

So this is particularly useful when it comes to like animations, and like data tracking and that kinda stuff because you can do some really incredible things and you don't have to worry about any of the caching foot guns that you might typically have to deal with. And so in this case, for example, we have this filtered restaurantList, right?

And once again, when people write a method or a computed property, they can define whatever they want, but it's useful to actually be explicit regarding what it's returning. So all we need to do here, if we want, is we can say we're expecting an array of restaurants. That's what we're expecting.

And, so that way if someone comes in, and so let's say they decide to like, so not this return statement, this return statement will always return an array of restaurants. So let's go ahead and botch this real quick, and return 123. You'll see here, hey, wait a second, this return, it's not right.

And so honestly, if you think about it, what we're doing here with TypeScript is kinda similar to what you would expect on a word processing, word processor, where if the dictionary catches a mistake, you kinda want it to let you know about it. You don't wanna wait till you've printed it and shipped it off to your professor for grading, be like, whoops, I have the typo there, right?

This is one of the things that I think TypeScript does really well. And as you can see, we're really just progressively sprinkling on what is ultimately documentation that is then converted into help tooltips to make our coding lives easier. So there you go. We have a list of restaurants from that list.

Now, okay, and what about this? numberOfRestaurants. Well, as you can see here, numberOfRestaurants has actually been, this is what in TypeScript they call type inference, which is basically it's inferring or assuming what the type will be based on how the code's written. So, in this case we're, using enough vanilla JavaScript here to basically for TypeScript to recognize that this is probably gonna be a number, and in this case it's totally right.

And so, you actually don't need to define it any more because TypeScript does try to do a lot of the heavy lifting whenever possible. But in case you do wanna be explicit, once again, let's just do that for practice sake. We can just say, okay, we do expect a number when that comes back.

But once again, some people do consider this code clutter, again, I leave that to you and your team to decide. But this is also just perfectly valid. It's already typed, so that in the event we try to do something funky like this, actually this would work, cuz I think it's gonna.

It'll just do some funky things because now if you're always doing on the inference part, you'll see that you can still mess it up. So when you have things that are a little bit more contingent on what the outcome is, I do actually prefer to be just a little bit more explicit.

And so if we look, though, this signature method is actually very similar to data because basically you have a function and you're basically after the colon what you're returning. So once again, just to show, we have our data here, what we're returning after the parameters, computed properties, same thing.

Okay, so now that we've seen that, very similar, we're gonna look at methods. And so this is where the functions that we're gonna use when inside of our Vue components. And so inside of here, let's start with what we already know, which is what we expect to be returned.

And so typically though, when we're using methods, particularly when it's things like click handlers and that kinda stuff, you're typically not actually returning anything. That's not really your goal. And in that case, you'll notice that when I hover over addRestaurant, it automatically declares a return type of void.

Basically, nothing is being returned. That's all that means. And so you don't need to be explicit about that unless, the only time I think this is really useful is if you wanna make sure that no one returns, if there's a strict reason why you don't want people to return things, you can certainly jot that down, but otherwise void is very much an optional thing.

However though, this is where once again we can see something that we often deal with when it comes to code, which is how many of us when we're working with JavaScript events, we have a payload that we pass? And it's like, well, what kinda payload do I expect?

[LAUGH] This is not very helpful. So you can always sit here and you can, like, I'm sure many of us have done this really, like, payload is going to be, we've done this before. [LAUGH] But we have TypeScript to help us out, again, we just needed to help it out a little bit.

And so how do we define types for our parameters? Well, it's actually just the colon and then the type that we expect. So if we do that for both of these, You'll see now that it actually started doing some type checking so that if we said payload.randomMessage, you'll see that it's like, hey, whoa, whoa, whoa, whoa, wait a second random message does not exist on this payload.

This structure does not exist. And so, again, another reason why just this little bit of TypeScript can make a huge difference in the long run, especially when we all know that whether it's yourself that's maintaining the code base, we often forget what we set out to intend. And whereas with this, even if you come back to this code a month later, it will yell at you.

You won't dive into a rabbit hole and then forget that at some point you set a type, you intended it to be the shape and then you decided to name it something else. You don't have to worry about that anymore. Otherwise, let's see. hideForm here. There's nothing we're doing here besides basically taking the showNowForm reactive and turning it false.

So there's nothing to type there. And then actually, this here is a typo. Let me just fix this real quick. There's nothing happening in here, okay. So that's basically the core functionality of what most people are using Options API for, right? You have your props, you have your data, you have your methods, and you have your computed.

So, now that I've kind of thrown that information out, do people have any questions about what I went through or should I dive in any deeper? Yeah, go for it.
>> I have a question about, so you talked about how the word processor is giving you these errors.

What kind of errors, these typo errors, cause a buildtime error or a runtime, if I didn't have the editor telling me what was wrong?
>> Yeah, so let's test that out. So just to reiterate, so the question here is around what the error provides in addition to just the red squiggly line.

So let's go ahead and again, let's do this randomMessage here and save this. And so you'll see now if I run npm run build, oops, I'm in the wrong folder. npm run build. Yes, okay. [LAUGH] Sometimes things don't work when you want them to, but it did this time.

You'll see that it actually stops the build. Now to be clear, for people new to TypeScript, it doesn't do runtime compilation if I'm not mistaken. So in other words, once you ship this, it's not gonna retain the types and then check everything to make sure everything's fine, this is really for while you're developing.

That might change in the future. That's my big caveat. Maybe browsers will install a way for it to be brought on and stuff. But as of this moment, it's really meant for during development and then when you build it, to help block these kinda things and then basically you're on your own after that.

[LAUGH] So this is where things like checking for your types is still important. So type guards, so you know sometimes in functions, you'll be like, if this is an array, do this, if this is a string, do this. You'll still be doing that with TypeScript, it won't protect you from having to write that code, but what it will do is protect you from common mistakes like this.

Where, like for example, restaurants, I called it name at one point, but at one point I called it title, too, when I was building this. And so I was like, wait. That's right. And so that's if we rely on our brains to remember things, sometimes we just get stumble a little bit.

And so it's a nice little reminder that hey, it doesn't exist, instead if I can just check real quick, that's right I named it name and set.
>> Do we need to add types to the argument inside the filter function?
>> The question here is regarding this parameter right here.

So, the short answer is, you don't have to do any of this. And I think it's something I do wanna underscore for a lot of this workshop is that it's really based on how your team works, right? Because one of the things I think made TypeScript difficult to adapt, especially early on when people are telling everyone to go all in is that people felt like they had to type everything.

And then all of a sudden things were colliding or didn't, people's knowledge didn't quite match up to what they wanted to do. So then people were slapping Any on everything. And so if you don't know, Any is basically like a cheat code for TypeScript to shut up. That's basically what it means.

It's just like, stop yelling at me, just ignore it. And at that point, it's basically useless. And so that's why to me, for this kind of thing, if I'm looking at this computer property, honestly I care most about what's being returned. In the event that I do think the filter's gonna have problems and maybe someone might not understand the code.

That might be something where I can come here and just say, okay, just for documentation sake, we're gonna make sure people know that the parameter should be of type restaurant. But because filter is a built in array method, this is nothing I customized, for example. This is straight up ES6 syntax.

We do know that it basically will iterate through whatever restaurantList is. Aand so it's basically to choose your own adventure kinda bit. But in this particular case, I might omit it in this case because I think the key thing is what you're working with after everything's been returned.

But again, no right or wrong answer [INAUDIBLE].
>> But you could. That's a cool part of it is you could-
>> Yeah, exactly, right?
>> Yeah.
>> And that's kind of what I wanna keep re-emphasizing with this, is that if you're like, I feel a bit more comfortable.

In fact, we'll just leave it in here. There you go. You've annotated it, people know what to expect. That's all there is to it. And then just to reinforce this, you'll see that the restaurant without any type definition does inherit, TypeScript does some of that work for you.

It's not like you're just like, yeah, I got some array thing. It does know that restauranList contains this kind of shape. So it does basically assume that for every item I'm iterating through, it's probably inheriting the shape. And guaranteed there may be reasons why this may change which is why as mentioned, if we want to, we can always augment it as needed

>> So how did it know that restaurant was a type restaurant without-
>> Yeah, so the reason is because, remember we did that define component to tell TypeSscript how to find things. If we scroll back up to the data, this is where the DataShape told it that when you do this dot something, restaurantList is of type restaurant.

And so this is kind of some of the dance that has to happen with TypeScript and Options API because of this keyword. Cuz if you hover over this, it's basically useless. But actually, it's funny though, you can see here that the CreateComponentPublicInstance does have this filteredRestaurantList with a return on here.

And then can I actually navigate anymore? But anyhow, so that's how it's knowing through all that jumping.

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