Bootstrapping a Vue.js Project - Part 1 Structure

πŸ“… Wednesday, January 10th 2018

⏱ 6 minutes read

Welcome to this series of articles on working your way through a new Vue.js project. I’ll break down the series into three (or possible more) parts as followsΒ :

Part 1: Structure
Part 2: Initial configuration and caveats - TBD
Part 3: Best practices - TBD

One of the easiest ways to make sure your project won’t be overwhelming in the long run, is to set up some conventions from the very early on. Having a clear and true structure, will make all the pieces to come, fall into place and sweep maintaining nightmares away.

Thus, for the first part of this series of articles, I will talk about my preferred folder structure and set up some boilerplate code for the main pieces. Without any further ado, this is the main skeleton we’ll work on. Note that some files and folders that I’ve included (e.g datepicker.js, charts) are just there to fill the gaps and give you an idea.

β”œβ”€ src
β”‚  β”œβ”€ assets/
β”‚  β”‚  β”œβ”€ fonts/
β”‚  β”‚  β”œβ”€ styles/
β”‚  β”‚  β”‚  β”œβ”€ partials/
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _common.scss         # Common styling, e.g anchors.
β”‚  β”‚  β”‚  β”‚  β”œβ”€ (_tables.scss)       # Element stylings that get too lengthy
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _layout.scss         # CSS not suitable in layout/components scoped css
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _helpers.scss        # If not using bootstrap 4 helpers
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _reset.scss          # Reset, Normalize, whatever
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _typography.scss     # Typography specific
β”‚  β”‚  β”‚  β”‚  └─ _variables.scss      # Strictly variables
β”‚  β”‚  β”‚  └─ main.scss
β”‚  β”‚  └─ svg/
|  β”œβ”€ components/
β”‚  β”‚  β”œβ”€ layout/                    # (The)Header, (The)Sidebar etc.
β”‚  β”‚  β”œβ”€ major/                     # Components that consist of 'minor' components
β”‚  β”‚  β”‚  β”œβ”€ charts/
β”‚  β”‚  β”‚  β”‚  β”œβ”€ ChartBar.vue
β”‚  β”‚  β”‚  β”‚  β”œβ”€ ChartPie.vue
β”‚  β”‚  β”‚  └─ ColorPicker.vue
β”‚  β”‚  β”‚  minor/                     # Lowest level components
β”‚  β”‚  β”‚  β”œβ”€ Avatar.vue
β”‚  β”‚  β”‚  β”œβ”€ MessageBox.vue
β”‚  β”‚  β”‚  └─ Rating.vue
β”‚  β”œβ”€ utils/
β”‚  β”‚  β”œβ”€ api/
β”‚  β”‚  β”‚  β”œβ”€ calls/
β”‚  β”‚  β”‚  β”‚  β”œβ”€ user.js
β”‚  β”‚  β”‚  β”‚  β”œβ”€ something.js
β”‚  β”‚  β”‚  β”‚  └─ else.js
β”‚  β”‚  β”‚  └─ index.js                # Axios instances and interceptors
β”‚  β”‚  β”œβ”€ directives/
β”‚  β”‚  β”œβ”€ helpers/                   # Common functions and plugin configurations
β”‚  β”‚  β”‚  β”œβ”€ filters.js              # Text transformations, moment functions, etc
β”‚  β”‚  β”‚  β”œβ”€ colors.js               # Color combinations for charts.
β”‚  β”‚  β”‚  └─ datepickers.js          # Datepicker options
β”‚  β”‚  β”œβ”€ i18n/
β”‚  β”‚  β”œβ”€ store/
β”‚  β”‚  β”‚  β”œβ”€ modules/                # Always use modules, keep them seperate from views
β”‚  β”‚  β”‚  β”‚  β”œβ”€ user/                # Either keep a single index.js or if getting lengthy
β”‚  β”‚  β”‚  β”‚  └─ dropdowns/           # break into _actions.js, _mutations.js, etc
β”‚  β”‚  β”‚  └─ index.js
β”‚  β”‚  β”œβ”€ router/
β”‚  β”‚  |  └─ index.js                # Totally dependable on the length of the project.
β”‚  β”œβ”€ views/
β”‚  β”‚  β”œβ”€ landing/
β”‚  β”‚  β”‚  └─ Landing.vue
β”‚  |  β”œβ”€ interface/
β”‚  β”‚  β”‚  β”œβ”€ view1/
β”‚  β”‚  β”‚  β”‚  β”œβ”€ subview/
β”‚  β”‚  β”‚  β”‚  β”œβ”€ _routes.js            # path & child views paths, imported in app/routes.js
β”‚  β”‚  β”‚  β”‚  β”œβ”€ View1.vue
β”‚  β”‚  β”‚  β”œβ”€ view2/
β”‚  β”‚  β”‚  β”œβ”€ view3/
β”‚  β”‚  β”‚  └─ (interface)_routes.js   # imported in utils/router
β”‚  β”œβ”€ AppWrapper.vue                # Main app component
β”‚  └─ main.js                       # App entry file
β”œβ”€ public/                          # static assets (no webpack)
β”‚  └─ ...
β”œβ”€ ...
β”œβ”€ ...
└─ ...

