Vue - Directory Structure

In this article, directory structure best practices will be explained.

Recommended Directory Standards for Predictability

Most of the code lives in the src folder and looks like this:

src
|
+-- components        # shared components used across the entire application
|
+-- mixins            # all the mixin object for reusable functionalities on Vue components
|
+-- pages             # all view component that act as a page which is imported on router configuration
|
+-- router            # router configuration
|
+-- test              # test utilities and mock server
|
+-- services          # exported baseService for interacting with API
|
+-- store             # vuex store
|
+-- utils             # shared utility functions
|
+-- validators        # vee-validate custom validator rules

In order to scale the application in the easiest and most maintainable way, keep most of the code inside the pages folder, which should contain different page-based things. Every pages folder should contain domain-specific code for a specific page. This allows you to keep functionalities scoped to a page and not mix it with the shared things. This is much easier to maintain and refactor than a flat folder structure with many files. A page could also contain other pages such as in the case of nested routes.

A page could have the following structure:

src/pages/user/
|
+-- User.vue            # entry point for the page, this top level page contains <router-view/> for nested page routes
|
+-- components/         # components scoped to the User page and/or its descendant, not used anywhere else
|
+-- utils/              # utility functions used only by the User page and/or its descendant
|
+-- profile/
    |
    +-- UserProfile.vue         # entry point for the page
    |
    +-- components/             # components scoped to the UserProfile page, not used anywhere else
    |
    +-- utils/                  # utility functions used only by the UserProfile page

Route - Page Naming Convention

Another practice that makes sense is a standardized way of naming our routes and page components. In your typical CRUD application you will likely have the following different pages for each resource:

1. A list of all the resources
2. A view of a single resource
3. A form to create the resource
4. A form to edit the resource

While some of these may end up being a nested route, they usually end up having a dedicated route with a corresponding page. Here is an example of the naming convention for a "Users" resource: