App Plugins     

A common use case for Quasar applications is to run code before the root Vue instance is instantiated.
Quasar provides an elegant solution to that problem by allowing users to define so-called app plugins.

IMPORTANT
Do not confuse app plugins with Quasar plugins, like ActionSheet, Dialog, Notify. Quasar plugins are something else entirely and will be covered in the Components section.

In earlier Quasar versions, to run code before the root Vue instance was instantiated, you could alter the /src/main.js file and add any code you needed to execute.

There is a major problem with this approach: With a growing project, your main.js file was very likely to get cluttered and challenging to maintain, which breaks with Quasar’s concept of encouraging developers to write maintainable and elegant cross-platform applications.

With app plugins, it is possible to split each of your dependencies into a self-contained, easy to maintain file. It is also trivial to disable any of the app plugins or even contextually determine which of the app plugins get into the build through quasar.conf.js configuration.

Anatomy of an app plugin

An app plugin is a simple JavaScript file which needs to export a function. Quasar will then call the exported function when it boots the application and additionally pass an object with the following properties to the function:

export default ({ app, router, store, Vue }) => {
  // something to do
}

Notice we are using the ES6 destructuring assignment. Only assign what you actually need/use.

When to use app plugins

IMPORTANT
Please make sure you understand what problem app plugins solve and when it is appropriate to use them, to avoid applying them in cases where they are not needed.

App plugins fulfill one special purpose: they run code before the App’s Vue root component is instantiated while giving you access to certain variables, which is required if you need to initialize a library, interfere with Vue Router, inject Vue prototype or inject the root instance of the Vue app.

Examples of appropriate usage of app plugins

• Your Vue plugin has installation instructions, like needing to call Vue.use() on it.
• Your Vue plugin requires instantiation of data that is added to the root instance - An example would be vue-i18n.
• You want to add something to the Vue prototype for convenient access - An example would be to conveniently use this.$axios inside your Vue files instead of importing Axios in each such file.
• You want to interfere with the router - An example would be to use router.beforeEach for authentication
• You want to interfere with the Vuex store instance - An example would be to use vuex-router-sync package
• Configure aspects of libraries - An example would be to create an instance of Axios with a base URL; you can then inject it into Vue prototype and/or export it (so you can import the instance from anywhere else in your app)

Examples of unneeded usage of app plugins

• For plain JavaScript libraries like Lodash, which don’t need any initialization prior to their usage. Lodash, for example, might make sense to use as an app plugin only if you want to inject Vue prototype with it, like being able to use this.$_ inside your Vue files.
• Make API requests - You probably want to do this inside your pages Vue component

Usage of app plugins

The first step is always to generate a new plugin using Quasar CLI:

$ quasar new plugin <name>

Where <name> should be exchanged by a suitable name for your plugin.

This command creates a new file: /src/plugins/<name>.js with the following content:

// import something here

// leave the export, even if you don't use it
export default ({ app, router, store, Vue }) => {
  // something to do
}

You can now add content to that file depending on the intended use of your plugin.

Do not forget that your default export needs to be a function.
However, you can have as many named exports as you want, should the plugin expose something for later usage. In this case, you can import any of these named exports anywhere in your app.

The last step is to tell Quasar to use your new plugin. For this to happen you need to add the plugin in /quasar.conf.js

plugins: [
  '<name>' // references /src/plugins/<name>.js
]

Quasar App Flow

In order to better understand how a plugin works and what it does, you need to understand how your website/app boots:

1. Quasar is initialized (components, directives, plugins, Quasar i18n, Quasar icon sets)
2. Quasar Extras get imported (Roboto font – if used, icons, animations, …)
3. Quasar CSS & your app’s global CSS is imported
4. App.vue is loaded (not yet being used)
5. Store is imported (if using Vuex Store in src/store)
6. App plugins are imported
7. App plugins get their default export function executed, except for App Boot plugin
8. (if on Electron mode) Electron is imported and injected into Vue prototype
9. (if on Cordova mode) Listening for “deviceready” event and only then continuing with following steps
10. (if App Boot plugin exists) Executing App Boot plugin
11. (if no App Boot plugin exists) Instantiating Vue with root component and attaching to DOM

