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

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

Ben walks through passing data to components by declaring props. A student's question regarding passing functions as props is also covered in this segment.


Transcript from the "Props" Lesson

>> The question is, how do we pass data down to our components? And so this is where we talk about the idea, and it's called props, which is shorthand for properties. And the reason why I like the concept of props a lot is because if you think about it, they're really just data attributes on your HTML element.

But it sounds really fancy when you say props, but really it's just, you're passing an attribute a value, and then that component can access the attribute. That's really what it is. So I think of props as custom attributes. Well, what do we need? We need the character list.

So for now, I'm gonna add a prop called characters, and this is gonna be passing down our characterList. So then I can go ahead and bind it to character lists like this, and then, does anyone know what I'm missing here?
>> Colon.
>> Colon, yep, cuz I need to v-bind this to make it dynamic.

So I'm gonna just do the shorthand for colon. But that's not good enough though, because after all, what we just did was we just passed it in data. But one of the things I really like about Vue, it's not Vue-specific, but I did like this when I started learning about it, is that it's really all about trying to document your components and making it easier for people to use.

So inside of your options, you have the ability to define what props you're going to get, right? So actually, before I do the object one, the simplest way to define your props is through an array of strings. So I could just be like characters, like that, and then you can see here, let me save that, okay?

What this means now is that if I do this.characters, Vue will know this character's reference refers to this prop up here. And so if I save this now and refresh, you'll notice our statistics suddenly works again. Now, the thing is though, I only show you this because in case you see this in the wild, this is code smell, because again, characters as a string doesn't tell you very much about what you expect as a prop.

If you're interested in enterprise level, patterns, and that kinda stuff, be sure to check out the production grade view that I've recorded before. And so that covers a lot of the different patterns that you'll see in enterprise apps, and so this is kind of a snippet of something that I mentioned.

Okay, so when it comes to props, I recommend defining it via object, why? Because what we can do is four characters, we can do things like define what kind of type that we're expecting. And again, this is not type in TypeScript perspective, this is more of a runtime check, like Vue helps you out.

When you pass something funny down, it'll just kinda highlight, hey, you told me you wanted this? Why is it something different? So in this case, I know this is gonna be an array. More importantly, I can say this is a required property. Or I could say, I could also define a default property on it as well.

But for this particular case, all we need to worry about is the fact that it's a required property. And that's important because what you're doing here is basically self-documenting the component so that people in the future can actually use it correctly. And so when I save this here, you see that we're refreshed.

This is good. But then when we go back to App.vue, let's say I accidentally tried to use Bender Statistics without passing the component. Let's see, will it yell at me? [SOUND] So this time, it doesn't yell at me. But there are times where I think, I actually I need to do this real quick, if I do characters="123", save.

Looks like it's not doing any checks for me at the moment. It's been kinda finicky. But anyhow, at the bare minimum, when you're doing this, you can actually see, it's easy to read, easy to understand, and then more importantly, makes your app easier to maintain. So once again, we are characterList like this, oops.

Okay, and so props really is basically the glue to which we can connect our parent components into our child components. There's a question there?
>> Functions as props.
>> [LAUGH] Okay, so this is a hotly debated one. Okay, so the question here is around the concept of functions as props.

And so in other words, to set up the example here, let me go into the sandbox one instead just to show. [SOUND] Okay, so let's say in base counter, we had a props, and this is actually something that I think it's more common in React code bases. So in App.vue, we saw that we actually scoped the increment counter directly to the component, right?

Well, theoretically, what you could do with this concept is that you would have your methods at your parent component. So it'd be at this level, right? And you'd have this increment function, and then what you pass down to the component is the actual increment function. So it would look something like this, right?

And then in terms of how this would be, how it would look from a component perspective, you would have this increment prop, and it's like type function, right? And then just be like whoops, required: true. [COUGH] There is an example of a props. Personally, I am not a fan of passing functions down as props.

The reason for this is because I know that, especially when we are programming, we get caught up in trying to do factory functions, right? And with the factory components, where it becomes very easy to genericize everything. And so that's why I think one of the reasons it even got popular to pass functions is, because you're basically saying as a parent, I'm gonna tell the child what to run.

But what I found with that a lot of times is that now you're starting to kinda conflate, I feel like the parents start to do too much work in terms of. if the scope of the child is meant to increment, I found very few times where it didn't make sense for the child to own that from the beginning, as far as functionality wise.

>> Sir, in this example, [COUGH] I tend to think about this in the Add New Airbender form.
>> Yep.
>> The parent app owns the list of airbenders, and the form has what is a new airbender app, and how do I modify it? But the one I wanna actually add that to that list, I could modify the list in the child, but that feels dirtier than having the parent own that function that actually adds it to the list.

>> I love this question. So that is actually a good lead in after the exercise. I'll call it what I consider the more standard pattern of dealing with that. And so to recap, in case anyone couldn't hear, is that, let's go back to the example brought up ,what's inside of my Avatar Airbender component?.

Earlier you might have heard me say, for example, that the component hit a limit, and there's a reason for that. But for the favorite characterList, as was mentioned, if we were to break our favorite character right here, into its own component, it's tricky because at this point, favorite list is also dependent on, there's the data exists in the parent.

And so you don't actually wanna pass the data into the child for the child to modify. But at the same time then, it sounds like it would be better to then pass a function to the child to tell it what to do, right? But I'll leave that a little bit on the cliffhanger, but just know that there's a better way than passing functions down as props when it comes to that scenario.

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