Structure a Large Scale Vue.js Application

07 December 2021

Introduction:

As an honest framework, vue.js features a very small learning curve and is straightforward to configure.

When starting a brand new application, the common challenge for an architect or developer are:

1. How to structure the appliance as modular, flexible, and scalable.
2. How to handle HTTP calls.
3. How to do management.
4. How to add exception handling.
5. How to add logging.

What is the straightforward path to structure a Vue.js application so that it scales and remains maintainable and extendable the more applications grow? This is a problem that I have heard on numerous occasions in which I feel one answer thereto question lies within the principle of predictability. When the application involves creating a scalable project you would like everything about it to be as predictable as possible.

What exactly do I mean by predictability? At its simplest, it’s the power to intuitively go from a feature request or bug report back to the thing within the codebase where said tasks are often addressed. Furthermore, it is the ability to quickly know what tools you’ve got access to at that location within the codebase to finish the task at hand.

I think it’s worth noting here that, while predictability is feasible, no project will ever be 100% predictable. Every project, new or existing will have a minimum of a small learning curve. Also, know that predictability doesn’t suggest that the codebase or application is quickly understood as an entire. Many large-scale applications are just too complex for this to be possible and they’ll take time to know in their entirety. Thus, predictability isn’t about seeing the whole finished puzzle but more about knowing the shape of a specific piece and having the power to quickly see where it fits. The character of an honest codebase lends itself to being understandable a bit at a time and should not require its developers to ever need to believe the whole thing at once.

So how can we accomplish predictability during a codebase? The answer: standards, plain and simple. Maybe that’s not the solution you are looking for but it’s true. The best thanks to making anything predictable is to follow a group of standards. For example, I can predict with almost 100% certainty that the new full-size sheets that I bought just today will fit my bed albeit I’ve never dressed it with those sheets before. Why? Because of the quality sizing system for bed sheets.

The standard file structure at the beginning:

The best thanks to starting with Vue.js is to use Vue CLI Configure the project.

Installation requirements: Vue cli 4.x require Node.js version 8.9 or above (v10+ recommended)

$ npm install -g @vue/cli

$ vue create hello

The directory structure of the first Vue project:

├── dist

├── config

├── public

├── node_modules

├── src

│   ├── App.vue

│   ├── assets

│   │   └── logo.png

│   ├── components

│   │   └── HelloWorld.vue

│   ├── views

│   │   └── About.vue

│   │   └── Home.vue

│   ├── main.js

│   └── router

│       └── index.js

Some important points of the director are the following:

1. Assets directory: The assets directory contains uncompiled assets such as Less, Sass, or JavaScript.
2. Components directory: The components directory contains all the Components.
3. Mixins directory: The mixins directory contains reusable mixins for reusable components and considers components.
4. Router directory: The router directory contains all the routes of the application.
5. Store directory: The store directory contains all Vuex Store files data and modules.
6. Views directory: It contains application views and routes.

Component Recommendation Rules:

Now check the component catalog. The Vue style guide provides us with more tips to make our file structure more predictable. Among other things, the planning guide encourages the next when it involves defining components:

• When possible each component should be defined in its dedicated file.
• Single file components should be named in the PascalCase.
• Base components should start with the same prefix, You can consider base components as your app-wide reusable components sort of a button or a modal
• The component name should always consist of multiple words to avoid conflicts with existing or future HTML elements. Don’t create form or button components.
• The single instance components should begin with the prefix
  • For example, website header or footer
  • This groups them together and declares them as single-use.
• Tightly coupled child components should be prefixed with their parent component’s name.
  • For instance a TodoListItem during a TodoList.
  • This groups them together and declares them to be related.
• Component names should begin with the foremost top-level (usually general) words and end with the foremost specific
  • Such as SearchWidgetInput, SearchWidgetResultsList, SearchWidget.
  • This groups related components together within the file structure

Hold tight if these don’t completely add up, there is a picture coming during a moment that can help. Besides these, the entire style guide has several other standards which can help your project be more predictable to a community-wide audience of developers.

Some Recommended Personal/Team-Wide Standards for Predictability:

While there are some great standards set in the Vue.js community at large by official sources, there are other patterns not so widely adopted that, will be helpful and made into standards for you or your team’s projects. These standards are necessary because community-wide standards are not 100% complete, but be careful and be strict when it involves how team standards are decided upon and maintained. Many times, if you are not careful, this will become a hiding place for changing rules. That said, here are a variety of my recommendations for your Vue.js project standards.

A Flat Component Directory:

The naming conventions always help group related components together within the file system. A flat component directory has the next benefits:

