VueJS

Going Serverless with Vue.js and Firebase Cloud Functions

Published Mar 11, 2020

Updated Feb 14, 2023

10 min read

Fire the base of Vue.js! - 3 Part Series

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Welcome to a new episode of the Fire the base of Vue.js! series.

In this episode, I will integrate our Vue.js Notes Writer App with a serverless backend- specifically, the Firebase Cloud Functions.

If you haven’t read the other parts of this series, I highly recommend you do so before starting here.

Vue the Mirage from this angle! Storing your notes in the Cloud Firestore with Vue.js Firebase for user authentication in Vue.js

To follow up on the demo part of this article, you can use this GitHub source code repo as a starting point.

Firebase Cloud Functions, the concept

Cloud Functions are part of the Google Cloud Platform. You use them to write and deploy code that can respond to events coming from Google Cloud Services, including, but not limited to, the Firebase family of products.

With Cloud Functions, you piece together your application using different products. For instance, a user creates a new Document inside Firestore via the Web app. Consequently, a Cloud Function triggers, and responds to the event of Document Creation. The logic of a Cloud Function depends solely on the business scenario you are implementing.

Not only do they let you connect Google Cloud Services together, but they also allow you to create your own set of REST APIs to consume inside your Web or Mobile app.

The Cloud Functions project is a wrapper on top of the Google Cloud project. However, it was made easier for developers to configure and use.

The two major benefits Cloud Functions offer: Centralize your code in a safe way on Google Cloud Servers. Firebase Cloud Functions run on Google Servers. All of your apps, whether they be Web, Mobile or Desktop, can access and use them. Code security. It is better to save the access codes and keys for Firebase Services on the backend (on the Google Servers) rather than exposing them inside the client-side app code.

Cloud Functions are best used to: Trigger code in response to events coming from Firebase products. Perform writes to the Realtime Database and Firestore Upload to your Cloud Storage buckets. Respond to new accounts created in Firebase Authentication. Handle incoming HTTPs Request.

Firebase supports two flavors of Cloud Functions: HTTPs triggered Functions Background triggered Functions

Unlike Google Cloud Functions, Firebase Cloud Functions support only JavaScript/TypeScript with Node.js. The team is working on including more programming languages. Until then, let’s enjoy JavaScript!

HTTPs Triggered Cloud Functions

Let’s explore the anatomy of Cloud Functions for HTTPs triggers.

Start by ensuring Node.js version >= 8.13.0 is installed on your machine.

Next, install the Firebase CLI globally on your computer by running the following command:

npm install -g firebase-tools

Create a Firebase project by running the commands:

mkdir firebase-functions-http
cd firebase-functions-http

The next step is to log into Firebase services to connect the new project. Issue this:

firebase login

That command opens up a new tab in your default browser to ask for some permissions needed by the Firebase account.

Let’s initialize the Firebase project by running the following command:

firebase init

This command guides you through a command-line wizard to choose the Firebase features you want to add to the project.

For our case, let’s pick the following:

Which Firebase CLI features do you want to set up for this folder? Functions

What language would you like to use to write Cloud Functions? JavaScript

Do you want to use ESLint to catch probable bugs and enforce style? Yes

Do you want to install dependencies with npm now? Yes

That’s all!

Let the Firebase CLI do the project scaffolding, and get the project files ready.

The command scaffolds a Node.js project, and stores the Cloud Function related code inside the /functions folder.

The /functions.package.json lists all the dependencies needed by the Cloud Function. The most important dependencies are:

"dependencies": {
    "firebase-admin": "^8.9.2",
    "firebase-functions": "^3.3.0"
  },

Let’s make sure we have the latest bits of these packages by running the following command:

npm install firebase-admin@latest firebase-functions@latest

The /functions/index.js file contains the Cloud Function code.

const functions = require('firebase-functions');

exports.helloWorld = functions.https.onRequest((request, response) => {
    response.send("Hello from Firebase!");
});

The index.js file is a typical Node.js module file that exports a single Cloud Function named helloWorld. You can export more functions as needed.

The module starts by requiring the firebase-functions library. This library allows you to create Cloud Functions for HTTPs triggers. It exposes the onRequest() function. This function expects two parameters, the Request and Response objects. The callback function is required to return a Promise by issuing a call for response.send() function.

The popular Express.js module for Node.js is behind a Cloud Function for HTTPs trigger. When you deploy a Cloud Function on Firebase, it creates an Express.js app behind the scenes. This app will listen to any HTTPs request for /helloWorld, prepare a Request and Response object, and will call through your Cloud Function, passing it to the two objects.

You can include any code inside the onRequest() callback function like you do when writing Express.js apps.

I highly recommend reading this great article on dissecting the Express.js module, and learning how it’s made under the hood. Understanding how Express.js Works

Let’s run this Cloud Function locally by issuing the following command:

firebase serve --only functions

The command starts the Firebase Cloud Functions emulator to allow you to run the function locally, without the need to deploy it to Firebase servers.

