DEV Community: Adam Purdy

To the Stars with Quasar & Firebase - User Profile

Adam Purdy — Thu, 06 Feb 2020 19:01:45 +0000

Introduction
- 1.1 Assumptions
Update User Creation Flow
- 2.1 Setup Cloud Firestore
- 2.2 Create the DB Service
- 2.3 User Model
- 2.4 Update Auth Actions
User Profile with Vuexfire
- 3.1 Why Vuexfire
- 3.2 Vuexfire Installation
- 3.3 Vuexfire Integration
Update User Info
- 4.1 Google Cloud Storage Setup
Unbinding Vuexfire Bindings
Summary
Repository

1. Introduction

This article builds atop of the initial article, Initial Service & Structure, and Email Authentication published in the Quasar-Firebase series. In this post, we're going to build something that most applications that handle users have: a user profile. We'll be using Firebase, Firestore, Vuexfire, and Google's Cloud Storage.

1.1 Assumptions

Before we get started, a few assumptions are in order. In this post, we're going to be building atop of the email authentication article, specifically, state management. Be sure to go over the insights in that post first, or review if needed. Also, one minor addition is we'll be adding Vuexfire bindings in our actions files. Let's update our illustration for consistency.

*Note: This repo already contains a working Firebase API key. In order to set up your own project, you need to delete the "FIREBASE_CONFIG" attributes within the .quasar.env.json file and replace it with your own key from the first article.

If you already created an account on this Firebase API from the email authentication article you'll need to use a different email to set up a new account, as that account doesn't have a user in the users collection as you'll learn in this article.*

Be sure to clone the repo and have the app to follow along with. Navigate to the respective app and run:

$ npm run dev

A final note, this code is for Vue v2 and Quasar v1.

2. Update User Creation Flow

In our email authentication post, we built a form to allow users to register a new account and also log into the application via their credentials that were supplied during registration. That was a good first step, but now we need to expand the experience so we can build our profile off of additional user information.

Also, now that we're going to be working more in-depth with our user, we're going to split up our layouts. One called Basic.vue, and one called User.vue. The user layout will have the logging out functionality and also controlling the opacity of when a user launches their settings modal.

/src/layouts/Basic.vue
/src/layouts/User.vue

Managing users are possible to some extent through the Firebase authentication record, but we need more fidelity for our user.

Let's use Cloud Firestore as our database and create a new record in a users' collection.

2.1 Setup Cloud Firestore

Back in the Firebase console, click on the Database section in the left menu, and then create a Cloud Firestore instance.

Be sure to keep our Firestore instance in Production Mode

Set the location of your server. You can choose whatever works best for your location.

Once you have Firestore set up, it's essential to set some basic security rules for your data. In your Rules tab, enter the following snippet of code:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

If you don't do this, your call to Firestore to save a User record will fail, and our application will prevent the user from moving forward after successful user registration.

2.2 Create the DB Service

Now, a DB service needs to be created. Take a look at the new service:

/src/services/firebase/db.js

Following the pattern from the Email post, this service allows the application to have a reference to Cloud Firestore. Now, add the reference of the db service into our firebaseService object in our index.js file to keep the service under one namespace, firebaseService.

/src/services/firebase/index.js

import * as base from '../services/firebase/base.js'
import * as db from '../services/firebase/db.js'
import * as email from '../services/firebase/email.js'

export default Object.assign({}, base, db, email)

2.3 User Model

Next, create a User model.

/src/models/User.js

/** Class representing a User. */
export default class User {
  /**
   * Create a user.
   * @param {String} id - Place holder for a unique Firebase id.
   * @param {String} backgroundPhoto - A generated URL from Google Storage.
   * @param {String} email - A valid email.
   * @param {String} fullName - The user's full name.
   * @param {String} mobile - the user's mobile number.
   * @param {String} profilePhoto - A generated URL from Google Storage.
  */
  id = ''
  backgroundPhoto = ''
  email = ''
  fullName = ''
  mobile = ''
  profilePhoto = ''

  /**
   * @param  {Object} args - User args
   */
  constructor (args) {
    Object.keys(args).forEach((v, i) => {
      this[v] = args[v]
    })

    return {
      ...this
    }
  }
}

Here is a basic user class that consumes the supplied arguments and returns an object to send to Cloud Firestore.

2.4 Update Auth Actions

