Vue 3 Fundamentals

Props Exercise and Q&A

Ben Hong

Ben Hong

Vue 3 Fundamentals

Check out a free preview of the full Vue 3 Fundamentals course

The "Props Exercise and Q&A" Lesson is part of the full, Vue 3 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Be instructs students to practice implementing props for their Vue application. Student questions regarding how to approach user details when creating a user card component, if computed properties could be used to pass data, if properties are passed by reference, and will the component rerender if the data changes outside of it are also covered in this segment.


Transcript from the "Props Exercise and Q&A" Lesson

>> So I wanna give people, first, a chance to practice the props approach, and then I'll reset the context in terms of the lead-in into the next technique that I think is really important when it comes to the model of web development and how we look at things.

We did get a great question here in the chat. And so, is this around the idea of when in a lot of real world apps, a lot of times you're getting large sets of data from your API, right? And so in the case of the question is, user details.

And so if you're creating a component like user card, how might you approach this? So, again, just for the sake of not just me talking, lets at least scaffold this out a little bit, just so there's something visual for us to have. [SOUND] Let's go to the playground.

And then we'll go into our app. Okay, there we go. And so what I'm gonna do here, I'm gonna create a file called user-card.vue. And then let me just do this real quick to set up the scaffold, let's keep it easy user. All right, so we have a user card component.

And then I'll explain what is the question here. UserCard from components.user-card.vue, UserCard, okay. And then here we have a UserCard like that. So let me run, wait, wrong thing to run dev in, okay. All right, cool, this is too small. So we're gonna bump that, bump that, bump that, close that.

Okay, so the question here is around this concept of what happens when you get a large data object? So inside of here, for instance, let's just define it here real quick is that, let's say we have a userData object that we end up fetching from the API that has something like name, Ben, preferredFramework, vue, for example, favoriteFood, sushi.

And then, let's just keep this, okay, so let's say there's this level of object, or actually let's go ahead and, what's one more thing? Let's just say, I don't know, favoriteNumbers. And this can be an array, and that can be 8, what? 10, these are not actually my favorite numbers, but for the sake of the exercise.

Okay, we have this complex thing. And so the question here is, if the UserCard, for example, let's say on the user card we only wanna display a couple of things. We wanna display the name, we want to display the, what else have we got? [SOUND] We got the Name, and let's just say Favorite Food.

Let's actually just say two things. And so we refresh this, very good. Okay, the question here is around data architecture, and how do we actually manage this? Because there's one way we can do this, right? Let's talk about the first approach. Probably the most straightforward approach is to just say that, hey, inside of this component I'm gonna take this prop called user.

And it's gonna be a type of object, and I'm going to require it, okay. And then here is where I'll say, and user.favoriteFood, cuz that corresponds with this data that we're gonna go ahead and pass here directly, user="userData", okay? So if we take a look at how that looks here, you'll see, did I not save?

There we go. You see, user Ben appears and sushi appears. Okay, so it's working. But the question here is, as you'll notice, is that we have passed in more data than we actually need. And so I think the question is kinda like, what's the right way? And like a lot of programming things, there is no singular right way.

A lot of times what it ends up boiling down to when it comes to managing this stuff is the complexity around maintenance of the components, that's what I would basically say. There's certainly sometimes concerns that, the data you're passing in is so massive. They're like, it doesn't make sense to pass it as a single component.

But then I would argue at that point, the bottleneck is not the component architecture, but maybe how data is being fetched and being passed on at the higher level, right? This is why I think stuff like GraphQL has gotten really popular. Because if the servers are just returning giant blobs of data, that's expensive for the user, right?

There's no amount of smart things you can do as far as, if you're just getting more data than you need from your server, that's a problem that has to be dealt at that end, and not necessarily at this level. And so in this case, however though, let's say this was a lot bigger.

Let's just say this was a lot bigger, right? And you're like, I really don't wanna pass that. There honestly is nothing wrong just being like, well, they will have a name, it'll be String. And this time we'll just say it's a default of John Doe. And then we'll also have a food prop that is a type String, and we'll default it to Cheeseburgers, right?

And so what's cool about this now with the default, cuz this is, I think, the first time I'm demoing this. Is that if in the event we don't include anything on the app side, you'll see. What did I break?
>> You used user in your app.
>> I did, you're totally right, good catch.