✔  functions: Using node@10 from host.
✔  functions: Emulator started at http://localhost:5000
i  functions: Watching "/.../firebase-functions-http/functions" for Cloud Functions...
✔  functions[helloWorld]: http function initialized (http://localhost:5000/firebase-functions-http/us-central1/helloWorld).

Copy & Paste the Function URL into your browser, and you will see a plain text response of Hello from Firebase!.

To deploy the Cloud Function to Firebase platform, run the following command:

firebase deploy --only functions

Cloud Functions for HTTPs triggers can only be run under HTTPS and not HTTP.

Inside a Cloud Function for HTTPs trigger, you can call any other third party service. You can query the Firestore database, and return data from it, for instance.

You can always refer to the amazing Firebase Cloud Functions documentation to study the full range of capabilities supported by them.

Background Triggered Cloud Functions

The Background Triggered functions is the other type of functions offered and supported by Firebase.

Each and every product in the Firebase family exposes a set of events that are triggered upon a certain action.

For example, when a new Document is created inside Firestore, the OnCreate event is triggered.

Another example is when a new User is created in the Firebase Authentication module, the onCreate event is triggered.

exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => {
  // ...
});

The functions object gives access to all supported types of Cloud Functions. This includes both the HTTPs, and Background triggered ones.

The example above gives you access to the user that was created. Then, you might decide to send the user an email, or push down a notification to the app. The sky's the limit!!

The Firebase Cloud Functions supports all Firebase products, and gives the developer the chance to handle many of the events triggered by them.

For a full list of all the supported background triggered functions, have a look at Trigger background functions

The Firebase Cloud Functions documentation is complete, and is extremely helpful to learning all the ins and outs. Therefore, without any further ado, let’s jump into our Notes App Writer, and add a new background triggered Cloud Function.

Demo

Clone the Notes App Writer at the add-auth branch. This is the branch we worked on in the previous article while authenticating users in the app.

Clone the app

Run the following command to clone the branch:

git clone --single-branch --branch add-auth git@github.com:bhaidar/notes-writer.git

Make sure to install all NPM packages by running this command:

npm install

Add support for Firebase Cloud Functions

If you haven’t logged into Firebase before, it’s time to do it by running this command:

firebase login

Once you log in, let’s initialize the Firebase services once again to include Functions this time.

firebase init

Follow the same steps mentioned in the HTTPs Triggered Cloud Functions section.

You will notice a new folder created under the root folder of the project named functions. This folder, as you know by now, holds all the source code for the Cloud Functions in your project.

It’s always important, whenever you add support for Cloud Functions in your project, to update the Firebase NPM packages by running the following command:

npm install firebase-admin@latest firebase-functions@latest

Use Environment Variables to store configuration settings

Let’s revisit the /firebaseConfig.js file. This file holds the Firebase connection settings as provided by Firebase Console.

I will make use of a hidden gem in Vue.js CLI v3, which allows you to use Environment Variables in your application to store such configuration settings. In fact, this is the recommended way of storing configuration settings in a Vue.js app rather than putting them in plain JSON or JavaScript files.

The CLI documentation referenced above gives you all the details about the Environment Variable files to use in your app. For now, create a new .env file at the root of the project, and paste the following keys:

VUE_APP_API_KEY=
VUE_APP_KEY_AUTH_DOMAIN=
VUE_APP_KEY_DATABASE_URL=
VUE_APP_PROJECT_ID=
VUE_APP_STORAGE_BUCKET=
VUE_APP_MESSAGING_SENDER_ID=
VUE_APP_ID=

Grab the actual keys from the Firebase Console and place them after they == sign on each and every line.

For instance,

VUE_APP_PROJECT_ID=notes-writer-f1e85

Going back to the firebaseConfig.js file, replace its content with the following:

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

// firebase init
const config = {
  apiKey: process.env.VUE_APP_API_KEY,
  authDomain: process.env.VUE_APP_KEY_AUTH_DOMAIN,
  databaseURL: process.env.VUE_APP_KEY_DATABASE_URL,
  projectId: process.env.VUE_APP_PROJECT_ID,
  storageBucket: process.env.VUE_APP_STORAGE_BUCKET,
  messagingSenderId: process.env.VUE_APP_MESSAGING_SENDER_ID,
  appId: process.env.VUE_APP_ID
}

firebase.initializeApp(config)

// firebase db
const db = firebase.firestore()

// firebase auth
const auth = firebase.auth()

// firebase collections
const notesCollection = db.collection('notes')

export {
  auth,
  db,
  firebase,
  notesCollection
}

Implement the Cloud Function

Let’s visit the functions/index.js file, and start implementing our function logic.

The purpose of this function is to listen to any new Note Document created inside Firestore, grab its details, and send them in an email.

Replace the contents of the index.js file with the following:

const functions = require('firebase-functions')
const admin = require('firebase-admin')

admin.initializeApp()

exports.onNewNoteCreated =
  functions.firestore.document('notes/{notesId}').onCreate((snap, context) => {
    const { body } = snap.data()
    const { params: { notesId } } = context

    console.log(context)
    console.log(body)
    console.log(notesId)

    return Promise.resolve(true)
  })

