This is an excerpt from my course Clean Components. You can learn more about it here.
It is Lesson 2 of Module 1 — Cleaning up the template.
The applications that we write are filled with repetition. For example:
But just because the interface repeats, it doesn't mean your code needs to be repetitive as well.
This is exactly why we invented computers — to do the tedious, boring things for us!
We know we can reduce duplicated code by reusing components, but it certainly doesn't stop there.
In this lesson we'll be covering:
v-for, with a real case studyAt the very end we'll also discuss some of the tradeoffs that we had to make along the way.
So let's get into it!
As software developers we're always looking for ways to get more done with less work.
So why write something multiple times when you can you write it just once?
By reducing repeated code, you can greatly simplify your components. This makes them easier to read and understand.
And less code means less bugs! 🐛
Plus, if you've copy and pasted code in a bunch of places, what happens when you need to change it in the future? You have to go around and make that same change everywhere you've copy and pasted it.
Gross.
Trust me, it's not a fun task.
Here we have a Menu component that has a lot of repeated sections. Right now the template is 181 lines long, but there is definitely a lot we can do to simplify this component and make it easier to work with:
First, let's explain what's going on in this component.
This is a menu component taken from a tool for browsing Git repositories. In it we have 5 menus:
Each of these menus uses a DropdownList component with DropdownItem components inside for each menu item. There is also a DropdownDivider component which adds in a divider between the menu items.
When the user clicks on the div that wraps a menu, it sets the corresponding flag to true, and the DropdownList is displayed. As soon as the user's mouse leaves the menu though, it's set back to false and the menu hides itself again.
This is repeated for each of the 5 menus we have.
Although this component isn't too bad, there's still a lot we can do to simplify it and make it easier to work with. So let's get going!
First we need to figure out what our strategy here will be.
Since each menu is performing a distinct function, we could apply what we learned from the previous lesson and break each menu into it's own component. That would clean things up a bit, but we can do much better than that.
Let's focus in on one of the menus, and once we figure out how to simplify that we'll be able to apply it to all of the others. We'll look at the Branch menu:
The majority of this component is the DropdownItem component repeated 8 times. That means that we can replace the repetition with a v-for.
Here is the rewritten section:
We'll ignore the DropdownDivider component for now, just to keep things simple.
The result of this refactor is that this section went from 41 lines down to 22 lines, nearly cut in half!
The only part that we changed was how we used the DropdownItem component:
We add in the v-for, looping over menuItems, an array that we'll create in just a moment. Since we already have unique text for the menu, we'll use that as our key as well.
The click handler gets replaced by menuItem.action, and the menu text is replaced by menuItem.text. All that's left now is to create our menuItems array.
To create the array we have to look at what all of the DropdownItem components were doing before, and copy it into an array that looks like this:
Once you've done that, you'll end up with an array in your data() function like this:
Now we've greatly simplified the template of the Branch menu!
But you may have noticed that we didn't actually get rid of the complexity. We've just moved it out of the template and into the data() function of our component. All we've done in this example is move where the complexity lives.
But hold on, we're not quite done here yet.
If we keep going we'll start to see some benefits of this approach. We've just tidied things up a bit. The next steps are where we really start to see some progress.
Now we take the improvements we made to the Branch menu, and apply them to the other menus.
We'll have to create a new menuItems array for each menu to keep them separate.
Our in-progress template now looks like this:
And we'll need to add the following to our data() function:
Yes, we've added a lot to our data() function. But we'll cover why that's not so much of an issue right after we finish cleaning up this template.
Let's quickly recap what we've done.
We noticed that each menu had the same structure of DropdownItem components repeating, so we were able to clean that up using a v-for.
If you look closely at what we have now with our template, you'll see that because we've cleaned it up, each menu now has an identical structure again.
Time to add in another v-for and clean it up!
Let's grab the File menu:
In order to add in the v-for we need to convert every value here to use a variable that will change with every iteration. We'll put all of these on a menu object:
We keep track of whether the menu is open or not through menu.active, we use menu.text to hold the name of the menu, and we're now keeping all of the menu items on menu.items as well.
So each menu object will look like this:
When we fully refactor the rest of this component this way, we're left with a template that looks like this:
To me, this template is very clear and concise. It's quite easy to read and understand what it does.
We had to nest two v-fors to get there, but in the end it's worth it. The template was originally 181 lines long, and now it's only 31 lines!
But I did mention that we're just moving the complexity to a different location, so let's take a moment to understand why we did that.
If we take a look at what the data() function now looks like after this refactoring, it's pretty long:
Yes, we added about 130 lines, so we didn't reduce the lines of code in our app.
But it's not about how many lines of code we have.
It's about the type of code as well. We've shifted 150 lines of logic into 130 lines of static, declarative configuration, and there are many benefits to that:
At the end of the day though, it's all about your judgment.
You could go to one extreme and define your entire app in a giant json file that gets parsed when the app loads. Or you could never use a v-for and explicitly write out each time you want to use a component.
As always, you'll have to rely on your experience and intuition to know the best approach in each situation.
You can also find out more about the course here.