All right, welcome back. So in this episode, we're going to focus on refactoring, but also, more broadly, I'd like to talk about responsibility. And by that I mean, when you're reviewing these components, you should always be thinking, should this component be responsible for that? And it's kind of a tough decision. It's something you will figure out over time. So here's what I mean. If we take a look at the AssignmentList component, this component is responsible for displaying a list of assignments.

If we take a look at the AssignmentList component, this component is responsible for displaying a list of assignments. But now as part of that, we've introduced all of this terminology related to tags. So I have this block here for displaying my tags. If we scroll down, we have this section here for tracking the current tag. And then down here, we have a computed property for gathering and displaying all the tags. And you can just as easily imagine us adding a little button here to add a new tag. And if we took that approach, we would have to introduce another data property, another method that would append this new tag. We would need some kind of logic to maybe save it to the database, or at least store

method that would append this new tag. We would need some kind of logic to maybe save it to the database, or at least store it in local storage. So very quickly, this component that is really just responsible for displaying a list of assignments becomes aware of so many things related to tagging. Okay, so with that in mind, why don't we refactor this? And often what I like to do is start with the template. So this is the section that we will extract. And why don't we call the component, how about AssignmentTags. Now on this node, you may have noticed, let me create this, that all of our components

And why don't we call the component, how about AssignmentTags. Now on this node, you may have noticed, let me create this, that all of our components related to assignments begin with the word assignment. This is actually a pretty common practice in the Vue world. If nothing else, it's a nice way to group everything like so. Imagine if this component was instead named CreateAssignment.js. Well, in a real project where we have dozens and dozens of files, Create.js would be way down here, separate from all of the other assignment-related components. So it's just a common practice that you can adopt if you wish. Okay, so let's export.

So it's just a common practice that you can adopt if you wish. Okay, so let's export. We'll set up our templates. And we'll paste that HTML block. All right, next we need to start a list of tags that we can loop over. Hmm, how should we do this? Well, right now, our tags are being created here. But maybe I could extract this, bring it over to our computed property, and I'll paste that in like so. But now, yeah, we're in that situation again where in order for this to work, our tags

in like so. But now, yeah, we're in that situation again where in order for this to work, our tags component now needs access to all assignments. And I don't love that. So again, an option might be, let's clean this up, to begin by passing our tags here. And maybe I could just do this inline, .map, and all I care about is the tag name. So this would be a way to pass the initial tags. So now, you'll see that we run into another issue. I want to accept an array of tags. But now we end up in a situation where our prop is named tags, but we also have a computed

I want to accept an array of tags. But now we end up in a situation where our prop is named tags, but we also have a computed property named tags, which we don't want and we can't do. So to skirt around this, you have a couple choices. One option would be simply change the computed name, like allTags. And that might be good because we are taking the initial set of tags and we are extending it to also include this all tag name as well. So that might be fine. Another common approach is to do something like this, where you name the prop either dataTags or even something like initialTags.

For now, I'm going to add it here, but I think we're going to remove this. But yeah, this would migrate everything over. Okay, so now let's switch back. We will import it, import AssignmentTags. We will register it as a component, and then we use it in a template. Okay, let's have a look in the browser. We give it a refresh and I still see my tags. Let's open up Vue DevTools. All right, here's our assignment list. And now I can see it does consist of a AssignmentTags component.

All right, here's our assignment list. And now I can see it does consist of a AssignmentTags component. But now our problem is if I click on one of these, we're not re-rendering the AssignmentList. So let's figure out why. Well, I go in here, we click on it, we update the currentTag, but there's no communication, is there? At no point do we communicate back to AssignmentList that it needs to then re-render the assignments here. And further, we now have this issue where we're tracking the currentTag here, but we

Emit, and why don't we call this change, and we'll pass through the tag that was clicked. All right, now if I switch back, if we come up here, we pass through the initial tags, and then we listen for when it changes, and what we want to do is update the current tag. So I could say changeCurrentTag, we're going to do this inline, equals the tag that was passed through. And when we are responding inline, like we're doing here, remember, we could just as easily call a method, updateCurrentTag, right? But when we do it inline, we can access the parameter by using this magic event variable. Okay, so that would work if you think about it. When I click on a specific tag, we emit a change event, and we pass through the tag.