The JavaScript module imports the Firebase Functions Admin SDK libraries.

The Firebase Admin SDK lets you interact with Firebase from privileged environments to perform several actions.

The module exposes a single Cloud Function named onNewNoteCreated. This function subscribes to the OnCreate() event handler to run once a new Firestore Document is created.

The onCreate() event handler accepts as callback function having two parameters: DocumentSnapshot. EventContext.

The former parameter lets you access the content of the Document created, while the latter lets you access the context in which the event has occurred.

The next line extracts the body property of the Notes Document. Then, the code extracts the notesId from the EventContext parameter.

The variables are then logged to the Cloud Functions Logs database. From my experience, the Cloud Functions Logs is the best tool to debug and test your functions!

Finally, the function returns a resolved Promise. I will further discuss the concept of returning Promises from Cloud Functions in the next section of this article.

Let’s run the Cloud Function locally first by using the Firebase Functions Shell.

Run the following command:

firebase functions:shell
``

You use the Functions Shell to test your functions interactively. You can read more about it by following this link: [Test functions interactively](https://firebase.google.com/docs/functions/local-shell)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yb0oljjnidl4ix4es15z.png)

Behind the scenes, the Shell loads the Functions emulator, and lists them all for reference.

To execute a single function, simply run the following on the **firebase** command line:

```bash
onNewNoteCreated({ body: "Hello Firebase Functions!" }, { params: { notesId: "note-#001" }})

Hit Enter!

The output is as follows:


'Successfully invoked function.'

firebase > >  

{ eventId: 'c6f8eec2-e7e0-463e-9966-c8c8b0a25505',
>    timestamp: '2020-02-15T08:12:02.088Z',
>    eventType: 'google.firestore.document.create',
>    resource:
>     { service: 'firestore.googleapis.com',
>       name:
>        'projects/notes-writer-f1s85/databases/(default)/documents/notes/note-#001' },
>    params: { notesId: 'note-#001' } }

>  Hello Firebase Functions!

>  note-#001

The first block of text represents the ExecutionContext object. It gives you details about the current event, and its context. For instance, the event type is a google.firestore.document.create. The full path of the new document shows inside the resource property. Finally, your Cloud Function has access to the params property that includes the ID of the new Notes Document.

The second block of text prints the body of the new Note Document.

Finally, the third block of text prints the notesId grabbed from the params property on the ExecutionContext object.

Send an email inside the Cloud Function

Let’s make our Cloud Function more useful! You have many options to do so with the Firebase family of products.

For instance, we could send the new Note as a Push Notification using the Firebase Cloud Messaging product. However, I would rather not introduce more than one Firebase product in one article.

Let’s, instead, send the contents of the new Note Document using an email. For that, we need to install an additional NPM package to allow us to send the email.

Make sure you are inside the /functions folder, run the following command:

npm install nodemailer

We are going to use the nodemailer Node.js module to send out the emails.

Replace the contents of the /functions/index.js with the following code:

const functions = require('firebase-functions')
const admin = require('firebase-admin')
const nodemailer = require('nodemailer')

admin.initializeApp()

var transporter = nodemailer.createTransport({
  host: 'smtp.gmail.com',
  port: 465,
  secure: true,
  auth: {
    user: '',
    pass: ''
  }
})

exports.onNewNoteCreated =
  functions.firestore.document('notes/{notesId}').onCreate((snap, context) => {
    const { body } = snap.data()
    const { params: { notesId } } = context

    console.log(body)
    console.log(notesId)

    const mailOptions = {
      from: '',
      to: '',
      subject: 'A new note is created',
      html: `
        <h1>New Note</h1>
        <p>A new note is created with the following details:</p>
        <p>
          Note Id: <br />
          ${notesId}
        </p>
        <p>
          Note Body: <br />
          ${body}
        </p>`
    }

    return transporter.sendMail(mailOptions)
      .then(() => console.log('Email Sent!'))
      .catch(error => console.error(error))
  })

Start by importing the nodemailer library.

Then, create a nodemailer transporter. The transporter is the object responsible for sending out the email. Nodemailer module supports SMTP based transport and other non-SMTP based transport. I will keep it simple, and use an SMTP transport for this Cloud Function.

For this to work, you need to create a new Nodemailer Transport using an SMTP account. I will be using the GMAIL SMTP account details. This is OK for testing locally but never used for production. Other options to use for production are: GMAIL OAUTH 2 and SMTP account you get from your hosting company.

Replace the user and pass fields with a real Gmail account.

Inside the Cloud Function, prepare a mailOptions object containing all the details of the email to send. Make sure to include the from, to, and the rest of the fields.

Finally, send the email by returning the transporter.sendMail(mailOptions) function call. This function returns a Promise.

That’s it! You can follow the steps above to test the function locally, using the Functions Shell.

Let’s deploy the Cloud Function to Firebase, and start receiving emails!

firebase deploy --only functions

The command above deploys all the Cloud Functions in your current app.

Now, whenever you create a new Note inside the app, the onNewNoteCreated() Cloud Function is triggered and eventually you receive an email similar to the one below:

Cloud Function Execution Process

Firebase internally manages the Server, and all the resources needed to deploy and run a Cloud Function. When a Cloud Function finishes executing, it needs to cleanup the resources used by the function.

How can Firebase tell or decide that now is the correct time to cleanup the resources, and that the Cloud Function has finished executing?

This task is certainly more complicated! Why?

Most of the Cloud Functions’ code you will be writing will interact with other Firebase SDKs, or even third party SDKs. This type of communication happens asynchronously.

A Cloud Function executes code, and returns immediately. However, there might be some kind of work that’s pending in the background, asynchronously. Therefore, Firebase cannot just run the function, and cleanup all the resources. It must wait until the function completely finishes running, and then do so.

For that reason, all of the Firebase SDKs support JavaScript Promises. What’s a JavaScript Promise?

A Promise represents some async work that should eventually complete! When work tracked by a Promise is still executing, the Promise is in a pending state. If the work completes successfully, the Promise is said to be fulfilled. If there is an error, the Promise becomes rejected.

These are the only states a Promise can go through. Once fulfilled or rejected, a Promise cannot go back to any other state.

For instance, the Firebase Admin SDK returns promises when your code: Reads or writes from a database. Interacts with files in the Cloud Storage. Sends a notification with Cloud Messaging.

Therefore, when dealing with Background-triggered Cloud Functions, it’s so important to just return the Firebase SDK API call you perform inside the Cloud Function. The Cloud Function Runner now has access to a Promise. As long as the Promise is in the pending state, it will wait, and will take no action. Once the Promise is fulfilled or rejected, it can safely remove all resources, and do the cleanup.

For an HTTPs-triggered Cloud Function, always make sure you return response.send() as the last line of the code. The Cloud Functions Runner will terminate and cleanup an HTTPs-triggered function only when the function returns a response to the client.

In this article, I’ve shown how to integrate and use a third party library, the Nodemailer. What we have implemented is a Background triggered function, hence we need to return a Promise at the end of the function. How are we doing so?

return transporter.sendMail(mailOptions)
      .then(() => console.log('Email Sent!'))
      .catch(error => console.error(error))
  })

The sendMail() function sends an email, and returns a Promise. In our case, we are sending an Email Sent! message to the logs when the Promise is fulfilled. Also, we are logging any errors when the Promise is rejected. At the same time, we are returning the sendMail() Promise to let the Cloud Functions Runner use that Promise to clean up the resources for this function. This only works because JavaScript Promises are chainnable!

Conclusion

For now, this will be the last episode on Fire the base of Vue.js! series.

Firebase is such a big topic, and requires many articles to cover it all. The team at Firebase did a great job at providing decent documentation. Still, I believe, working with the Firebase SDKs will give you experience and knowledge that theory cannot.

In the future, I might add episodes to this series. However, in the coming two weeks, I will start a new series on Vue.js development. Stay tuned!

Happy Vueing!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Bilal Haidar
Author, Developer, and Mentor: Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB | A Complete Guide to VueJS
@bhaidar @bhaidar

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools

In the ever-evolving world of web development, Nuxt.js has taken a monumental leap with the launch of Nuxt DevTools v1.0. More than just a set of tools, it's a game-changer—a faithful companion for developers. This groundbreaking release, available for all Nuxt projects and being defaulted from Nuxt v3.8 onwards, marks the beginning of a new era in developer tools. It's designed to simplify our development journey, offering unparalleled transparency, performance, and ease of use. Join me as we explore how Nuxt DevTools v1.0 is set to revolutionize our workflow, making development faster and more efficient than ever. What makes Nuxt DevTools so unique? Alright, let's start delving into the features that make this tool so amazing and unique. There are a lot, so buckle up! In-App DevTools The first thing that caught my attention is that breaking away from traditional browser extensions, Nuxt DevTools v1.0 is seamlessly integrated within your Nuxt app. This ensures universal compatibility across browsers and devices, offering a more stable and consistent development experience. This setup also means the tools are readily available in the app, making your work more efficient. It's a smart move from the usual browser extensions, making it a notable highlight. To use it you just need to press Shift + Option + D (macOS) or Shift + Alt + D (Windows): With simple keystrokes, the Nuxt DevTools v1.0 springs to life directly within your app, ready for action. This integration eliminates the need to toggle between windows or panels, keeping your workflow streamlined and focused. The tools are not only easily accessible but also intelligently designed to enhance your productivity. Pages, Components, and Componsables View The Pages, Components, and Composables View in Nuxt DevTools v1.0 are a clear roadmap for your app. They help you understand how your app is built by simply showing its structure. It's like having a map that makes sense of your app's layout, making the complex parts of your code easier to understand. This is really helpful for new developers learning about the app and experienced developers working on big projects. Pages View lists all your app's pages, making it easier to move around and see how your site is structured. What's impressive is the live update capability. As you explore the DevTools, you can see the changes happening in real-time, giving you instant feedback on your app's behavior. Components View is like a detailed map of all the parts (components) your app uses, showing you how they connect and depend on each other. This helps you keep everything organized, especially in big projects. You can inspect components, change layouts, see their references, and filter them. By showcasing all the auto-imported composables, Nuxt DevTools provides a clear overview of the composables in use, including their source files. This feature brings much-needed clarity to managing composables within large projects. You can also see short descriptions and documentation links in some of them. Together, these features give you a clear picture of your app's layout and workings, simplifying navigation and management. Modules and Static Assets Management This aspect of the DevTools revolutionizes module management. It displays all registered modules, documentation, and repository links, making it easy to discover and install new modules from the community! This makes managing and expanding your app's capabilities more straightforward than ever. On the other hand, handling static assets like images and videos becomes a breeze. The tool allows you to preview and integrate these assets effortlessly within the DevTools environment. These features significantly enhance the ease and efficiency of managing your app's dynamic and static elements. The Runtime Config and Payload Editor The Runtime Config and Payload Editor in Nuxt DevTools make working with your app's settings and data straightforward. The Runtime Config lets you play with different configuration settings in real time, like adjusting settings on the fly and seeing the effects immediately. This is great for fine-tuning your app without guesswork. The Payload Editor is all about managing the data your app handles, especially data passed from server to client. It's like having a direct view and control over the data your app uses and displays. This tool is handy for seeing how changes in data impact your app, making it easier to understand and debug data-related issues. Open Graph Preview The Open Graph Preview in Nuxt DevTools is a feature I find incredibly handy and a real time-saver. It lets you see how your app will appear when shared on social media platforms. This tool is crucial for SEO and social media presence, as it previews the Open Graph tags (like images and descriptions) used when your app is shared. No more deploying first to check if everything looks right – you can now tweak and get instant feedback within the DevTools. This feature not only streamlines the process of optimizing for social media but also ensures your app makes the best possible first impression online. Timeline The Timeline feature in Nuxt DevTools is another standout tool. It lets you track when and how each part of your app (like composables) is called. This is different from typical performance tools because it focuses on the high-level aspects of your app, like navigation events and composable calls, giving you a more practical view of your app's operation. It's particularly useful for understanding the sequence and impact of events and actions in your app, making it easier to spot issues and optimize performance. This timeline view brings a new level of clarity to monitoring your app's behavior in real-time. Production Build Analyzer The Production Build Analyzer feature in Nuxt DevTools v1.0 is like a health check for your app. It looks at your app's final build and shows you how to make it better and faster. Think of it as a doctor for your app, pointing out areas that need improvement and helping you optimize performance. API Playground The API Playground in Nuxt DevTools v1.0 is like a sandbox where you can play and experiment with your app's APIs. It's a space where you can easily test and try out different things without affecting your main app. This makes it a great tool for trying out new ideas or checking how changes might work. Some other cool features Another amazing aspect of Nuxt DevTools is the embedded full-featured VS Code. It's like having your favorite code editor inside the DevTools, with all its powerful features and extensions. It's incredibly convenient for making quick edits or tweaks to your code. Then there's the Component Inspector. Think of it as your code's detective tool. It lets you easily pinpoint and understand which parts of your code are behind specific elements on your page. This makes identifying and editing components a breeze. And remember customization! Nuxt DevTools lets you tweak its UI to suit your style. This means you can set up the tools just how you like them, making your development environment more comfortable and tailored to your preferences. Conclusion In summary, Nuxt DevTools v1.0 marks a revolutionary step in web development, offering a comprehensive suite of features that elevate the entire development process. Features like live updates, easy navigation, and a user-friendly interface enrich the development experience. Each tool within Nuxt DevTools v1.0 is thoughtfully designed to simplify and enhance how developers build and manage their applications. In essence, Nuxt DevTools v1.0 is more than just a toolkit; it's a transformative companion for developers seeking to build high-quality web applications more efficiently and effectively. It represents the future of web development tools, setting new standards in developer experience and productivity....

Dec 1, 2023

8 mins

VueNuxtJSDevToolsJavaScript

Understanding Vue.js's <Suspense> and Async Components

In this blog post, we will delve into how and async components work, their benefits, and practical implementation strategies to make your Vue.js applications more efficient and user-friendly. Without further ado, let’s get started! Suspense Let's kick off by explaining what Suspense components are. They are a new component that helps manage how your application handles components that need to await for some async resource to resolve, like fetching data from a server, waiting for images to load, or any other task that might take some time to complete before they can be properly rendered. Imagine you're building a web page that needs to load data from a server, and you have 2 components that fetch the data you need as they will show different things. Typically, you might see a loading spinner or a skeleton while the data is being fetched. Suspense components make it easier to handle these scenarios. Instead of manually managing loading states and error messages for each component that needs to fetch data, Suspense components let you wrap all these components together. Inside this wrapper, you can define: 1. What to show while the data is loading (like a loading spinner). 2. The actual content that should be displayed once the data is successfully fetched. This way, Vue Suspense simplifies the process of handling asynchronous operations (like data fetching) and improves the user (and the developer) experience by providing a more seamless and integrated way to show loading states and handle errors. There are two types of async dependencies that can wait on: - Components with an async setup() hook. This includes components using with top-level await expressions. *Note: These can only be used within a component.* - Async Components. Async components Vue's asynchronous components are like a smart loading system for your web app. Imagine your app as a big puzzle. Normally, you'd put together all the pieces at once, which can take time. But what if some pieces aren't needed right away? Asynchronous components help with this. Here's how they work: - Load Only What's Needed: Just like only picking up puzzle pieces you need right now, asynchronous components let your app load only the parts that are immediately necessary. Other parts can be loaded later, as needed. - Faster Start: Your app starts up faster because it doesn't have to load everything at once. It's like quickly starting with the border of a puzzle and filling in the rest later. - Save Resources: It uses your web resources (like internet data) more wisely, only grabbing what’s essential when it's essential. In short, asynchronous components make your app quicker to start and more efficient, improving the overall experience for your users. Example: ` Combining Async Components and Suspense Let's explore how combining asynchronous components with Vue's Suspense feature can enhance your application. When asynchronous components are used with Vue's Suspense, they form a powerful combination. The key point is that async components are "suspensable" by default. This means they can be easily integrated with Suspense to improve how your app handles loading and rendering components. When used together, you can do the following things: - Centralized Loading and Error Handling: With Suspense, you don't have to handle loading and error states individually for each async component. Instead, you can define a single loading indicator or error message within the Suspense component. This unified approach simplifies your code and ensures consistency across different parts of your app. - Flexible and Clean Code Structure: By combining async components with Suspense, your code becomes more organized and easier to maintain. An asynchronous component has the flexibility to operate independently of Suspense's oversight. By setting suspensible: false in its options, the component takes charge of its own loading behavior. This means that instead of relying on Suspense to manage when it appears, the component itself dictates its loading state and presentation. This option is particularly useful for components that have specific loading logic or visuals they need to maintain, separate from the broader Suspense-driven loading strategy in the application. In practice, this combo allows you to create a user interface that feels responsive and cohesive. Users see a well-timed loading indicator while the necessary components are being fetched, and if something goes wrong, a single, well-crafted error message is displayed. It's like ensuring that the entire puzzle is either revealed in its completed form or not at all rather than showing disjointed parts at different times. How it works When a component inside the boundary is waiting for something asynchronous, shows fallback content. This fallback content can be anything you choose, such as a loading spinner or a message indicating that data is being loaded. Example Usage Let’s use a simple example: In the visual example provided, imagine we have two Vue components: one showcasing a selected Pokémon, Eevee, and a carousel showcasing a variety of other Pokémon. Both components are designed to fetch data asynchronously. Without , while the data is being fetched, we would typically see two separate loading indicators: one for the Eevee Pokemon that is selected and another for the carousel. This can make the page look disjointed and be a less-than-ideal user experience. We could display a single, cohesive loading indicator by wrapping both components inside a boundary. This unified loading state would persist until all the data for both components—the single Pokémon display and the carousel—has been fetched and is ready to be rendered. Here's how you might structure the code for such a scenario: ` Here, is the component that's performing asynchronous operations. While loading, the text 'Loading...' is displayed to the user. Great! But what about when things don't go as planned and an error occurs? Currently, Vue's doesn't directly handle errors within its boundary. However, there's a neat workaround. You can use the onErrorCaptured() hook in the parent component of to catch and manage errors. Here's how it works: ` If we run this code, and let’s say that we had an error selecting our Pokemon, this is how it is going to display to the user: The error message is specifically tied to the component where the issue occurred, ensuring that it's the only part of your application that shows an error notification. Meanwhile, the rest of your components will continue to operate and display as intended, maintaining the overall user experience without widespread disruption. This targeted error handling keeps the application's functionality intact while indicating where the problem lies. Conclusion stands out as a formidable feature in Vue.js, transforming the management of asynchronous operations into a more streamlined and user-centric process. It not only elevates the user experience by ensuring smoother interactions during data loading phases but also enhances code maintainability and application performance. I hope you found this blog post enlightening and that it adds value to your Vue.js projects. As always, happy coding and continue to explore the vast possibilities Vue.js offers to make your applications more efficient and engaging!...

Apr 24, 2024

6 mins

VueWeb PerformanceUXJavaScript

Nuxt.js for Complete Beginners

The Vuejs Amsterdam online conference was held at the end of February in 2021. It brought together Vue.js enthusiasts and community members from around the world. Many interesting topics were presented and covered. The focus, of course, was on Vue.js 3. In addition, the creators of Nuxt.js had the opportunity to showcase it from the current standpoint in development, to their intentions for it down the track. They even demonstrated a pre-alpha version of Nuxt.js 3, that’s based on Vue.js 3. This article will start by briefly covering general Nuxt.js concepts, creating a new Nuxt.js app using the create-nuxt-app CLI, and finally, going through the different files and folders that Nuxt.js auto-generates for us. Let’s start! Nuxt.js Concepts Nuxt.js is a web development framework that builds on top of the Vue.js framework. It allows you to use your Vue.js skills to build a more confident, structured, SEO friendly website purely in Vue.js. Remember when you had to mess with the Vue.js SSR module and the Vue Meta module to build a SEO friendly website? On top of that, you had to install and use Vuex and Vue Router too! Well, Nuxt.js takes care of that! No more chaotic setup and scaffolding to start a new Vue.js app. With the help of the create-nuxt-app CLI, you can scaffold a Nuxt.js app in no time. What’s remarkable about Nuxt.js is its capacity to enforce convention over configuration. This means, you write less configuration files by sticking to a specific directory structure that makes Nuxt.js happy and saves you a ton of time! Apps supported by Nuxt.js Nuxt.js supports building a variety of web apps, including the following: Server-Side Rendering (SSR) SSR apps are also known as Universal Apps. The app gets rendered on the server-side before it is sent to the client-side, and is displayed in the browser. This is the best option when working on an SEO friendly website written in Vue.js. You can read the full documentation for the SSR apps here: SSR Apps Single Page Apps (SPA) This is what you’ve been doing so far with Vue.js. The app is compiled into a few JS and CSS files. When the user requests the app, the files are downloaded to the client-side, and the Vue.js engine takes over rendering and displaying the app. Static Site Generation (SSG) Nuxt.js can pre-render your app at build time. This means the entire app will be converted to simple static HTML files that can be hosted and served over a Content Delivery Network (CDN). The SSG option makes an app a legal JAMStack app. You can read the full documentation for the Static Site Generation here: Static Site Generation. File System Routing Nuxt.js automatically generates all the Vue.js Routes in your app based on the folder structure inside the *pages* folder. For example, consider having this folder structure: ` Nuxt.js automatically generates the following route configuration: ` You can read about *File System Routing* here: File System Routing. Data Fetching Inside a Nuxt.js app, you can still use the old techniques you kmow when developing Vue.js apps. However, we have a new player here! Server-side rendering. Nuxt.js provides a new set of data-hooks that you can implement so that Nuxt.js can prefetch data when generating the app at the server-side. Here are two data-hooks offered by Nuxt.js: fetch() hook This hook was introduced with Nuxt.js 2.12+ release. It can be used inside Vue.js components stored in the *pages* folder and *components* folder. asyncData() hook This hook has been around for a while now, and can be used only inside the Vue.js components stored in the *pages* folder. You can read more about *Data Fetching* hooks here: Data Fetching. Meta Tags and SEO Nuxt.js makes it so intuitive to add SEO support to your SSR app. You can add Metadata to your app at two different levels: - Globally using the *nuxt.config.js* file - Locally inside a Nuxt.js Page You can read about *Meta Tags and SEO* hooks here: Meta Tags and SEO. Create our first Nuxt.js app Let’s use the create-nuxt-app CLI, and create our first Nuxt.js app! Before you start, you want to make sure you have all the perquisites required before you can install and run the CLI. For this article, I am going to use npx. However, you can also use npm, or feel free to use yarn. Step 0 Start by running the following command: ` This command uses the create-nuxt-app tool, and specifies the name of the project- in this case *my-first-nuxt-app*. The CLI will ask you a few questions that are important to scaffold the new Nuxt.js app based on your own preferences and decisions. Here’s what to expect. Step 1 First, let’s confirm the project name as shown in the Figure 1. Give the app a name and hit Enter. _Figure 1: Specify project name_ Step 2 You’ve got to choose whether you want to develop your app with TypeScript or JavaScript. I will select *JavaScript* as shown in Figure 2. _Figure 2: Programming language_ Step 3 Next, you need to choose between Npm or Yarn. I will select *Npm* as shown in Figure 3. _Figure 3: Package manager_ Step 4 In this step, you’ve got to select the UI framework you are going to use in the app. I will select *Tailwind CSS* as shown in Figure 4. Even if you skip this step, you can add any UI framework you want later. _Figure 4: UI framework_ Step 5 Nuxt.js offers a set of modules that you can use right away in your apps. For this app, I will pick the *Axios* module. Figure 5 shows the selection. _Figure 5: Nuxt.js modules_ Step 6 The CLI makes it super intuitive to integrate linters in your app. I will pick up both *ESLint* and *Prettier*. Figure 6 shows the selection. _Figure 6: Linting tools_ Step 7 Now it’s time to select a testing framework. For the sake of this article, I will select *None*. Feel free to add any. Figure 7 shows the selection. _Figure 7: Testing framework_ Step 8 By default, Nuxt.js supports two rendering modes. SSR/SSG and SPA. I will pick *SSR/SSG* to take advantage of the Server-side rendering. Figure 8 shows the selection. _Figure 8: Rendering mode_ Step 9 The deployment target depends on our selection in Step 8. In this case, we have two options to select from. Server (using a Node.js server hosting) or Static (CDN/JAMStack hosting). I will select the *Server* deployment target as shown in Figure 9. _Figure 9: Deployment target_ Step 10 For the development tools, I will keep it simple and select the *jsconfig.json* option as shown in Figure 10. _Figure 10: Development tools_ Step 11 I won’t be using any continuous integration for this app. I will simply select *None* as shown in Figure 11. _Figure 11: Continuous integration_ Step 12 Finally, the CLI asks whether you want to use any version control system. A version control system is always recommended when doing any kind of development. I will select *Git* as shown in Figure 12. _Figure 12: Version control system_ These twelve questions are enough for the CLI to start scaffolding and generating your app based on your preferences. It takes a few seconds to have everything ready for you. If all goes well, you should see the following as in Figure 13. _Figure 13: create-nuxt-app new app instructions_ The CLI gives you instructions on how to run and build the app. Step 13 Let’s run the app by following the steps highlighted in Figure 13. Run the following commands: ` The CLI compiles both the client and server parts of the app and starts the Node.js server on port 3000 as shown in Figure 14. _Figure 14: App is running_ Step 14 Open a browser instance and navigate to the URL *http://localhost:3000/* and you should see the default Nuxt.js app rendering. Figure 15 shows the app running in a browser. _Figure 15: App rendering in a browser_ That’s all you need to get started on your first Nuxt.js app. Enjoy! Nuxt.js Directory Structure Let’s quickly go through the different folders the CLI generated for us. I will start by opening the new app inside Visual Studio Code. Figure 16 shows the app open inside the editor. _Figure 16: App folders and files_ Let’s go through each folder, and explain their roles briefly. .nuxt The *.nuxt* folder is (re-)generated by the CLI every time you run or build the app. It has all the automatically generated files that Nuxt.js uses to run your app. You can read more about the *.nuxt* folder here: .nuxt. assets The *assets* folder contains all of your uncompiled files such as Sass files, images, or font files. Nuxt.js makes use of Webpack to load all the files inside this folder. You can read more about the *assets* folder here: assets. components This folder holds all of your Vue.js components. Nuxt.js components are not different from any other Vue.js component. Read more about the *components* folder here: components. layouts This folder contains all of your layout components. These are Vue.js components with placeholders for content. At run time, the component and the layout it uses get merged together into a single component. Layouts in Nuxt.js allows you to define fixed UI sections in your app instead of having to repeat things over and over. You can read more about the *layouts* folder here: layouts. pages This folder also holds Vue.js components. It is unique because Nuxt.js converts this folder structure (components with sub-folders) into actual Vue.js Routes. You can read about the *pages* folder here: pages. plugins This folder contains global JavaScript functions that you want to run before Nuxt.js instantiates the root Vue.js app. These functions are called *Plugins*. They can take multiple forms. For instance, you create a Nuxt.js Plugin to load a Vue.js Plugin to your app. You can also install, and make use of a third-party Nuxt.js Plugin. You can read more about the *plugins* folder here: plugins. static The name of this folder says it all! This folder is directly mapped to the server root. You can place any file in this folder that you do not want Webpack to process. For example, you can place a favicon file, any CSS files, and many other such files. You can read more about the *static* folder here: static. store The *store* folder holds all the Vuex store files. Nuxt.js comes with the Vuex module installed, but keeps it disabled. In order to enable the Vue store in your Nuxt.js app, create an *index.js* file inside this folder, and Nuxt.js will automatically enable it for you. You can read more about *store* folder here: store. nuxt.config.js As I mentioned, Nuxt.js prefers convention over configuration. However, at some times you may need to tweak the configuration a little. Nuxt.js provides the *nuxt.config.js* file to allow for custom configuration settings on the app level. Read more about *nuxt.config* file here: nuxt.config. That’s just a quick overview of what folders are generated by the Nuxt.js CLI. There are more you can read up on. You can find all the information you need on Nuxt.js Documentation website. Conclusion In this article, you were introduced to Nuxt.js and took a few baby steps towards creating your first Nuxt.js app. In the coming articles, we will immerse ourselves in the Nuxt.js world, and explore this fresh and promising web development framework together. You can follow me on Twitter to see more of my work....

Mar 22, 2021

12 mins

NuxtJSVue

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Going Serverless with Vue.js and Firebase Cloud Functions

Fire the base of Vue.js! - 3 Part Series

Firebase Cloud Functions, the concept

HTTPs Triggered Cloud Functions

Background Triggered Cloud Functions

Demo

Clone the app

Add support for Firebase Cloud Functions

Use Environment Variables to store configuration settings

Implement the Cloud Function

Send an email inside the Cloud Function

Cloud Function Execution Process

Conclusion

Bilal Haidar

You might also like

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools

Understanding Vue.js's <Suspense> and Async Components

Nuxt.js for Complete Beginners

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Nuxt DevTools v1.0: Redefining the Developer Experience Beyond Conventional Tools

Understanding Vue.js's <Suspense> and Async Components

Nuxt.js for Complete Beginners

Introduction to Zod for Data Validation