It's no longer an object, it's just individual properties. There we go. User, favorite food, yes, and this is just food. Okay, you can see we have John Doe and cheeseburgers. And then, as a result, what you get is now, okay, let's just say, Ben's favorite food is cheeseburger.

Well, then in that case, can be the only thing that we pass. And you'll notice that Ben state, Ben is good, default prop stays cheeseburger. And then here you can also then say, you know what? Then also for favorite, so, food can be userData.favoriteFood, and then it still works.

And so, again, it's one of those things, I think, with experience you'll come to figure out, one, when is it too many props? Cuz I will say, that is actually a legitimate problem. If you have the point where you're breaking down your object, then you have ten lines of props, no one's gonna wanna read that, no one wants to deal with that.

But, again, fill it out with your team. Figure out, what is your limit? For me once I start getting passed three to five props, I start wondering if I can maybe manipulate the data just pass a concise object that can then be spread out inside of the component.

But, again, it's one of those things where you'll have a style as far as how you approach that, yeah?
>> Would that be where you might use a computed property to pass as a prop?
>> I love it, okay. So the question here is that then with this same concept, right?

Could we then use a computed property to pass it down, instead? And I think that's a great example. So once again, let's take this example. If we wanted to say, only pass down the food and the name, we could say, call it refinedUserData. And this refinedUserData can basically just be, returns an object where we do a [SOUND], what is that?

Name and then just And then food, this.userData.favoriteFood. And that way you actually get to massage the data a little bit, anyways. And then we can revert back to this user now, which can just be passed. And it will be passed refinedUserData. And so it means we'll update this now to be user, type: Object, required: true.

And this time, we can then say, actually I could have just done that like that. There we go. What did I break? Cannot read properties defined name, computed return name. Okay, it did work, I just didn't save after view. Okay, so there you go. That's an example of passing down just the data you need into your components so that it doesn't have to deal with the cruft of all the other data properties.

And so once again, it'll be a stylistic part as far as like filling out what makes the most sense, in terms of, is that level of complexity even needed? Because if it's just one or two extra properties, I'd say, most of the time, it's not worth creating an entirely separate property just to refine the data a little bit.

Granted, if you have a massive card, right? That has a ton of stuff in it, then that's the point where, once again, whether using things like serverless functions, for example, those are great ways to massage the data so that when they come back from the back-end, it's smaller in the way that you want.

That's one approach to that, as well. Because, for example here, one of the APIs we have to play with later in the workshop is, if you take a look at something like this, right? This is actually a great example of a really complicated, let me see, copy paste.

This is the entire thing for the Pokemon Ditto, and there's a lot of stuff in here that you probably don't need. You probably need one image. You need, maybe the number it is, and maybe need to render. But this is an example of a lot of raw data that you don't necessarily need.

And so, once again, there are different approaches to handle this, but I hope that answers that question. So thank you for asking that. Cool, all right, yes?
>> When you do pass properties, is it sort of passing by a reference, or is it passing a copy of the object?

Just cuz we're talking about performance and memory.
>> [LAUGH] Okay, so the question here is that when you pass in this refined user data, is it passing in a copy of it or is it passing a reference to that data? And the answer is that it's passing a reference to that data.

And so when it comes to props that actually does bring up the concept of mutating props, generally speaking, not a good practice. So, what you don't wanna do is come in here, and then be like, yes, I'm gonna create a method that's changeName. And it'd be, = 'Charlie'.

You don't wanna do this.
>> But you could.
>> But you could, but as you can see though, unexpected mutation of user prop, it's yelling at you. Because, once again, when you start muddling up the chain of command as far as how data flows, it starts to get really tricky to figure out what's happening now, right?

Now, again, this leads into the question that we had earlier regarding, well, if that's the case, are you saying that my child component can't change the data it's happening? No, that's not the case, at all. But before we move on to that topic, does anyone have any other questions about the exercise they've worked with in terms of props, that kinda stuff?

>> If the data changes outside the components, since it's passed by reference, will it rerender the component then?
>> Yeah, it'll know basically what parts of the to update and all the dependencies. So that's one of the advantages is that, basically, all the reactivity Vue tracks and takes care of.

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