Now that there is a user object, the actions file for creating a user can be updated. Assuming email is the authentication method, let's look at the actions file.

/src/store/auth/actions.js

Similar to the actions file from the last post for doing basic email authentication, a few changes are needed. Import the new User class, add a new method, addUserToUsersCollection, and then update our existing method, createNewUser.

import { firestoreAction } from 'vuexfire'
import User from '../../models/User.js'

export const addUserToUsersCollection = async (state, userRef) => {
  const
    { email } = state,
    user = new User({ email })
  return userRef.set(user)
}

export const createNewUser = async function ({ dispatch, commit }, data) {
  const $fb = this.$fb
  const { email, password } = data
  const fbAuthResponse = await $fb.createUserWithEmail(email, password)
  const id = fbAuthResponse.user.uid
  const userRef = $fb.userRef('users', id)
  return addUserToUsersCollection({ email }, userRef)
}

A quick note before we move on.

The import of firestoreAction is seen later in our updated logoutUser action.
Accessing $fb from this is possible because of the use of the function keyword, and because we assigned the service back in our serverConnection file when we imported * for base, email, and db, respectively.

3. User Profile with Vuexfire

Now that we have the user flow updated, we move the user over to the user profile screen upon the successful creation of a new user record in Firestore via our route command via our Auth.vue file.

/src/pages/Auth.vue

onSubmit () {
  const { email, password } = this
  this.$refs.emailAuthenticationForm.validate()
    .then(async success => {
      if (success) {
        this.$q.loading.show({
          message: this.isRegistration
            ? 'Registering your account...'
            : 'Authenticating your account...',
          backgroundColor: 'grey',
          spinner: QSpinnerGears,
          customClass: 'loader'
        })
        try {
          if (this.isRegistration) {
            await this.createNewUser({ email, password })
          } else {
            await this.loginUser({ email, password })
          }
          this.$router.push({ path: '/user/profile' })
        } catch (err) {
          console.error(err)
          this.$q.notify({
            message: `An error as occured: ${err}`,
            color: 'negative'
          })
        } finally {
          this.$q.loading.hide()
        }
      }
    })
}

Here is our profile page.

/src/pages/user/Profile.vue

Before we render the user profile, we want to get the user's data and sync it to our application's store via Vuexfire.

3.1 Why Vuexfire

The Vue core team maintains Vuexfire, so a reasonable assumption here is that their approach to syncing your data against Firestore is well-designed. Vuefire, another similar binding available, is another option. However, over time, as your application grows, and the need for its data to be in your application's store for multiple aspects of the app, it's just easier to keep it in Vuex.

Ideally, we want to go from this:

to this, with as little as code possible.

The Firebase SDK does provide an API to keep your local data in sync with any changes happening in the remote database. However, it is more tedious than you can imagine, and it involves many edge cases. Take a look here at the code needed to perform this operation.

3.2 Vuexfire Installation

Simply install Vuexfire in your app:

yarn add vuexfire
# or
npm install vuexfire

3.3 Vuexfire Integration

Next, integrate the binding package into our store.

/src/store/index.js

import Vue from 'vue'
import Vuex from 'vuex'
import { vuexfireMutations } from 'vuexfire'

import auth from './auth'
import common from './common'
import user from './user'

Vue.use(Vuex)

/*
 * If not building with SSR mode, you can
 * directly export the Store instantiation
 */

export default function (/* { ssrContext } */) {
  const Store = new Vuex.Store({
    modules: {
      auth,
      common,
      user
    },
    mutations: {
      ...vuexfireMutations
    },

    // enable strict mode (adds overhead!)
    // for dev mode only
    strict: process.env.DEV
  })

  return Store
}

Now that we have the binding connected to our store, we will create a method in the store's user module actions file.

/src/store/user/actions.js

export const getCurrentUser = firestoreAction(({ bindFirestoreRef }, id) => {
  return bindFirestoreRef('currentUser', userRef('users', id))
})

Now that we have an access point to get our current user information from our users' collection in Firestore, we'll need to connect this method when Firebase's onAuthStateChanged observer fires when the user becomes authenticated. The key to this is setting our auth state with a uid from Firebase. Then the key can be used anywhere in the app where specific data regarding the user is needed.

Back in our base.js service, look at the handleOnAuthStateChanged method:

/src/services/firebase/base.js

