Working with a flat component directory structure in vue

Vue developers glorify making use of nested directory structure in the components directory of Vue. Well, I have worked with both structures on large-scale projects and I am here to share some views on why I prefer a flat directory structure to a nested directory structure.

Photo by Andrej Lišakov on Unsplash

Have you ever worked on a project where you had tons of components and made use of the nested architecture? Let me guess, at some point in the project, you asked yourself what is the best directory to place this particular component. Well, it happens to me a lot when I make use of a nested architecture so I would go ahead and assume it probably happens to you as well. P.S: I may be wrong and probably the only one who has ever faced this issue(But it is highly unlikely).

When I work with a nested component directory architecture, I face problems like:

1. Taking a long time to decide on the particular component sub-directory to place a component.
2. Giving two components the same name. (This is more rampant when working in a team that changes happen in real-time) e.g having two files like:

src\components\dashboard\QuickActions.vue
And
src\components\profile\QuickActions.vue

This could easily bring confusion especially when debugging.

When a flat component directory structure is used correctly, it eradicates these issues and brings extra advantages. e.g, if I was to represent this using a flat structure, I would name it this way:

src\components\DashboardQuickActions.vue
And
src\components\ProfileQuickActions.vue

And when these components are used in the template of a vue project, it makes it easier to read, track the exact file, and also makes it easier to differentiate between the two quick actions components. e.g:

<dashboard-quick-actions />
<profile-quick-actions />

You are probably saying to yourself: The flat directory structure is not scalable, the grouping of the components could become a mess and the list of files in the directory would grow to be so large. Well, that’s why I am here to show you how to handle this issue effectively 😃.

First, I would start by telling you the benefits of the flat directory structure:

1. The few minutes spent deciding the folder a particular component should go into is eradicated.
2. Automation of components through tools like hygen is easier and straightforward.
3. There is no possibility of giving two components the same name hence, it could reduce your debugging time.
4. It is really easy to group components e.g:

A group of base components.

When working with a flat component directory, we still want to be able to group files for ease of access and organization. The best way to achieve this is by using the names of the components by starting the component with the highest level element or parent component. e.g. if we were to have a component named CalendarWidget, and we needed other atoms of the widget like the weekdays, day item, etc. the highest level element, in this case, would be CalendarWidget, hence, the naming of the files would be in the format:

Proper grouping of a CalendarWidget component.

Using this naming format, all components are linked with the highest element or parent component which is CalendarWidget in this case.

Navigating through the long length of files

You are probably asking, how do you deal with scrolling through the files when you have a very long list of components? Well, except for the fact that it is properly grouped by name, files can be easily located using some quick shortcuts on your preferred IDE. e.g, I make use of visual studio code, and in visual studio code, locating a file can be easily achieved by the command:

ctrl + p

After which, VS code puts forth a search input box to find the component by name. Whatever tool you use, I can bet there is a shortcut to find files by name. I guess this is a call for you to do research on your chosen IDE and find out the shortcuts that could help increase your productivity. Since you work with your IDE every day, make it your friend 😃.

Summary

As much as I emphasized more on the flat directory structure, both structures are still great and either of them could suit your team's needs. But, I have found the flat directory structure easier to work with and automate plus it scales just exactly as the nested structure does.