• Quickly and easily go from spotting a component in Vue dev tools to finding the enter the codebase (the filename and thus the component name are the same)
• Use your IDE’s quick find or file jumping feature to filter files supported their most general attribute right down to the more specific
• Remove analysis paralysis when it involves deciding the thanks to organizing components into subdirectories.
• Be able to see all of your components directly during one list
• Get obviate the redundancy of keywords in filenames AND within the directory (that is that if you’re following the planning guide (and you need to be) and you’re using nested directories) (ie. post/PostList.vue, post/PostFeature.vue, etc)
• Remove the temptation to use short one-word component names which is simpler to try to do with nested directories (ie. post/List.vue, post/Feature.vue ) and violates the planning guide
• Eliminate surfing the file structure in and out of directories to hunt out a component
• Simplify importing components. It will always be import SomeComponent from “@/SomeComponent”.

So what does a flat structure that follows the planning guide look like? Here’s an honest example.

Standardized Route/Page Naming Convention:

Another practice that creates sense may be a standardized way of naming our routes and page components. In your typical CRUD application you’ve got the subsequent different pages for every resource:

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

While a number of these may find yourself being a nested route (like viewing the only resource during a modal overlay from within the list page), they typically find yourself having a fanatical route with a corresponding page.

Since I even have a background within the PHP framework Laravel, when it came to naming routes and predictably defining their paths I intuitively fell back on the standards that Laravel already had in place. Using a users resource as an example, the naming convention prescribed by Laravel and adapted for Vue that I prefer to recommend is as follows:

Path	Route and Component Name	What it Does
/users	UsersIndex	List all the users
/users/create	UsersCreate	Form to create the user
/users/{id}	UsersShow	Display the user’s details
/users/{id}/edit	UsersEdit	Form to edit the user

While tempted to call the route during a more traditional Laravel manner like users. index rather than UsersIndex, I’ve found that using the PascalCase works whilst well and has the extra advantage of matching the component name.

For further consistency and adaptability, you ought to also always reference your routes via their name when using them in router links and when referencing them programmatically.

For example:

<router-link :to=”{name: ‘UsersIndex’}”>Users</router-link>

More complete file structure:

Besides the essential file structure that Vue CLI gives you out of the box, I suggest standardizing subsequent for better predictability and management of the file structure.

The added directories are documentation, helpers, layouts, mixins, and plugins. You will notice that 4 of the 5 have a flower icon next to them, provided by the VS Code extension material icon theme. That’s because on only one occasion or another, for a couple of frameworks or languages, these directory conventions were common enough to urge their icon within the eyes of the extension developer. That’s no coincidence!

So what are the reasons for these file structure standards?

Docs:

The purpose of this one is obvious but the more important thing is that it’s included and is sitting there staring your team right within the face whenever they open the codebase. If the developer has never successfully uninstalled their IDE, it is more likely to document certain aspects of the project. I’ve also discovered (it was a satisfying surprise) that writing docs first before coding out a Having reusable classes or components often helps me improve the interface or API of such code.

In addition to the documentation directory, I also found a README file, which is a useful file based on any standardized directory. Explain the purpose of the directory and the rules for its content. This is particularly useful for standards that are not applicable to the community.

Helpers:

This is a typical directory in many frameworks for basic input and output functions that can be reused in a project. They are usually easy to test and are usually only used once. I prefer to start with the index.js file, and then as the assistant gets bigger, break it down into more cluster files, such as https.js, cache.js, time.js. Everything during this directory can just be imported and used on-demand and if a function lands up never getting utilized in the smallest amount it’s often easily trees shaken from the assembly bundle.

Layouts:

I got this convention from Nuxt, just like Laravel. Not only define the components of the page but also define the layout components that are reused across multiple pages. As the name suggests, these components define the overall layout, not the content of the page. For example, is it a 1-column or 2-column page? Do you have a left sidebar or a right sidebar? Does the layout include standard headers and footers, or is it a completely blank layout, maybe the page content is centered? There are usually only 2 or 3 of these design components, but they are useful abstractions.

Mixins:

This directory is used to organize all your Vue.js mixins. I find it very important to add the word mixin at the beginning of each file name (e.g. ResourceTableMixin.js) to easily search in the file switcher. Though I even haven’t had the prospect to work on a way bigger scale Vue 3 project yet, I assume this might probably quickly change to a composable directory in preference of extracting reactive data/methods with the Composition API instead of with mixins. Or at least you can add a compound directory to my standard file structure and add it to the mixin directory

Plugins:

The last directory I want to add to all Vue projects is the plugins directory. In the world of packages and libraries, we sometimes do more customization and registration than programming. Although they are called plug-ins, I don’t always use the term in the strictest sense. In other words, it doesn’t get to be a third-party lib registered via the Vue .use() method. This happens often, but sometimes alternative methods are used to fix libraries that use Vue (such as .component()). For libraries that use 1 or 2 lines of configuration, I will write them in the plugins / index.js file.

Conclusion:

While there are some community-wide standards that you simply would have best to not ignore, there’s also the kind of standards you’ll bring back to you or your team to form your codebases more predictable.

As applications grow, so does the problem, which requires better structural management applications. With the help of the above guide, we can Structure a Large Scale Vue.js Application.