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:
The things that I didn’t include in this list may be just as important as the things that I did include.
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:
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:
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:
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:
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:
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.
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.