Components are meant to be reusable, and even though we used multiple component instances for the counter button, it's quite hard to understand the benefits of reusability without seeing a more realistic example. So that's what we'll do in this lesson. view that renders the page for a coffee subscription service. You can get this markup inside of the description section below.
There I've left a link to both the markup as well as the styles that you'll need to make this work. css, and paste all the styles that are linked in the description here. Make sure you don't add these to the existing styles but instead replace those existing styles completely. Notice in the markup here that each of the different plans on our page is created by several different pieces of HTML.
We have a div with the class of plan, a div with the class of description, and a span with the class of title. And each of these pieces of markup is repeated for each of the different plans. If we had a component here, we could do something like this. Doesn't that look a whole lot nicer?
than all of this duplicated markup. It's a lot easier to follow. It's a lot easier to read. Oh, and just so you know, having single-worded component names like this is actually considered bad practice.
Why? Because they might collide with existing or future HTML elements. Therefore, it's a good idea to make this two words. Over on the right-hand side, you can see that this does not look right.
but that's because we haven't actually created the component yet. Let's do that now. View. We'll add a template in here, and then I want to copy the markup that a plan consists of, and we'll paste it inside of the template here.
Of course, this means we'll also need to import CoffeePlan now instead of the button. Beautiful. Now over on the right-hand side, It looks like the name of it has changed out, but it still doesn't look quite right. I think that's because coffee plan here should actually be inside of this div with the plans class.
So that's great. So now this looks perfect, but we don't have the hacker, that name of the coffee plan displaying to the page. That's because we have the addict hard coded in here as the name of the coffee plan. So how do we make the name dynamic?
Well, to use this specific syntax, we'd have to use slots, which we'll get into a little bit later. But right now we're going to talk about props. They look like HTML attributes. That is, they have a key and a value.
Now we need to update our coffee plan component in order to actually accept this prop. We can do that inside of script setup with the define props macro. Notice that I didn't have to import define props. from view.
That's because this is a compiler level macro that only exists in the pretty code that I have here in my IDE. It never actually runs in the browser. It compiles down to something else. But the important thing to know is that you don't have to import it.
You just use it. Okay, so define props allows me to define any prop. The one I want to define is called name. So notice here I could define multiple props if I wanted to.
This is an array. and I can just add as many different props as I'd like. We'll just stick to one for now, and then down inside of my template section here, I can print out the prop with the mustache syntax. Over on the right-hand side, the hacker does display now on the page.
Notice in our code that we were able to name our prop here and then use that prop directly inside of the template. If we wanted access to the prop though inside of a script setup, we would have to first set a variable called props, and then you could access each individual prop on that object. name, and then that would be the single, the curious, the attic, and the hacker respectively for each component on the page. We don't need that though, so I'll just remove it.
With the component now complete, we can use it to power the rest of the plans in our app. So I'll copy this, make one for the addict, do the same for the curious, and then finally the single. That means we can get rid of all of this markup above. And that looks a ton cleaner, but we get the exact same output on the page.
What was close to 20 lines before is now just four. Another thing we could do here, is create an array of our different plan names and loop over them displaying a coffee plan component for each of them. To do that, I'll import ref from view, and then we'll create the reactive ref, call it plans, and pass it an array of each of the different coffee plan names. Down inside the template then, I can use v4 and loop over plan and plans, give it a proper key, And then we can get rid of all the other coffee plans here.
Awesome. So notice now we have the single four different times. I need to make the prop dynamic. This is done just like any normal HTML attribute by using the bind or the shorthand colon.
Now I want to pass it the plan instead of a hard coded string. And this gets us exactly what we had before. How smooth is that? Before we move to the next topic, let me show you one more thing.
Props are something that you'll use very often, and so it's great to know some best practices directly from the beginning. Let's take a look at a few alternative ways to define our props. So it could be an array as we have here, but this method doesn't give us a whole lot of control. Another way to define our props is as an object.
And then we use the object keys in order to name the props. So for us, that is a name prop. And then for the value, we can say what kind of data we expect, like an array, a string, a boolean, or a number. If we had another prop here called price, it could be a number while name is a string.
This documents your component and will throw a warning in the browser console if you try to pass a wrong value. view and try putting a boolean here instead of a string for the coffee plan name. It shows true here, but in our browser console, we'll see these multiple warnings. Okay, we have an invalid prop type check filled for prop name, expected string, but got a boolean.
That's pretty cool. And we can even take this a step further by providing a type here. This is going to be string. but then we can do other things like give it a default value.
So maybe the default value for a coffee plan is default plan, or we could make a property required. So here we could say type number, we could say required true. Now when we take a look in the browser dev tools, you can see not only the invalid prop for the name, but now we also have this warning here, missing required prop. price.
Awesome. This is just a sampling of some of the options that you can use to configure your props. If you'd like more documentation on what all is available, I've left a link to the official VGS docs in the description below. Finally, let's review what we've done so far in this lesson.
First, we created a coffee plan component in order to consolidate some of the markup that it takes to create a coffee plan to a single place. view without having to repeat the markup for each one. We also defined a name prop to make the component flexible and display something different depending on the value passed for the name. So while we're at it, let's go ahead and change back name to the proper plan name and I will remove the unused price prop.
js and define props to make them dynamic. Components are meant to be reusable, and even though we used multiple component instances for the counter button, it's quite hard to understand the benefits of reusability without seeing a more realistic example. So that's what we'll do in this lesson. view that renders the page for a coffee subscription service.
You can get this markup inside of the description section below. There I've left a link to both the markup as well as the styles that you'll need to make this work. css, and paste all the styles that are linked in the description here. Make sure you don't add these to the existing styles but instead replace those existing styles completely.
Notice in the markup here that each of the different plans on our page is created by several different pieces of HTML. We have a div with the class of plan, a div with the class of description, and a span with the class of title. And each of these pieces of markup is repeated for each of the different plans. If we had a component here, we could do something like this.
Doesn't that look a whole lot nicer? than all of this duplicated markup. It's a lot easier to follow. It's a lot easier to read.
Oh, and just so you know, having single-worded component names like this is actually considered bad practice. Why? Because they might collide with existing or future HTML elements. Therefore, it's a good idea to make this two words.
Over on the right-hand side, you can see that this does not look right. but that's because we haven't actually created the component yet. Let's do that now. View.
We'll add a template in here, and then I want to copy the markup that a plan consists of, and we'll paste it inside of the template here. Of course, this means we'll also need to import CoffeePlan now instead of the button. Beautiful. Now over on the right-hand side, It looks like the name of it has changed out, but it still doesn't look quite right.
I think that's because coffee plan here should actually be inside of this div with the plans class. So that's great. So now this looks perfect, but we don't have the hacker, that name of the coffee plan displaying to the page. That's because we have the addict hard coded in here as the name of the coffee plan.
So how do we make the name dynamic? Well, to use this specific syntax, we'd have to use slots, which we'll get into a little bit later. But right now we're going to talk about props. They look like HTML attributes.
That is, they have a key and a value. Now we need to update our coffee plan component in order to actually accept this prop. We can do that inside of script setup with the define props macro. Notice that I didn't have to import define props.
from view. That's because this is a compiler level macro that only exists in the pretty code that I have here in my IDE. It never actually runs in the browser. It compiles down to something else.
But the important thing to know is that you don't have to import it. You just use it. Okay, so define props allows me to define any prop. The one I want to define is called name.
So notice here I could define multiple props if I wanted to. This is an array. and I can just add as many different props as I'd like. We'll just stick to one for now, and then down inside of my template section here, I can print out the prop with the mustache syntax.
Over on the right-hand side, the hacker does display now on the page. Notice in our code that we were able to name our prop here and then use that prop directly inside of the template. If we wanted access to the prop though inside of a script setup, we would have to first set a variable called props, and then you could access each individual prop on that object. name, and then that would be the single, the curious, the attic, and the hacker respectively for each component on the page.
We don't need that though, so I'll just remove it. With the component now complete, we can use it to power the rest of the plans in our app. So I'll copy this, make one for the addict, do the same for the curious, and then finally the single. That means we can get rid of all of this markup above.
And that looks a ton cleaner, but we get the exact same output on the page. What was close to 20 lines before is now just four. Another thing we could do here, is create an array of our different plan names and loop over them displaying a coffee plan component for each of them. To do that, I'll import ref from view, and then we'll create the reactive ref, call it plans, and pass it an array of each of the different coffee plan names.
Down inside the template then, I can use v4 and loop over plan and plans, give it a proper key, And then we can get rid of all the other coffee plans here. Awesome. So notice now we have the single four different times. I need to make the prop dynamic.
This is done just like any normal HTML attribute by using the bind or the shorthand colon. Now I want to pass it the plan instead of a hard coded string. And this gets us exactly what we had before. How smooth is that?
Before we move to the next topic, let me show you one more thing. Props are something that you'll use very often, and so it's great to know some best practices directly from the beginning. Let's take a look at a few alternative ways to define our props. So it could be an array as we have here, but this method doesn't give us a whole lot of control.
Another way to define our props is as an object. And then we use the object keys in order to name the props. So for us, that is a name prop. And then for the value, we can say what kind of data we expect, like an array, a string, a boolean, or a number.
If we had another prop here called price, it could be a number while name is a string. This documents your component and will throw a warning in the browser console if you try to pass a wrong value. view and try putting a boolean here instead of a string for the coffee plan name. It shows true here, but in our browser console, we'll see these multiple warnings.
Okay, we have an invalid prop type check filled for prop name, expected string, but got a boolean. That's pretty cool. And we can even take this a step further by providing a type here. This is going to be string.
but then we can do other things like give it a default value. So maybe the default value for a coffee plan is default plan, or we could make a property required. So here we could say type number, we could say required true. Now when we take a look in the browser dev tools, you can see not only the invalid prop for the name, but now we also have this warning here, missing required prop.
price. Awesome. This is just a sampling of some of the options that you can use to configure your props. If you'd like more documentation on what all is available, I've left a link to the official VGS docs in the description below.
Finally, let's review what we've done so far in this lesson. First, we created a coffee plan component in order to consolidate some of the markup that it takes to create a coffee plan to a single place. view without having to repeat the markup for each one. We also defined a name prop to make the component flexible and display something different depending on the value passed for the name.
So while we're at it, let's go ahead and change back name to the proper plan name and I will remove the unused price prop. js and define props to make them dynamic.