export const handleOnAuthStateChanged = async (store, currentUser) => {
  const initialAuthState = isAuthenticated(store)
  // Save to the store
  store.commit('auth/setAuthState', {
    isAuthenticated: currentUser !== null,
    isReady: true,
    uid: (currentUser ? currentUser.uid : '')
  })

Remember this method is connected to our serverConnection boot file.
/src/boot/serverConnection.js

firebaseService.auth().onAuthStateChanged((currentUser) => {
    firebaseService.handleOnAuthStateChanged(store, currentUser)
  }, (error) => {
    console.error(error)
  })

Once the uid is available via our currentUser from our Firebase auth service, we can attach it to our auth state, and commit the mutation in our
handleOnAuthStateChanged method.

/src/store/auth/mutations.js

export function setAuthState (state, data) {
  state.isAuthenticated = data.isAuthenticated
  state.isReady = data.isReady
  state.uid = data.uid
}

From here, a decision needs to be made when to query Firestore for the user's data. Either here in the handleOnAuthStateChanged, or later once the protected route has passed the route guard checks, and then perform the query and notify the user that the app is fetching data. In this instance, we're going to start the query here in the base service for the user's profile data. Because we've added the uid to the auth state, we can still rely on the uid to be available to any protected route before the page renders. This gives any protected view the key needed to query any data related to the user before rending the view, and after Firebase has supplied the uid from its Auth service.

export const handleOnAuthStateChanged = async (store, currentUser) => {
// ...

// Get & bind the current user
  if (store.state.auth.isAuthenticated) {
    await store.dispatch('user/getCurrentUser', currentUser.uid)
  }

// ...
}

Once the dispatch has completed, the application's currentUser is now bound to our Vuex store.

And that's it! Now, all subsequent writes to our user document in Firestore will automatically be kept in sync in our store module with no additional coding.

5. Updating User Info

At this point, you should have an app that looks like the image below.

Also, if you open up dev tools you will see a console statement outputting the uid from our state that is available to the protected page before rendering from our created Vue lifecycle method in our User.vue file.

Now that we have our data from Firestore bound and in-sync, we're ready to move on to the final piece of our user profile feature, uploading files, and updating user fields.

5.1 Google Cloud Storage Setup

Head back over to the console and click on the storage menu item, and click Get started, and follow the rest of the prompts.

5.2 User actions

Now that the current user called from Firestore is loaded into our store's user module, it's time to upload a photo to Cloud Storage. First, take a look at the custom component based off of Quasar's q-uploader, within the UserSettings component.

/src/pages/user/profile/UserSettings.vue

Per the docs, we can create a custom component to support our Cloud Firestore service modeled after the QUploaderBase mixin.

Have a look at our custom component FBQUploader

Because there are some considerations regarding reusability, multiple file uploads, and other considerations, a separate article highlighting FBQUploader component will be available in the future.

In regards to the user profile content like name, phone number, or anything else for that matter, capture the data and post it to Firestore. Here we can see this in the UserSettings component again. First, we capture the data in our saveUserData method on the form submission.

async saveUserData () {
  const { currentUser, email, fullName, mobile } = this

  this.$q.loading.show({
    message: 'Updating your data, please stand by...',
    customClass: 'text-h3, text-bold'
  })

  try {
    await this.updateUserData({
      id: currentUser.id,
      email,
      fullName,
      mobile
    })
  } catch (err) {
    this.$q.notify({
      message: `Looks like a probelm updating your profile: ${err}`,
      color: 'negative'
    })
  } finally {
    this.$q.loading.hide()
    this.setEditUserDialog(false)
  }
}

Set up some visual language notifying the user that we're doing an update via Quasar's Loading plugin, massage the data, then pass it over to the user action, updateUserData.

export const updateUserData = async function ({ state }, payload) {
  return userRef('users', payload.id).update(payload)
}

Again, once the data is successfully stored in the current user document in the users' collection, your store's user module automatically updates via the Vuexfire binding.

6. Unbinding Vuexfire Bindings

Lastly, when the user logs off we need to unbind our Vuexfire bindings.

export const logoutUser = async function ({ commit }, payload) {
  await firestoreAction(({ unbindFirestoreRef }) => { unbindFirestoreRef('users') })
  commit('user/setCurrentUserData', null, { root: true })
  await this.$fb.logoutUser()
}

7. Summary

Hopefully, this gave you some insight into the process of creating a user record in Firestore from the Firebase authentication step. Also, setting up a common use case of a user profile while combining the functionality of uploading files to Google's Cloud Storage, as well as harnessing the power of Vuexfire bindings to simplify the syncing process between your Vuex store modules and Cloud Firestore.

8. Repository

User Profile Repo

To the Stars with Quasar & Firebase - Email Authentication

Adam Purdy — Thu, 06 Feb 2020 19:00:05 +0000

Introduction
- 1.1 Assumptions
Firebase Console Setup
Form View
- 3.1 Forgot Password
Update Firebase Connection File
Services
- 5.1 Create the Email Service
- 5.2 Update the Base Service
Route Guarding
State/Vuex
- 7.1 Auth State
- 7.2 Auth Actions
Summary
Repository
About Quasar

1. Introduction

This article builds atop of the initial article, Initial Service & Structure published in the Quasar-Firebase series. We're going to look at the most common authentication type in most applications: Email.

1.1 Assumptions

Before we get started, a few assumptions are in order. In this article, we're going to be breaking down the interactions between Firebase services, the serverConnection file, and our base service file. We'll be harnessing our store for state management, so the assumption here is that you have a decent grasp of Vuex and its inner workings. The repository has the complete code base, so that is always a place for a bit of study if you're a little weak in Vuex, as well as keeping Vuex's API docs close at hand.

Implementing Vuex within the context of Quasar can be initially achieved in one of two ways. The first is durining initial project creation via the Quasar CLI prompt:

Or, if you already have a pre-existing application you'll have to set the store up manually. Take a look at the docs for the setup.
You'll have to create the directory structure and use the index.js that is shown in the docs.

Also, keep in mind Quasar offers a nice set of commands via the CLI. One of them being new. You can simply create new modules via the CLI:

$ quasar new store myModule

$ quasar n s myModule

Always be sure to update your store's index file to add the new module.

This is also a good spot to point out that we're going to be adding a new context to our application.

Note: This repo already contains a working Firebase API key. In order to set up your own project, you need to replace your Firebase config values in the .env file and replace it with your own key from the first article.

Be sure to clone the repo and have the app to follow along with. Navigate to the respective app and run:

$ npm run dev

A final note, this code is for Vue v2 and Quasar v1.

2. Firebase Console Setup

To set up email authentication, you first have to enable it in your project in your Firebase console:

In the Firebase console, click on the Authentication menu section.
On the Sign-in method tab, enable the Email/Password sign-in method and click Save.

3. Form View

Now a form for the user to register or login is needed. Create a page called Auth.vue. This page houses both registration and login, as well as a link to the, forgot password page.

$ quasar new page Auth

In Auth.vue. we've created a basic user form for registering and logging in users.

/src/pages/Auth.vue

Notice the use of the Vuex convenience method mapActions.

3.1 Forgot Password

Before we forget, the user needs to reset their password if needed. Using the quasar-cli create a new page:

$ quasar new page ForgotPassword

/src/pages/forgotPassword.vue

Update our routes file, by adding a new route inside of our /auth path:

const routes = [
...

   {
    path: '/auth',
    component: () => import('layouts/MyLayout.vue'),
    children: [
      {
        path: 'forgotPassword',
        name: 'ForgotPassword',
        component: () => import('pages/ForgotPassword.vue')
      },
...
]

4. Update Firebase Connection File

Now that the form is in place, we need to start to augment a few more files. First, let's take a look at our firebaseConnection file:

/src/boot/firebaseConnection.js

import firebaseServices from '../services/firebase'

export default ({ store, Vue }) => {
  const config = process.env.environments.FIREBASE_CONFIG
  firebaseService.fBInit(config)

  // Tell the application what to do when the 
  // authentication state has changed
  firebaseServices.auth().onAuthStateChanged((user) => {
    firebaseServices.handleOnAuthStateChanged(store, user)
  }, (error) => {
    console.error(error)
  })

  Vue.prototype.$fb = firebaseServices
  store.$fb = firebaseServices
}

There are two new statements, one for handling the change of the authentication state, and one for controlling the application's rendering process concerning the route.

Here is where it gets a little tricky, and one of the challenging pieces when dealing with Firebase with Quasar. Just a little tinkering is needed to handle this scenario. The next section will talk specifically about what the mechanics are in our base service to halt the rendering of our application while Firebase is initializing.

5. Services

A couple of additions are needed now that we're going to be authenticating users. One is a new email service, and the other is modifying our base service.

5.1 Create the Email Service

Take a look at the new service: email.

/src/services/firebase/email.js

This service is very straight forward and provides an interface to the Firebase auth methods themselves. Add the reference of the email service into our firebaseService object in our index.js file.

/src/services/firebase/index.js

5.2 Update the Base Service

Next, we have some updates on our base service. As mentioned at the end of section 4, things are a little tricky when working with Firebase and not having access to when the Vue app is being initialized. Looking back at our serverConnection boot file, we can now investigate the two statements in the function.

When Firebase's authentication state changes, we pass a store reference and the user state over to the method, handleOnAuthStateChanged.

/**
 * Handle the auth state of the user and set it in the auth store module.
 * Also sets up redirection if the user loses authentication. The action
 * method will determine where the application routes to.
 * @param  {Object} store - Vuex Store
 * @param  {Object} currentUser - Firebase currentUser
 */
export const handleOnAuthStateChanged = async (store, currentUser) => {
  const initialAuthState = isAuthenticated(store)
  // Save to the store
  store.commit('auth/setAuthState', {
    isAuthenticated: currentUser !== null,
    isReady: true
  })

  // If the user loses authentication route
  // them to the login page
  if (!currentUser && initialAuthState) {
    store.dispatch('auth/routeUserToAuth')
  }
}

First, we want to make an initial authentication check regarding the user with our method, isAuthenticated. Next, we will set an auth object into our auth store module describing the state of the user and the application.

/**
 * @param  {Object} store - Vuex store
 * @return {Boolean} - isAuthenticated
 */
export const isAuthenticated = (store) => {
  return store.state.auth.isAuthenticated
}

Doing this moves the internal state away from the service and in a global location in our store. As an application grows in complexity, relying on state in our store is a cleaner and more consistent way.

A convenience if, in the event a user loses their authentication, we route them immediately to the login screen.

if (!currentUser && initialAuthStateSet) {
  store.dispatch('common/routeUserToAuth')
}

You can test this by going in dev tools and removing the auth token provided by Firebase

Next, we have our ensureAuthIsInitialized method that will be utilized in our route guard coming up in our next section.

/**
 * Async function providing the application time to
 * wait for firebase to initialize and determine if a
 * user is authenticated or not with only a single observable.
 * https://firebase.google.com/docs/reference/js/firebase.auth.Auth#onauthstatechanged
 * @param {Object} store - Vuex store
 * @returns {Promise} - A promise that return firebase.Unsubscribe
 */
export const ensureAuthIsInitialized = async (store) => {
  if (store.state.auth.isReady) return true
  // Create the observer only once on init
  return new Promise((resolve, reject) => {
    // Use a promise to make sure that the router will eventually show the route after the auth is initialized.
    const unsubscribe = firebase.auth().onAuthStateChanged(user => {
      resolve()
      unsubscribe()
    }, () => {
      reject(new Error('Looks like there is a problem with the firebase service. Please try again later'))
    })
  })
}

This is what allows us to stay on a requiresAuth page and not route us back to login. Also, note the use of declaring the observable as an assigned function, and then later calling it. unsubscribe() allows us to resolve the auth service once it's done initializing, and then unsubscribe listening to the observable which is useful when dealing with the navigational guards. If this isn't set up this way, you'll end up with multiple observables in memory every time your user is being routed around your app.

6. Route Guarding

Here we are guarding our routes.

/src/router/index.js

  /**
    Setup the router to be intercepted on each route.
    This allows the application to halt rendering until
    Firebase is finished with its initialization process,
    and handle the user accordingly
  **/
  Router.beforeEach(async (to, from, next) => {
    const { ensureAuthIsInitialized, isAuthenticated } = firebaseServices
    try {
      // Force the app to wait until Firebase has
      // finished its initialization, and handle the
      // authentication state of the user properly
      await ensureAuthIsInitialized(store)
      if (to.matched.some(record => record.meta.requiresAuth)) {
        if (isAuthenticated(store)) {
          next()
        } else {
          next('/auth/login')
        }
      } else if ((to.path === '/auth/register' && isAuthenticated(store)) ||
        (to.path === '/auth/login' && isAuthenticated(store))) {
        next('/user')
      } else {
        next()
      }
    } catch (err) {
      Notify.create({
        message: `${err}`,
        color: 'negative'
      })
    }
  })

The route guard can grow and get more complicated as your needs change. Still, the most important thing here is to halt the application from routing until the Firebase service is done initializing by calling ensureAuthIsInitialized.

Note the check if the user is authenticated and trying to navigate to either the login or registration route. The application will not let the user go to either one of those routes and move them directly to the user page for a better user experience.

7 State/Vuex

Since Vuex is available from the initial project creation, we place the authenticated state in our store back in the base service file in the handleOnAuthStateChanged method.

7.1 Auth State /src/store/auth/state.js

export default {
  isAuthenticated: false,
  isReady: false
}

7.2 Auth Actions

Earlier we mentioned the use of mapActions in our Auth.vue page. Take a look at the methods that can be available via mapActions.

/src/store/auth/actions.js

Also, be sure to take a look at our mutation for our auth store that we are using in our base service during our handleOnAuthStateChanged.

/src/store/auth/mutations.js

8. Summary

Building from our first article, we now have a starting point in which we can successfully create and log in users against the Firebase SDK, as well as reset their password. After a user is successfully authenticated, they are routed to a protected route that is only accessible once a user is authenticated correctly. We've also augmented our base service to allow the Firebase SDK to finish it's initialization process so that we will not route a user back to the login screen if they are already correctly authenticated upon browser refresh.

9. Repository

Quasar-Firebase Repo: Email Authentication

Up next: User Profile

10. About Quasar

Interested in Quasar? Here are some more tips and information:

More info: https://quasar.dev
GitHub: https://github.com/quasarframework/quasar
Newsletter: https://quasar.dev/newsletter
Getting Started: https://quasar.dev/start
Chat Server: https://chat.quasar.dev/
Forum: https://forum.quasar.dev/
Twitter: https://twitter.com/quasarframework

To the Stars with Quasar & Firebase - Initial Service & Structure

Adam Purdy — Thu, 06 Feb 2020 18:59:17 +0000

Introduction
- 1.1 Assumptions
Installation
Firebase Configuration and Application Environment
Structure
Base Service
Summary
Repository
About Quasar

1. Introduction

Firebase is Google's mobile platform that helps you quickly develop high-quality apps and grow your business. It helps you by allowing you to build apps fast without managing infrastructure and gives you functionality like analytics, databases, messaging, and crash reporting so you can move quickly and focus on your users.

It was initially created as a startup in 2011 and was publicly available in 2012. In October 2014, Google acquired Firebase, which evolved into a platform that has 18+ products and is currently being used by 1.5 million apps as of October 2018. source - Wikipedia.

This article intends to be a base source for the articles that follows it, as the nature of this series is to inform the developer on how to set up Firebase within the Quasar Framework. While this information intends to be a foundational step for getting started with Firebase inside of Quasar, this is just the surface and is highly advisable to always consult the Firebase documentation initially for guidance.

1.1 Assumptions

Before we get started, a few assumptions are in order. Unless otherwise specified in the posts to follow in this series, a presumption of the Quasar project consists of using: Stylus, auto importing of components, and using the features of ESLint and Vuex.

Also, please be sure to keep your quasar-cli as current as possible.

$ npm i -g @quasar/cli@latest

Also, if you're here you've done two things:

Chosen the Quasar Framework to be your Vuejs front-end component framework
Chosen Firebase at the minimum to handle your Quasar application's authentication... maybe more

And finally, if something is not directly mentioned moving forward, it's more than likely to be covered in either the Quasar docs, or the Firebase docs. An effort will be made to keep a watchful eye on concepts that specifically pertain to the integration of Firebase within the Quasar Framework. Still, if something is missing, there is also the #firebase channel on the Quasar Discord server. A final note, this code is for Vue v2 and Quasar v1.

2. Installation

If you're new to Firebase, you must create a Firebase account with a Google identity and create a project in the console.

Perform steps 1 & 2 with the Firebase setup instructions.

Once you've gotten your account and project setup in Firebase, it's time to install dependencies in your Quasar app and start the configuration process.

Install Firebase to your Quasar application, preferably via yarn package manager:

$ yarn add firebase
# or 
$ npm install firebase

A configuration object is needed to configure the Firebase SDK for initialization from the Firebase console.

You can get access to your Firebase config object at any time by:

Sign in to Firebase, then open your project.
Click the Settings icon, then select Project settings.
In the Your apps card, select the nickname of the app for which you need a config object.
Select Config from the Firebase SDK snippet pane.
Copy the config object snippet, then add it to your app's HTML.

In your console run: $ firebase apps:sdkconfig web

3. Firebase Configuration and Application Environment

Assuming you are developing an app that will live in a production environment, Firebase recommends creating separate projects in the Firebase console. One for production, one for dev, and even a public testing endpoint if you'd like. The point here is to keep production data safe from development.

The use of environment variables is used during Quasar's build process to identify which Firebase and other configuration information are needed given the desired build. Earlier in this article's history, the use of Qenv was used but has since become deprecated. Dotenv is now used to set up the application's environment variables.

yarn add -D dotenv
# or
npm install -D dotenv

Create a .env file per the instructions on their repository. This file will house all environment options based on your application needs. Following dotenv's suggestion, do not split up your .env files per environment. Here's what your .env file could look like.

Note - For Windows Users - You'll need to install an additional package called cross-env, and update your package.json script.

{

  "scripts": {
    "dev:win": "cross-env QENV=DEV quasar dev"
  }

}

/.env

# DEVELOPMENT FIREBASE CONFIG
DEV_API_KEY=######
DEV_AUTH_DOMAIN=######
DEV_DATA_BASE_URL=######
DEV_PROJECT_ID=######
DEV_STORAGE_BUCKET=######
DEV_MESSAGING_SENDER_ID=######
DEV_APP_ID=######
DEV_API_ENDPOINT=######

# STAGING FIREBASE CONFIG
STAGE_API_KEY=######
...

Take notice of the prefix, 'DEV', in the variable names. This will be used in our script to set our QENV variable.

Create or update your build script in your package.json file.

/package.json

{
  ...
  "scripts": {
    "dev": "QENV=DEV quasar dev",
    "lint": "eslint --ext .js,.vue src",
    "test": "echo \"No test specified\" && exit 0"
   },
  ...
}

Per the Quasar documentation, we need to add our parsed values from our .env file. We also need to add our environment variables set during our build script to allow our config file to determine which config object to use.

/quasar.conf.js

const enviromentConfiguration = require('./src/utils/environmentConfig.js')
module.exports = function (ctx) {
  return {
    ...
    env: {
      QENV: enviromentConfiguration(process.env.QENV)
    }
    ...

Finally, create a utils folder and create an enviromentConfig.js file.
This file takes our environment variable set in our build script that gets passed over from our quasar.config.js and uses it to determine which configuration will initialize the Firebase applications. Utilizing template string literals and aligning your environment variable names with the prefixes in your .env file.

/src/utils/environmentConfig.js

const ENV = require('dotenv').config().parsed
/*
  Use an environment variable set in package.json scripts to determine
  the applications runtime environment. Add more switch cases as
  need for additional environments. Remember, Firebase recomends supporting
  separate Firebase project for different application environments: httpsq://firebase.google.com/docs/projects/multiprojects#support_different_environments
*/

module.exports = (QENV) => {
  if (!['DEV', 'STAGE', 'PROD'].includes(QENV)) {
    throw Error('Unknonw or not supplied environment variable')
  }
  return {
    FIREBASE_CONFIG: {
      apiKey: ENV[`${QENV}_API_KEY`],
      authDomain: ENV[`${QENV}_AUTH_DOMAIN`],
      databaseURL: ENV[`${QENV}_DATA_BASE_URL`],
      projectId: ENV[`${QENV}_PROJECT_ID`],
      storageBucket: ENV[`${QENV}_STORAGE_BUCKET`],
      messagingSenderId: ENV[`${QENV}_MESSAGING_SENDER_ID`],
      appId: ENV[`${QENV}_APP_ID`]
    }
  }
}

4. Structure

Before we dive into setting up the code, let's take a second to illustrate and discuss a bit of the opinionated direction we'll be taking. The fact that we can simply import Firebase and all its needed services into a single boot file, or just import the service directly in our Vue file and build our functionality as needed is definitely an option moving forward. But, the attempt here in these next few articles is to guide the development into more of a separated and maintainable production approach. We want to separate our services by a single namespace, firebaseServices, and also have each contextual service in a file. We can lend our structure to small and manageable files, as well as writing tests.

We'll revisit this again as we add more contexts to the application.

The following code snippet is meant to highlight the initial approach of setting up your application by separating your server connection and the actual service itself. The next bits are not intended to set up any real functionality, but highlight the first necessary pieces of the application structure. A typical Quasar app structure is here.

5. Base Service

The first place to get Firebase into Quasar is starting in a boot file. Create a boot file, then add its name to the boot array in the quasar.conf.js. Be sure to read up on Quasar’s boot files here. It is a great review, and also the first place to start when debugging Firebase issues.

$ quasar new boot firebaseConnection

/quasar.config.json

boot: [
  'firebaseConnection'
],

Our boot file is not the Firebase service itself, but a point in which to bring in the Firebase service, in case you need or want to switch out your backend to another cloud provider or traditional backend API interface.

/src/boot/firebaseConnection.js

import firebaseServices from '../services/firebase'

export default async () => {
  const app = firebaseServices.fBInit(process.env.QENV.FIREBASE_CONFIG)

  // Validation that our service structure is working
  // with an initialize Firebase application and auth instance.
  console.log('Firebase App Instantiation:', app)
  console.log('Firebase Auth Module:', firebaseServices.auth())
}

Calling the fBInit(process.env.QENV.FIREBASE_CONFIG) method is just a validation that the service structure is working, but does not guarantee that the initialization happened with a valid API key.

Create a new directory in our application structure called services, and put the base service inside.

/src/services/firebase/base.js

Throughout the next couple of articles, there will be a separation of each firebase service in relation to its context. These service file will be then be pulled into the /src/services/firebase/index.js file where we can have a top-level firebaseServices namespace via Object.assign().

Have a look here: /src/services/firebase

import firebase from 'firebase/app'
import 'firebase/auth'

/**
 * Returns Firebase's auth service
 * https://firebase.google.com/docs/reference/js/firebase.auth.html#callable
 * @returns {Auth} - The Firebase Auth service interface
 */
export const auth = () => {
  return firebase.auth()
}

/**
 * Convenience method to initialize firebase app
 * https://firebase.google.com/docs/reference/js/firebase?authuser=1#initializeapp
 * @param  {Object} config - FIREBASE_CONFIG during the build process
 * @returns {App} - Creates and initializes a Firebase app instance.
 */
export const fBInit = (config) => {
  return firebase.initializeApp(config)
}

First, we import our Firebase SDK and separate the imports per Firebase product. Be sure to check out the complete list of products, click on the expansion item for "Available Firebase JS SDKs (using bundler with modules)". Likewise, we could import the entire SDK, but you can shave off KB's by importing the products separately. Also, keep in mind if you only import just the app portion of the firebase and NOT the other products you'll end up getting undefined errors when trying to work with those products.

The fBInit method allows Firebase to register a project that was created in the Firebase console.

Run the app:

$ yarn dev

Remember if you're running Windows

$ yarn dev:win

Once the app is finished building, it will launch to http://localhost:8080/#/.

If you have successfully instantiated the Firebase service you will see this:

Otherwise, your application will fail to initialize and you will have a Quasar boot error and a Firebase error message stating you have an invalid key.

The Firebase API key doesn't get validated until an authentication method is executed. This will be highlighted in the Email Authentication article.

6. Summary

Here is the start of our integration between Firebase into the Quasar Framework and highlights getting a project created in the Firebase console, setting up the basic structure for our firebaseConnection and our base Firebase service files. This base service is ready for future application needs. It will serve as a starting point for any Firebase type of authentication or any of the other services that Firebase offers.

7. Repository

Quasar-Firebase Repo: Base Service

Up next: Email Authentication

8. About Quasar

Interested in Quasar? Here are some more tips and information:

DEV Community: Adam Purdy

To the Stars with Quasar & Firebase - User Profile

Table Of Contents

1. Introduction

2. Update User Creation Flow

3. User Profile with Vuexfire

5. Updating User Info

6. Unbinding Vuexfire Bindings

7. Summary

8. Repository

To the Stars with Quasar & Firebase - Email Authentication

Table Of Contents

1. Introduction

2. Firebase Console Setup

3. Form View

4. Update Firebase Connection File

5. Services

6. Route Guarding

7 State/Vuex

8. Summary

9. Repository

10. About Quasar

To the Stars with Quasar & Firebase - Initial Service & Structure

Table Of Contents

1. Introduction

2. Installation

3. Firebase Configuration and Application Environment

4. Structure

5. Base Service

6. Summary

7. Repository

8. About Quasar