Take your components and break them up into smaller pieces.

Or create new components and composables that let you encapsulate and reuse code in a better way.

This is the simplest way to clean up your Vue app and make you and your team more productive.

Instead of sharing patterns or tactics on how to do this though, I want to take a higher-level approach, and explain why this is true. I’ll also throw in a bit of how, but we’ll keep the discussion here to insights, not code.

In this article, we’ll cover 6 different reasons why you should split up existing components to create new ones:

1. Optimize for humans by making your components easier to think about
2. Reusing Code and Knowledge is easier when it’s DRY
3. Testing is easier with good architecture
4. Decouple components and focus them on a single task
5. Working with others can be made easier with good decomposition
6. Shield your codebase

The things that I didn’t include in this list may be just as important as the things that I did include.

1. Optimize for humans by making your components easier to think about

The most important thing we can do when writing code is to make it work.

The second most important thing is to make it understandable to other humans — including ourselves.

All too often we write clever code, terse code, code that isn’t even understandable to ourselves when we come back to it a week or a month later.

Here are some ways to fix that:

• Extract Components — by replacing a chunk of code with a meaningful name, we can separate the intention of the code from the implementation of the code. Good names are the most valuable form of abstraction that we have.
• Shorter components — longer components are harder to understand at a glance, and that should be the ideal we strive for. The harder it is to understand a single component, the more mistakes you’ll make, and the longer it will take for you implement anything new.
• Optimize for the most tired, frustrated version of yourself — Remember that we all have bad days, and we want to productive every day, not just our best days. Write code that even the worst version of you can understand.

2. Reusing Code and Knowledge is easier when it’s DRY

Don’t Repeat Yourself — an acronym that many know and that many don’t actually understand.

DRY isn’t actually about code, it’s about the knowledge and decisions that are contained in the code. Too often we are just pattern matching on syntax, and that leads us to bad abstractions that should never exist.

Here are some ways we can fix that:

• Don’t Repeat Yourself (DRY) — Use components and composables to create reusable views and logic. Doing this well is an entire topic all on it’s own, which is why I created a whole course on it.
• Optimize for Change — Most of our time is spent modifying existing code, so it pays to make it easy. If code is new or likely to change, don’t worry about abstracting it into a new component yet — duplication is welcome here.
• Syntax vs. Knowledge — When removing duplication or “drying up” your code, make sure you’re encapsulating knowledge and not syntax. Just because code looks the same doesn’t mean it is the same.

3. Testing is easier with good architecture

Testing is important to do, but it can be hard to do.

In my experience, good architecture lends itself to easy-to-write tests (or at least, easier-to-write). The inverse is also true, that difficult-to-write tests are typically a symptom of poor architecture.

Of course, sometimes tests are just hard to write, and there’s no way around it.

The best thing we can do is borrow a tool from mathematics and science, and transform a difficult problem into an easier but equivalent one:

• Humble Components — UI is notoriously hard to test, and always has been. So keep as much in Humble Components, components that only receive props and emit events and nothing else. By making our UI as simple as possible we also make it much easier to test.
• Extract logic to composables — And I mean all of your logic. Components (that aren’t Humble) should only contain the bare minimum to connect all the different composables together. Think of them as Controller Components, the “C” in MVC.
• Composables are thin layers of reactivity — The easiest thing in the world to test are pure functions that have no dependencies. If you can make the majority of your codebase simple JS or TS code, you’ve already won. Composables then become simple wrappers that add a layer of reactivity to this business logic.

4. Decouple components and focus them on a single task

Changes are really difficult to make if components have lots of dependencies on each other, or if they’re doing multiple things at once — often these issues come together.

If we can disentangle the spaghetti code we can make our lives a lot simpler.

Here’s how we can do this:

• Single Responsibility Principle (SRP) — Each component should have a specific and clear purpose. This makes it easier to know where new code should go, or how to use a component. If you can’t come up with a good, meaningful name easily, then that’s a sign the component is probably doing too much.
• Isolating knowledge — Keep knowledge about domains, systems, and decisions encapsulated in a single spot. This is DRY code in action, and makes it easier to update things in the future since we don’t have to track down multiple places all over our code base.

5. Working with others can be made easier with good decomposition

Most of us are working on teams with other developers.

Sometimes, this presents some challenges: merge conflicts, long-lived branches, regressions, and other issues can come up.

One way to make this easier is to have a clear and organized folder structure:

• More files means a smaller chance that you’ll have a merge conflict — another benefit of small components.
• Keeping related files near each other means that each PR only needs to change a small section of the codebase.
• You can try using a folder for every single component. Then, extract sub-components, tests, and component specific composables into the folder so they’re always nearby.

6. Shield your codebase

Every code base that’s been around for awhile has those ugly parts.

Maybe it’s legacy code that no one wants to touch, or an experiment or beta test that is changing frequently and causing lots of breaking changes.

If we encapsulate those parts nicely inside of components, the rest of our codebase can pretend they don’t exist.

Ideally, though, you can fix these problem areas instead of just ignoring them. But often we need a short-term fix to get us there.

We can also use this for code that isn’t exactly bad, just hard to work with: some libraries or APIs might benefit from being wrapped in a Vue component instead of being used directly in our application.

Getting to Root Causes

These are the main reasons why you should be splitting up components and creating new components in your Vue app.

Of course, there are likely other reasons that I missed, but I think they’re ultimately variations on these reasons at the end of the day.

Notice how I didn’t include things like, “Your component is more than 500 lines of code”.

Justification like this using arbitrary metrics isn’t helpful, and often not the actual root cause. For example, the reason that you may dislike components with 500+ lines of code is that they are hard to understand (Reason 1).

It’s always important to ask yourself, “why?”, when you feel like you need to refactor a component, or when a component becomes too difficult to work with. Hopefully this list gives you a better starting point.