How I structured my Vue project for scaling large Vue.js application

#vue #structure

Vue.js is great. However, when you start building large scale Vue applications, you will find some architectural issues in your application. These issues are not really the limitations of the framework; rather these are the important design decisions that Vue.js team had taken from time to time.

Unlike React or Angular, Vue.js caters to the different level of developers. It is developers friendly, easy-to-use for beginners and equally flexible for experts. It doesn’t try to shy away from DOM. Instead, it plays well with it.

Like other developers, first, you have to consider exactly what are your needs when building a large scale application. So I will share my own experience building a large app with vue, vuex, vue-router as front-end application.

The difficulties of building a large scale application

I face some of the difficulties when I working on a large scale application. we should Be prepared to

Review the behavior, the architecture, the code base and the look of the front-end several times, which takes a long time.
Change several times as long as the change in the backend the ways to access the data.
Manage code from different developers with diametrically opposed ways of thinking.
Rewrite codes to the developers that you do not like within your guideline.
Spend a lot, but a LOT of time writing and debugging tests.
Give question answer for the developers and manager where you have written the codes.
The estimates you make on new features ALWAYS magically transform to deadlines, with big events if they are outdated.
Be very very flexible in all those things you need to be ready for.

Component Modularisation

A component as a build tool not only deals with JavaScript; it can also build CSS, templates and other assets. With builder hooks, it can also pre-process files written in non-native formats, e.g. CoffeeScript, SASS and Stylus. Therefore it is possible to deliver highly self-contained components that encapsulate template structure, JavaScript logic and CSS presentation at the same time.

Vue js default folder structure

I recommend you to start the project with vue-cli. I personally like the default Webpack template provided. Here is the content of the src folder.

.
├── app.css
├── App.vue
├── assets
│ └── ...
├── components
│ └── ...
├── main.js
├── mixins
│ └── ...
├── router
│ └── index.js
├── store
│ ├── index.js
│ ├── modules
│ │ └── ...
│ └── mutation-types.js
├── translations
│ └── index.js
├── utils
│ └── ...
└── views
   └── ...

Modularisation of Vue component

Vue-cli provided a great file architecture. But growing your project, your files will start to become overweight.

You might be tempted to put separate your components into multiple folders. But, again, after 10 pages, you will face the same issue again.

The idea is to split your application by notions. Stick to one unique word.

For example, in a shop application, we could get Catalog, Basket and Payment. Now

├─ src/
│ ├─ components/
│ │ ├─ Catalog/
│ │ │ ├─ Components/
│ │ │ ├─ Pages/
│ │ │ ├─ Routes/ Or router.js
│ │ │ ├─ mixin/
│ │ │ │ ├─ catalog.api.js
│ │ │ │ └─ catalog.services.js
│ │ │ ├─ Store/
│ │ │ │ ├─ action.js
│ │ │ │ └─ getters.js
│ │ │ │ └─ mutationTypes.js
│ │ │ │ └─state.js
│ │ │ │ └─ index.js
│ │ │ ├─ Tests/
│ │ │ ├─ Catalog.vue
│ │ │ ├─ index.js

Module A shouldn’t share a component with Module B. For common functionalities (i.e. user logged in, user language…), I have the core folder!

Smart vs. Dumb components

smart components: can access the store, router, window object…
dumbs components: take props, emits events. That’s it!

It is important to keep a separation between your smart components(Pages folder) from the dumbs (Components folder). The main benefits of this approach are reusability, a better separation of concerns.

Testing

Testing application is a very complex topic. It is the hardest part too. By this architecture, I can keep simple and clean. The things I test for the application.

Components: High priority, easy to do. write unit tests for each component. it should be easy to do.
Pages: High priority, hard to do. You probably gonna have to mock API/browser parts.
Routes: Usually bugs aren’t here. Leave it for E2E tests.
Mixins: API Part I personally don’t test this part. But others functions I test it.
Store: The hardest part to test. You can test it via integration tests. Testing action, getter, and initial state separately are useless.

Modularisation of the vuex store

Vuex store, One of the biggest problems with a component-based application. This is a really great tool for state management. The first time I start using the Vue tools, it completely change my mind. But we can’t use it everywhere. With the growing your application the problem arises.

ime travel impossible with lots of mutations when a page load.
The state isn’t reinitialized when page switched. We need to update the state every time;
Overkilled features. You need to create a mutation for everything.

Using module in Vuex store is really great. For beginner user or small projects, you can store data in a file. With growing your project you should separate state, getters, mutations, and actions in different files, which is a good thing. It also presents modules, but without true guidelines to manage them. there’s a lot of ways to handle complexity, each one with pros and cons.

By organizing your store like you gain several advantages :

For more readable and maintainable Having one file per data model is good.
With backend update, you don’t need to change every file.
You can have a consistent getters and methods naming model across different data models.
Don’t overuse the store, you have a complete view where you need to use it or not.

When should I use the store or not?

It’s not mandatory, nor recommended putting all your state inside a Vuex store.

Evan You (creator of Vue.js)

data must be accessible in multiple components of your application, by components which oftentimes are not related in any way, they neither are parents or children of each other.
Data frequently update from different components.
When data complexity is higher to manage it and event passing is not possible
when you need to communicate or pass data between sibling components, or if a data change in one component (such as a boolean change) triggers a change in another

I recommend you to use the local component state as your default and only opt-in to Vuex as soon as a reason to do so arises

The post How I structured my Vue project for scaling large Vue.js application appeared first on Shahadat Hossain.