The Vue architecture that worked for me. (in small and large apps)

source: http://blog.stunited.org

Hi, I want to share with you the way that I’ve been working on Vue.js. Some of the practices that have worked for me, this can actually fit on a lot of frameworks (some parts), like React.js, Polymer or Angular.

1.- Components

1.1.- Make a Component, not a swiss knife
 Visual components must follow some rules. A component shouldn’t communicate with the store directly or make calls to the api. If we add that to our component it becomes very non-reusable. And the whole point of components its to reuse them.

Some of the rules that I follow to develop a component:
 • They must be “dummy”. They must follow the single responsibility principle. This means that your component should only to his job and thats it, it should be prepare to accept data from a parent. Example: a table must sort the data in columns and rows depending on the data passed from
 it’s parent.

• They shouldn’t interact with the “outside”, directly. The only way to do this is with events.
 • They should be independent. This means that they should and must work by they own. They’re not
 tied to a specific architecture or forced to have a store, etc.
 • They must be reusable
 • They must be able to be styled from the ‘outside’
 • They must have only the necessary logic.

1.2.- The gold rule:

source: https://vuejs.org/

1.3.- State of the components
When we create a component we should have in mind this four states:

  1. Loading
  2. Success
  3. Empty (edit, advise from Loki Zavala)
  4. Error

1.4.- Not everything is a component
 We should avoid create a very small component. This is to avoid the overload of components/dependencies on our project. Example: a link with an icon

1.5 .-Communication between components?
 Vue doesn’t allow us to communicate between nested components (without doing a callback hell) the ones that are in different pages. Out there are a lot of different approaches to do this, here’s an example: https://www.npmjs.com/package/vue-bus

2.- Page as models

Vue uses the MVVM pattern, so a page can work as the model (VM). This is the data provider for our components. This is where we have the store calls (getters, actions, etc). Also you can style the components from here (in some cases)

3.- Modular Code (divide and conquer, for real though).

The modules are pieces of reusable code that can be implemented wherever and whenever we want. Making a module in JS is easy, and it must follow a lot of the components rules because we are going to re-use them.

3.1.- When to create a module
 If you see yourself repeating a configuration or a code in different places you should create a module for it.

A case of a module: Let’s say we are using axios to call the api, and we need to make 30 calls all along our app, in this case we can create a module that has all the logic to make a call to the api, it can accept every parameter. This will allow us to call the server with a simple function instead of making a fetch function on different instances.

4.- Store

This is how Vue tells us to do the store:

source: https://vuejs.org/

4.1.- What do we need to have in mind when we do the Store?

  • Single Source of Truth
  • Data is Read-only
  • Divide the store per page

4.2.- Single source of truth

The application data (user is admin, user is logged, etc). Should be at one place only (the store). The pages should only read from here and they shouldn’t have their own copy to avoid problems along the app.

4.3.- Data is read only

The pages are not able to mutate the state directly. If you need to mutate it, it’s through an action.

4.4.- What goes in the store?

  • The data of the current view
  • The state of the current view
  • The “is” concept. (is loading?, is ready?, is current?, etc)
  • Shared data

5.- Styles for the App (components, and layouts)

This is tricky, but I’ll try to explain myself

5.1.- Styling “internal” components
 By internal I mean, that are not open-source, you have them on your ‘components’ folder or are company internal.

In this case we can make our component with some base-style, but it should be able to accept styles from the outside.
 
5.2.- Styling components that will be open-source.
 This components should have the minimum style possible and everything should be stylable from the outside

5.3.- Global styles
 We should have a global css file. I call this theme, here’s where we are gonna define the fonts, font-size, etc. But also some components styles.
 For example, if we have a component with the same style all along our app, those styles should be in the theme, with this we avoid the css over-write.
 The base css must be here, and the styles that are going to be across the app.

Thanks to the pre-processors we can have several files and import them in the theme so this file can be readable.

I’ll love to hear from you, and what you think about this, my twitter is @edernegrete_. ❤️