When to split a Vue component into multiple components (sub components)

Question

When creating Vue components, how does one decide when to separate out a component into a parent component with multiple child components versus just having a single component with more logic?

I am using Vue in a few places on a non-SPA website. On one of the pages of the site I need to display a list of items, with some icons next to each item to do some simple things like show/hide. I am building the list as a Vue component, lets call it ProductList. But I am not sure whether to make each item within that list a separate component or not. When is it appropriate to split a component into multiple sub components?

My own reasoning tells me that components should only be created for things that need to be able to stand alone. Since the items are not going to be used outside of a list, there is no point in having them a separate ProductListItem component to put inside the ProductList component. I should just have all the code in the ProductList component. Right?

But when I look at other examples on the internet, many of them tell a different story. For instance, I recall seeing an example where there was an Article component, an ArticleTitle component, an ArticleBody component, and an ArticleEnd component (or something like this). The template of the Article Component had <article-title>, <article-body> and <article-end> within it. If an ArticleTitle component or an ArticleBody component is only going to be used inside the Article component, not standalone, why bother having it be a separate component? Am I missing something here? Is there a technical criteria on which to base the decision of whether to have multiple components or is it just personal preference?

Answer 1

Typically it is best to create a new component in the following situations:

• if the component will be used more than once across your app, especially if it isn't coupled to the parent component.
• if the component has a lot of logic, or a big template, etc, then it is best to separate it so it doesn't bloat the parent component. Try to keep your components small and easy to reason about.
• if the component has logic that can be tested in isolation from the parent component.
• if the component has some internal state that would be easier to implement as a separate component with its own internal data that the parent shouldn't have to manage.

As for your list component, it seems like each list item is specific to the product list and won't be used elsewhere and probably isn't very complicated, so it's fine to keep it within the list component. Separating components out unnecessarily just increases complexity and memory usage (especially for lists with lots of items) with no benefit.

Answer 2

Interesting question, I think this really depends on the developers and its all gonna become agree to disagree. However, wanna share my experience if it helps:

In a most optimised system design, it should be split into components, because thats what modern frontend framework beats pure html coding ( component-based coding). When should we split the components, I think Decade Moon's answer makes a good and clear point. However, I want to write more about the type of components:

1/ View components ( or dumb components): only for purpose of display, no logic of data flow

2/ Control components ( or smart components): display many dumb component and contain data flow logic

3/ Containers (or views): contain many control components, usually put the logic of server interaction here ( api call ,.... )

When we divide like this, it would be easier for maintenance because we control how the data flow better.

So back to your example: the Product list is like a control component, and the list item is likely a view component. Therefore, i actually support the idea of separating them.

Splitting components will make the directory structure become longer, however with good naming and filtering, I think it still better than having single file components with too many code lines.