Notice: No project skeleton is perfect.

Let there beΒ style

Contrary to my love for PostCSS, I mostly use SASS and compliment it with any PostCSS plugin that seem appropriate. The partial SASS files categorization is not set in stone, but that’s the general idea. Anything that it’s really specific, put it the component’s scope.

Friendly reminder, use classes to target the appropriate elements.

The toolboxΒ folder

I keep a folder called utils, where all the cool JS files hang out. There you can find the HTTP client instances & calls, the router configuration, as well as the store and it’s modules.

I also include a folder called helpers. From this part on, it’s up to you. Every bit of code that shouldn’t really be in aΒ .vue file method, can be abstracted and called from there. At the very least, write your filters here.

Tip: Modifying Webpack configuration, it’s easy to set up an alias and expose this folder as β€˜utils/something/something’ for easier access. Relative paths are like semicolons, it’s best to avoid them.

Do i need so many routes.js files? Actually I did not getΒ it.

Consider the following:

    Tournament.vue        # Just a 'router-view' wrapper

Naming conventions aside, here’s what the single Tournament routes would be

import Overview from './TournamentOverview';
import Participants from './TournamentParticipants';
import Settings from './TourmamentSettings';

export default [
    path: '',
    name: 'tournament-overview',
    component: Overview,
    meta: {
      requiresAuth: true,
    path: 'participants',
    name: 'tournament-participants',
    component: Participants,
    meta: {
      requiresAuth: true,
    path: 'settings',
    name: 'tournament-settings',
    component: Settings,
    meta: {
      requiresAuth: true,

With the children views, imported in the upper level.

import List from './TournamentsList';
import Single from './Tournament';

import tournamentRoutes from './Tournament/routes';

export default [
    path: '',
    name: 'tournaments-list',
    component: List,
    meta: {
      requiresAuth: true,
    path: ':tournamentid',
    component: Single,
    meta: {
      requiresAuth: true,
    children: tournamentRoutes,

If your app have very few screens, you can most likely get away having everything in utils/router. Otherwise it’s best to split everything into smaller pieces of code.

That way, if you need to rename or re-organise the children views, you don’t have to scroll past a huge route tree with irrelevant information. These routes are tightly coupled with the components, so there’s no point to have them elsewhere.

Ideally the utils/router should only export the Router and have some middle-ware logic for transitions between pages. Consider the following snippet for a simple Auth check before every transition.

router.beforeEach((to, from, next) => {
  if (!to.meta.requiresAuth || store.state.user.authenticated) {
  } else {
    next({ name: 'landing' });

// and we use the meta tag as follows
// {
//   path: '/users',
//   name: 'users',
//   component: Users,
//   meta: { requiresAuth: true },
// },

What about the APIΒ helper?

Axios will be the HTTP client of our choice. We can initialize an instance of with some default properties and reuse it in every part of our application.

Taking it one step further, we can apply some middle-ware for better error handling.

import axios from 'axios';
import qs from 'qs';

const API_URL = process.env.API_URL;
// const OTHER_API_URL = pricess.env.OTHER_API_URL

axios.defaults.headers.common.Accept = 'application/json';

// Instances -----------------------------------------
export const apiService = axios.create({
  baseURL: API_URL,
// If needed, hasle free calls to another API
// export const otherService = axios.create({
//     baseURL: OTHER_API_URL
// })

// Interceptors -----------------------------------------
// ----- Before
  config => {
    config.paramsSerializer = params => {
      return qs.stringify(params, {
        arrayFormat: 'brackets',
    return config;
  error => {
    return Promise.reject(error);
// ----- After
  response => {
    return response;
  error => {
    if (error.response.status === 401 || error.response.status === 400) {
      // your prefered global error handling
    return Promise.reject(error);
// ------------------------------------------------------

export function setToken(token) {
  axios.defaults.headers.common.Authorization = `Bearer ${token}`;

What about the call themselves?

I like to keep the requests separate from the Vuex actions, in order to keep things modular and a bit more tidy.

import { apiService } from 'utils/api';

export const requestMemberInterests = params => {
  return apiService.get(`/path/to/happiness`, { params });

export const requestMemberSubscriptions = params => {
  return apiService.get(`/path/to/happiness`, { params });

// etc
import * as dropdowns from 'utils/api/dropdowns'

// ...
 async getMemberCategories ({ commit }, params) {
   const response = await dropdowns.requestMemberSubscriptions(params)
// ..

I’m ready forΒ kickoff

Vue.js CLI is pretty awesome for painless project initialization. I kick-start my projects with the Webpack template although Brunch seems promising) and some specific configurations I’ll go by in the next article.


Watch out for the next parts!

Thanks for reading!  ❀️
Next up: Error handling with async-await in Vue and Vuex
Previous: 5 commandments for new developers
Due to privacy concerns, I've decided to remove Disqus.
Until I settle for another commenting solution, you can share your thoughts with me via e-mail
Back to Posts