Examples of app plugins

Axios

import axios from 'axios'

export default ({ Vue }) => {
  // we add it to Vue prototype
  // so we can reference it in Vue files
  // without the need to import axios
  Vue.prototype.$axios = axios

  // Example: this.$axios will reference Axios now so you don't need stuff like vue-axios
}

vue-i18n

// we import the external package
import VueI18n from 'vue-i18n'

// let's say we have a file in /src/i18n containing the language pack
import messages from 'src/i18n'

export default ({ app, Vue }) => {
  // we tell Vue to use our Vue package:
  Vue.use(VueI18n)

  // Set i18n instance on app;
  // We inject it into root component by doing so;
  // new Vue({..., i18n: ... }).$mount(...)

  app.i18n = new VueI18n({
    locale: 'en',
    fallbackLocale: 'en',
    messages
  })
}

Router authentication

Some plugins might need to interfere with Vue Router configuration:

export default ({ router, store, Vue }) => {
  router.beforeEach((to, from, next) => {
    // Now you need to add your authentication logic here, like calling an API endpoint
  })
}

Accessing data from plugins

Sometimes you want to access data that you configure in your app plugin in files where you don’t have access to the root Vue instance.

Fortunately, because app plugins are just normal JavaScript files you can add as many named exports to your app plugin as you want.

Let’s take the example of Axios. Sometimes you want to access your Axios instance inside your JavaScript files, but you can not access the root Vue instance. To solve this you can export the Axios instance in your plugin and import it elsewhere.

Consider the following plugin file for axios:

// axios app plugin file (src/plugins/axios.js)

import axios from 'axios'

// We create our own axios instance and set a custom base URL.
// Note that if we wouldn't set any config here we do not need
// a named export, as we could just `import axios from 'axios'`
const axiosInstance = axios.create({
  baseURL: 'https://api.example.com'
})

export default ({ Vue }) => {
  // for use inside Vue files through this.$axios
  Vue.prototype.$axios = axiosInstance
}

// Here we define a named export
// that we can later use inside .js files:
export { axiosInstance }

In any JavaScript file, you’ll be able to import the axios instance like this.

// we import one of the named exports from src/plugins/axios.js
import { axiosInstance } from 'plugins/axios'

Further reading on syntax: ES6 import, ES6 export.

Special App Plugin: Boot

This is deprecated and will be removed in next version in favor of using PreFetch Feature in src/App.vue and calling redirect(false) to abort app render.

IMPORTANT!
This special app plugin is ignored for SSR builds.

Every Quasar website/app is booted up after plugins have been loaded and executed. The last step is to call new Vue() and attach it to the DOM.

If, for whatever reason, you need to control this final step and decide the specific moment when Vue kicks in, you can create a special Quasar plugin named “boot” (requires Quasar v0.15.6+).

Remember to only use this plugin for eventually calling new Vue(app). Don’t use this for initializing any library you may have – for that, use a regular app plugin.

# we create the boot plugin
$ quasar new plugin boot
 app:new Generated plugin: src/plugins/boot.js +0ms
 app:new Make sure to reference it in quasar.conf.js > plugins +2ms

We then add this plugin to app plugins list in /quasar.conf.js:

module.export = function (ctx) {
  return {
    plugins: [
      'boot'
    ],
    ...
  }
}

IMPORTANT
The name “boot” for your plugin has a special meaning to Quasar CLI. It runs this plugin after all other app initialization has been executed and right before kicking off Vue with new Vue(). By adding this plugin you are responsible for kicking off Vue yourself, as we’ll see next.

We edit our new plugin (/src/plugins/boot.js):

export default ({ app, Vue }) => {
  // do some logic here...

  // ... then, kick off our Quasar website/app:

  /* eslint-disable-next-line no-new */
  new Vue(app)

  // "app" has everything cooked in by Quasar CLI,
  // you don't need to inject it with anything at this point
}

IMPORTANT
Do not forget to have at least one decisional branch where you call new Vue(app) otherwise your app won’t boot and you’ll only see a blank page!