DEV Community: Timea Pentek

The process I follow when starting a new project

Timea Pentek — Wed, 02 Oct 2024 17:40:19 +0000

As I am starting an exciting project for a small business, I reflected on the steps I follow when initiating a project. One thing I observed is that this process gets more refined as I take on more tasks, and I also pay more attention to having a well-organised plan in place. This helps both me and the client to have a clear timeline and defined expectations.

1. Gathering requirements for the project

The first step I take is to understand the overall task and the client’s requirements. This is more of a discovery session where I attempt to find out some of the most important aspects of the desired website. For example, for my current project, I learnt that it's important for the client to manage the site and its content independently to some extent. Insights like this often guide my decision on the tech stack I might use.

After this session, I am able to create a functionality report that provides a clear overview of the project. I then like to reiterate this with the client and dive deeper into more details during a follow-up conversation. During this meeting, I also ask questions about the design or receive it in case it is available. In my situation, I am collaborating with the owner to help develop the design. Once the design is finalised I gather all the necessary resources for the website such as images, vectors, and copy.

2. Deciding on the tech stack

Once I gather all the necessary information about the website’s features and functionalities, I like to outline various tech stack options. I then give a short pros/cons presentation to the client, along with my advice for the best approach to take. Next comes the decision on the hosting platform and a conversation about any paid third-party libraries or tools that the front-end might be consuming. This varies depending on the website’s specific functionalities, and the client needs to be aware of any additional costs.

Since my current client wants to be able to manage the website, I also introduced my recommended content management system when I was presenting the tech stack options. This helps clarify the overall vision, including how it will be possible to manage orders, products, and pages.

3. Creating a timeline, setting goals, and developing a plan

The third step in my process is to create a detailed timeline, set goals for the project, and develop a plan. This involves breaking down the project into manageable parts. A well-organised plan keeps both me and the client on track and ensures efficient progress throughout the project.

4. Development, testing, and client review

My next step is development itself. By this phase, all the third-party tools, design choices, and assets have been decided on. During this stage, I set up the development environment, after which I implement back-end and front-end functionalities by focusing on modular, reusable elements. I also implement all the features discussed previously with the client.

Once the website is completed I conduct thorough testing including functionality, usability, and compatibility across browsers and devices. In case any bugs are identified during the testing phase I fix those, after which, I present the website to the client. Following the client review session, I make any necessary adjustments based on the feedback received.

5. Deployment and maintenance

The last step I take is to prepare for launch by finalising all content and settings and then deploying the website to the live server. I like to do a few more tests once the website is live. My final activities include training the client on how to manage the website and offering ongoing maintenance and support for post-launch issues.

I found that this approach helps lead to a successful outcome, and that communication is more effective throughout the process. What are some of the steps you follow when starting a project from scratch? I would love to find out and learn from a different perspective.

How I made a drag-and-drop file uploader with Vue3 and Firebase

Timea Pentek — Sat, 01 Jun 2024 19:16:08 +0000

There is shared responsibility between the client and the server when handling features such as uploading files. The client takes care of transferring the file to the server and providing a way to access the file. The server takes care of validating the upload, storing the file, file permissions, and creating the API for the client to send the file.

I started out by building the component where users will be able to drop the files. After I was done with the HTML template I had to find a way to ‘pay attention’ to drag and drop actions made by the user. Luckily, there are Javascript event listeners for drag and drop events such as: drag, dragstart, dragend, dragover, dragenter, dragleave, drop. I added these event listeners to the div tag that acted as the ‘drop zone’, however, by default most browsers redirect the user away from the app when a file is dropped. To avoid this behaviour I used event modifiers, which allowed me to handle what happens when a file is dropped. The event modifiers I added were ‘prevent’ and ‘stop’. Once the drop event fired I created an upload function where I handled most of the logic.

<div
   class="w-full px-10 py-20 rounded text-center cursor-pointer border border-dashed border-gray-400 text-gray-400 transition duration-500 hover:text-white"
   :class="{ 'bg-[#4EE4A2] border-[#4EE4A2] border-solid': is_dragover }"
   @drag.prevent.stop=""
   @dragstart.prevent.stop=""
   @dragend.prevent.stop="is_dragover = false"
   @dragover.prevent.stop="is_dragover = true"
   @dragenter.prevent.stop="is_dragover = true"
   @dragleave.prevent.stop="is_dragover = false"
   @drop.prevent.stop="upload($event)" 
>

The next step was to retrieve the file/s that the user uploaded. To do this, I needed access to the $event object. The event object refers to the argument added to the event handler function, and it contains information regarding the event that caused the given handler to be invoked. The event object contains a property called ‘dataTransfer’, which is an object that contains the information on the files transferred.

Once I had access to the uploaded files the next step was to transfer them to the Firebase storage. Since the event object provided me with the files in an object format (this was tricky as the object has numeric keys and it looked like an array), the first step I took was to convert them into an array so that I can loop through the array and send each file to Firebase. I converted the object into an array using the spread operator, and iterated through the array. For each file I added a validation to check whether the file’s mime type corresponds to what I was expecting to receive from the user. Validation can be performed both on the client and server side. For this particular project I was allowing only mp3 files to be sent to the server.

upload($event) {
      this.is_dragover = false

      // convert obj to array
      const files = $event.dataTransfer ? [...$event.dataTransfer.files] : [...$event.target.files]

      files.forEach((file) => {
        if (file.type !== 'audio/mpeg') {
          return
        }
}

I initialised the Firebase storage and set up a reference to the main storage which basically represents the bucket url. Once I had reference to the main storage I also created a child reference to the folder holding the audio files just to keep everything clean. The last step was to actually upload the files to Firebase, and to achieve this I used a Firebase specific function called uploadBytesResumable(ref, data, metadata). I choose this function because it exposes progress updates, which helped me create progress bars for the uploads.

upload($event) {
      this.is_dragover = false

      // convert obj to array
      const files = $event.dataTransfer ? [...$event.dataTransfer.files] : [...$event.target.files]

      files.forEach((file) => {
        if (file.type !== 'audio/mpeg') {
          return
        }

        const storageReference = ref(storage) 
        const podcastRef = ref(storageReference, `/podcasts/${file.name}`)

        const uploadTask = uploadBytesResumable(podcastRef, file)
}

This is roughly the logic behind how I managed to upload files to Firebase that came from a drag and drop event. I later added to the project animated progress bars, handled the responses from Firebase accordingly and stored the file data in Firebase database with additional fields such as who uploaded the audio file, the name of the file, genre, etc. Follow this link to see the full component logic: https://github.com/PentekTimi/podcast-listener/blob/master/src/components/AppUpload.vue

Quick overview of reactivity in Vue3

Timea Pentek — Thu, 30 May 2024 21:48:16 +0000

In my opinion, one of Vue’s most powerful features is its reactivity system. Reactivity allows the framework to automatically update the UI when the information behind it changes. By default, Javascript is not naturally reactive, if nobody tells it, it won’t know that the state changed.

In Vue3 with the Composition API it is common to use ref() and reactive() to add reactivity to a variable/object. Under the hood, Vue converts the data into a proxy object, which enables Vue to perform dependency tracking and change-notification when properties are accessed or modified. In-depth blog about reactivity here: https://blog.logrocket.com/your-guide-to-reactivity-in-vue-js/

The most common ways in Vue Composition API to achieve reactive states are by using reactive() or ref().

reactive()

This function only works with objects, and it does not work with primitives. The returned value from reactive() is a Proxy of the original object. When implementing reactive() we can avoid using the ‘.value’ to retrieve the properties of the object, in contrast with the ref() function where we have to use ‘.value’. To access a property we can do so by using ‘object.key’ notation.

The question is, however, if losing ‘.value’ is a benefit or not. I have seen many opinions that losing ‘.value’ can make it harder to track which line of code is triggering a reactive effect. This issue is not so noticeable with small projects, but it can become much more difficult to track reactive objects in a large project. In fact, Vue dropped the reactivity transform feature which got rid of the ‘.value’ when using ref() mainly for this reason.

In addition to this, reactive has a few limitations such as limited value types (only works with objects), can’t replace entire reactive objects because the reactivity connection to the first reference would get lost, and is not destructure-friendly because, again, reactivity connection would get lost.

Because of these limitations, Vue currently recommends using ref as the primary API to declare a reactive state.

ref()

Ref works with any data type, including objects. To create a reactive value for primitives (boolean, string, number, etc) we can only use ref(). Whenever we want to access the current value of the reactive property we have to use ‘(name of the value/object).value’. You do not need to append the ‘.value’ when using the ref in the HTML template. With ref, if you are passing it an object you can completely replace it with another one, this is not possible with reactive.

Hopefully, with this quick overview you've gained a bit more clarity about the differences of the two.

Keeping track of the authentication state with Pinia in a Vue.js web app

Timea Pentek — Tue, 30 Apr 2024 13:52:48 +0000

Once a user is registered, or logged in in most cases the dashboard or navigation links will slightly change in an application to reflect the logged-in state. This was something that during my project I also wanted to achieve. To keep track of the authentication state I used Pinia state management and created a user store. By doing this I was able to conditionally render different components/html elements or content depending on the authentication state.

The first step was to create a Pinia store and initialise the authentication state as false.

import { defineStore } from 'pinia'

export default defineStore('user', {
  state: () => ({
    userLoggedIn: false
  }),
})

In a previous blog post, I described how I registered users using Firebase (link to the blog post: https://dev.to/pentektimi/authentication-with-firebase-for-a-vuejs-project-5h36), however, this solution was isolated to a single component. I wanted to have easy access to the register function and I wanted to keep track of the authentication state.

This is where Pinia's actions property came in handy. Pinia actions are functions that outsource business logic, they become available to all components. Actions can be asynchronous and can commit multiple mutations which helps reduce the amount of code you have to write.

I decided to extract the register function logic from the component and add it to Pinia actions, as this function plays a role in updating the authentication state. Once a user registered I wanted to give access to their personal dashboard and update the authentication state to true. I imported the necessary methods from Firebase and references to the Auth instance and Firestore database (find details on this here: https://dev.to/pentektimi/authentication-with-firebase-for-a-vuejs-project-5h36). After initialising the ‘userLoggedIn’ as false, I created an action function called register. To be able to access the ‘this’ keyword this function has to be written as a regular function, and not an arrow function.

import { defineStore } from 'pinia'
import { auth, db } from '@/includes/firebase'
import { createUserWithEmailAndPassword } from 'firebase/auth'
import { doc, setDoc } from 'firebase/firestore'

export default defineStore('user', {
  state: () => ({
    userLoggedIn: false
  }),
  actions: {
    async register(values) {
      // logic to register user
      const userCred = await createUserWithEmailAndPassword(auth, values.email, values.password)
      const newDocument = doc(db, 'users', userCred.user.uid)
      await setDoc(newDocument, {
        name: values.name,
        email: values.email
      })

      // logic to update state
      this.userLoggedIn = true
    },
  }
})

In the code block above you can see that after the logic of registering a user, I updated the authentication state using the ‘this’ keyword. The keyword refers to the ‘userLoggedIn’ variable. The asynchronous function register receives as an argument the values object which contains the input data that the user entered.

In the component that has the register form, I replaced the register logic inside the try block with the action function imported from the Pinia user store. To be able to access this function I used the mapActions method from Pinia. The script looked something like this after the changes were made.

<script>
import { mapActions } from 'pinia'
import useUserStore from '@/stores/user'

export default {
  name: 'AppRegister',
  methods: {
    ...mapActions(useUserStore, {
      createUser: 'register'
    }),
    async register(values) {
      try {
        await this.createUser(values)
      } catch (error) {
        return
      }
    }
  }
}
</script>

In case you are wondering where the 'values' argument comes from, I used VeeValidate to handle the form. In VeeValidate if you add a submit handler to the vee-form component, VeeValidate will automatically pass the form values to the handler as the first argument.

Authentication with Firebase for a Vuejs project

Timea Pentek — Tue, 30 Apr 2024 13:41:53 +0000

In my most recent Vuejs project, I had to decide how I would be going about the authentication feature of the app. Authentication is a task that is mainly left to the back-end/server, however, the browser or client does play a role in it too. Vue.js is a client-side framework, so I needed a server that could handle authentication. I opted for Firebase as a back-end solution and decided to store the user data in the Cloud Firestore.

Firebase can take care of hashing passwords, sending confirmation emails, or storing the user’s data. The role of the front end during authentication is relatively simple. The Vue application sends the register/login details to the server, Firebase will then take care of the authentication and check if the user exists with the credentials that were sent.

In case the authentication is successful, the server would respond with a token, and then this can be stored. It is important to store the token because it can be sent back to the server whenever data related to the user has to be modified or updated. Tokens are unique and only sending back the token to the server will suffice; we won’t have to send back all the authentication data. Firebase will not actively keep track of who is logged in, instead, we use the tokens to verify the user. This type of authentication is known as stateless authentication.

In this blog post I will be describing the steps I took that resulted in authenticating users successfully. As a quick overview, I first set up the Firebase SDK (software development kit) and initialised the app, then handled user registration with the help of ‘createUserWithEmailAndPassword’ method from Firebase.

The Firebase SDK is a library that helps us communicate with Firebase’s products, so the first step I took was to install the SDK and initialise Firebase.

npm install firebase

Configuring and initialising Firebase can be done in the main.js file, however, to avoid cluttering the app, I decided to separate this into a different file. Instead of having all the configuration code in the main.js, I just had to import the file. I am using the Firebase modular API, which is designed to make your web app as small as possible by importing functions individually.

//path to file: src/includes/firebase.js
import { initializeApp } from 'firebase/app'

//configuration object
const firebaseConfig = {
  apiKey: the api key will allow us to connect to Firebase,
  authDomain: url where we can send the authentication information,
  projectId: id of the project,
  storageBucket: describes the location where files are stored,
  appId: id of the app
}

//initialise the app
const firebaseApp = initializeApp(firebaseConfig)

I also imported the authentication module for the authentication services to be available. The authentication service of Firebase stores only the email and password, but it can’t hold any additional data such as name, age, or country. I added an input field requiring the entry of the user’s name to my registration form. To be able to store the name of the user I used the Firebase database (Firestore) service.

I created references to the authentication and Firestore services in the firebase.js file. I did this to not import and call repeatedly the same functions in multiple components. I also had multiple collections in Firestore, so I created a reference to the collection that held the user information. Below you can find the necessary imports and the final version of the firebase.js file.
Note: for all of this to work I had to enable the authentication services within the Firebase console, and made a few changes to the Cloud Firestore rules.

import { initializeApp } from 'firebase/app'
import { getAuth } from 'firebase/auth'
import {
  collection,
  getFirestore,
  initializeFirestore,
  persistentLocalCache
} from 'firebase/firestore'

const firebaseConfig = {
  apiKey: '',
  authDomain: '',
  projectId: '',
  storageBucket: '',
  appId: ''
}
const firebaseApp = initializeApp(firebaseConfig)
initializeFirestore(firebaseApp, { localCache: persistentLocalCache({}) })

//reference to authentication service
const auth = getAuth(firebaseApp)
//reference to the firestore service
const db = getFirestore(firebaseApp)
//reference to user collection
const usersCollection = collection(db, 'users')
export { auth, usersCollection, db}

Next, I handled the registration logic. I navigated to the component that has the registration form and listened to a submit event on the form. Once the event was triggered I wanted to call an asynchronous register function, which had a parameter that contained the input values (data from the input fields such as email, name, and password).

The createUserWithEmailAndPassword function from Firebase accepts as arguments three elements, the auth instance, the user’s email, and the user’s password. Below you can see that I created the user with this function. Now that the user has been created, Firebase generates a unique user identifier (User UID) for it. I wanted this user identifier to be the document name in the 'users' collection, so I passed the UID to the doc() function. The doc() function gets a document reference instance that refers to a document at the specified path, the arguments passed to this function are the path segments. The setDoc() function writes to the document referred to by a document reference, and if the document does not exist in that case it will create it. The parameters that the setDoc() function accepts are the document reference and a map of the fields and values to be added. I wrapped this logic in a try-catch block.

methods: {
   async register(values) {
      try {
      const userCred = await createUserWithEmailAndPassword(auth, values.email, values.password)
      const newDocument = doc(db, 'users', userCred.user.uid)
      await setDoc(newDocument, {
        name: values.name,
        email: values.email
      })
      } catch (error) {
        console.log(‘Unexpected error’)
        return
      }
    }
  }

Currently, the code is isolated to a single component, if you would want to register a user at a different location in your application it would make sense to refactor the code using Pinia actions.

Once a user is registered, or logged it is also very common that the dashboard or navigation links will slightly change to reflect the logged-in state. This was something that during my project I also wanted to achieve. I used Pinia state management and created a user store to keep track of the authentication state. I refactored the register function and added it to a Pinia store’s action function. I rendered conditionally different components/HTML elements or content in case the user was logged in.

Check out the refactored code in this blog post: https://dev.to/pentektimi/keeping-track-of-the-authentication-state-with-pinia-in-a-vuejs-web-app-3gb3, or find the full repository here: https://github.com/PentekTimi/podcast-listener.

Vue.js lifecycle hooks

Timea Pentek — Sun, 28 Apr 2024 12:42:33 +0000

Today I strengthened my knowledge of Vue.js lifecycle hooks to be able to correctly unmount a component and stop any requests to the server that would be ongoing in the background. This is a situation I came across while building a file upload component in my Vuejs project, where I had to cancel the upload/s in case a user navigated away from the page.

It was a very important step to take care of as components or resources not cleaned up properly could have impacted the performance of the application, but also cause excessive memory usage both to the server and front-end.

Vue.js and many other front-end frameworks offer predefined methods that allow us to get hold of a specific phase of the component’s lifecycle. Some of the Vuejs hooks are beforeCreate, created (creation hooks), beforeMount, mounted (mounting hooks), beforeUpdate, updated (updating hooks), beforeUnmount, and unmounted (destruction hooks).

What are lifecycle hooks?

Vuejs lifecycle hooks are predefined methods that get executed in a certain order throughout the lifecycle of a component from the initialisation of that Vue instance to its destruction. The lifecycle hooks allow you to know when a component is created, added to the DOM, updated, or destroyed.

There are some differences in how to use the lifecycle hooks in Vue 3 Composition API vs. Option API. Creation hooks are the first thing that runs in our component, however in the Composition API both creation hooks are replaced by the setup() method. In the Options API, we have the beforeCreate and the created hooks. When using Options API we don’t have to import the lifecycle hooks, however, when using Composition API we have to import the hook before we can use it; this is to keep the project as lightweight as possible.

beforeCreate:
The beforeCreate hook runs at the initialisation of the component. It runs before we have any reactive elements or DOM elements. At this stage, we don’t have access to any data or events, and we can’t call component methods either.
As I was trying to find use cases for this lifecycle hook I tended to come across information suggesting that this hook is not extensively used. However, it can be useful when we need to make an API call that does not need to be assigned to data (as the assigned data would be lost once the state is initialised), or for actions that require low-level setup.

created:
This is the first hook that gives us access to our component's data and events. The DOM is yet to be mounted and rendered, and the $el property will not be available yet.
This is one of the most used lifecycle hooks and is a perfect place to fetch external data.
The hook is useful when we want to read/write the reactive data, for example making an API call and storing the response.

Mounting hooks

The mounting hooks run when the DOM is mounted, and they handle rendering the component. The hooks are commonly used in applications, as they allow us to access the component right before and after the first render.

beforeMount:
The beforeMount hook runs right before the component DOM is rendered and mounted, here the template and the scoped styles are compiled. The root element (this.$el) does not exist yet, so we can’t manipulate the DOM. It is important to note that this hook is not called during server-side rendering. The hook is useful for performing actions before the DOM is updated and should be the last stage to make API calls.

mounted:
In the mounted hook, we have access to the reactive components and rendered DOM. In the Options API, we can access the DOM via the ‘this.$el’, and in the Composition API we need to use refs. At this stage the app component in the project becomes functional and the data is fit into the template, so it can be manipulated. The mounted hook is commonly used to set up event listeners, modify the DOM, or fetch external data. It is important to note that this hook is not called during server-side rendering.

Updating hooks

The update hooks run when reactive data is modified.

beforeUpdate:
The beforeUpdate hook runs after data changes, but right before the DOM is patched and re-rendered. This is a good stage to update the DOM manually or for any logic before data changes, like removing event listeners. It is also safe to mutate the component state at this stage. Note that this hook does not run during server-side rendering.

updated:
The updated hook runs after data changes on your component and the DOM re-renders and updates. A parent component's updated hook runs after that of its child components. Avoid mutating component state during this hook as that would likely cause an infinite loop. You can access the updated DOM during this hook. Note that this hook is not called during server-side rendering.

Destruction hooks

The destruction hooks are used in the process of removing a component. They are great for clean-ups to avoid memory leaks, and sending analytics. Destruction hooks are not called during server-side rendering.

beforeUnmount:
The beforeUnmount is invoked right before teardown or destruction. At this stage, the component still completely exists and is fully functional, as it has not been destroyed yet. This hook is most used to clean up components, such as removing event listeners or clearing timeouts.

unmounted:
The destroyed hook is when everything part of the component has been torn down, or destroyed from existence. At this stage all associated reactive effects have been stopped, including render effects and computed watchers. This method is also useful for cleanup required within the component, such as stopping server connections.

The lifecycle hooks described above are the main Vue lifecycle hooks, but there are some additional ones. To learn about these, follow this link: https://vuejs.org/api/options-lifecycle.html

Displaying multiple error messages on incorrect form entries with Vee-validate | Vue

Timea Pentek — Thu, 25 Apr 2024 21:59:52 +0000

A typical interaction with websites involves filling in forms. Form validation and displaying errors on incorrect input entries will be a task to account for when building a webpage.

Form validation can be done both on the client side and the server side. Client-side validation is an initial check that happens in the browser before the data is sent to the server. It ensures that the requirements set are fulfilled by the data that is being entered, and it provides the user with an instant response in case an entry is incorrect.
According to MDN (https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation), client-side validation is not an exhaustive security measure as it is easy to by-pass, and apps should always perform security checks on data submitted on the server-side as well. Server-side validation is a check that occurs on the server after the data is submitted. Before the data is saved to the server it has to pass a server-side validation. If the data doesn’t pass the check, a response is sent back to the user with the corrections that should be made.

In this blog post I am exploring the client-side form validation with Vee-validate (https://vee-validate.logaretm.com/v4/) and vee-validate/rules (https://www.npmjs.com/package/@vee-validate/rules).

This blog post reviews the solution I implemented to destructuring the error message for a form in a Vue 3 application.

When an input field is being validated against multiple rules, what are the options for sending back an error response to the user, assuming the user added an incorrect value in the input field? Should we send back a single error message or do we destructure the error message and send back multiple descriptive error messages for each rule that failed?

It probably depends on the input field and what type of data is being asked, however generic messages such as ‘An error occurred’ lack context, and so we should always try to provide the user with enough details.

The password field is a common place where the user is required to meet multiple rules, and in my Vue application the input is validated against multiple criteria. Because of this, I decided to display multiple error messages for the password field, which is part of a registration form built with Vee-validate.

Why did I decide to display multiple error messages for the password field? The main reason behind my decision was user experience (UX). It can become annoying for the user to try and guess what went wrong and why the field is not accepting their input.

Let's get started!

To get started, I created a basic Vue 3 app. In the components folder, I generated a new file called AppForm.vue for the form template. I then added the AppForm component to the main App.js file.

Below is the form template that has three input fields and a submit button.

<form>
  <!-- Email -->
  <div class="mb-3">
    <label class="inline-block mb-2 text-white">Email</label>
    <input 
      name="email" type="email" 
      placeholder="Enter your email" 
      class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" />
  </div>

  <!-- Password -->
  <div class="mb-3">
    <label class="inline-block mb-2 text-white">Password</label>
    <input 
      type="password" 
      placeholder="Create password" 
      class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" />
  </div>

  <!-- Confirm Password -->
  <div class="mb-3">
    <label class="inline-block mb-2 text-white">Confirm Password</label>
    <input 
      name="confirm_password" 
      type="password" placeholder="Confirm password" 
      class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" />
  </div>

  <!-- Submit Btn -->
  <button 
    type="submit" 
    class="block bg-[length:400px_200px] mt-6 w-52 bg-gradient- to-r from-[#1F1C2C] via-[#928DAB] to-[#1F1C2C] text-white py-1.5 px-3 rounded enabled:hover:bg-[right_center] enabled:transition-all enabled:duration-500">
    Submit
  </button>
</form>

To use the Vee-validate library, run in the terminal the following:
npm i vee-validate

In my project I also used TailwindCSS, just to be able to quickly style the form. I installed the necessary resources and made the configurations to set up Tailwind.

Next, I wanted to configure the Vee-validate library. To not clutter the App.js I decided to outsource this to a validation.js file that I created in a new folder called plugins, inside the src folder.

// path: src/plugins/validation.js
export default {
    install(app) {}
}

In the configuration file, I am creating the Vee-Validate plugin. In Vue, plugins are objects with a method called install. When we register the plugin Vue will call the install method.
To register the plugin we have to add the following to our main.js file:

import VeeValidatePlugin from "./plugins/validation";
import { createApp } from "vue";
import App from "./App.vue";

const app = createApp(App);
app.use(VeeValidatePlugin);

app.mount("#app");

Note: Your app may import other files such as CSS stylesheets.

The reason why I chose to set up VeeValidate this way is because the project I am working on has other forms throughout the app. This way VeeValidate will be available globally for me.
Next, I installed the vee-validate/rules package that includes the most common validators for input fields (https://www.npmjs.com/package/@vee-validate/rules).

npm install @vee-validate/rules

VeeValidate handles complex validations in an easy way. It uses the Vee-form, Vee-field, and ErrorMessage components to validate forms. In the configuration file, validation.js, I imported these components. After, I imported the validation rules and defined them using the defineRule function from vee-validate.

//import the components and defineRule function from vee-validate
import {
    Form as VeeForm,
    Field as VeeField,
    ErrorMessage,
    defineRule,
  } from "vee-validate";

// import the validation rules from vee-validate/rules package
import {
    required,
    min,
    max,
    email,
    confirmed,
    not_one_of as excluded,
  } from "@vee-validate/rules";

export default {
    install(app) {
      // Make components available globally in the Vue application using the app.component() method. 
     // The function takes the arguments: app.component("registered name", implementation)

      app.component("VeeForm", VeeForm);
      app.component("VeeField", VeeField);
      app.component("ErrorMessage", ErrorMessage);
 
      // Define the rules. The defineRule function accepts a rule name that acts as an identifier 
     // for that validation rule, the second argument is the validator function that will verify the field value.

      defineRule("required", required);
      defineRule("min", min);
      defineRule("max", max);
      defineRule("email", email);
      defineRule("passwords_mismatch", confirmed);
      defineRule("excluded", excluded);
    },
  };

The configuration for VeeValidate is complete for now. To implement it, I had to make a few changes to the form template in the AppForm.vue component. The first changes that I made were the following:

Changing the form tag to vee-form
Changing the input tags to vee-field. Note: Vee-field will by default render an input tag. In order to render a different field add the ‘as’ prop to tell the component which field it should render (eg. as=’select’)
Adding an ErrorMessage component to each input. The name attribute on the ErrorMessage component has to match the name attribute on the vee-field. This is how to tell vee-validate for which input field should the ErrorMessage display the messages for

The vee-validate rules can be added in two different ways, either by adding the rule directly to the input field or by outsourcing the rules to an object. I opted for outsourcing the rules to a schema object to keep the form as clean as possible. To achieve this I used the validation-schema prop on the vee-form and passed in an object called schema. With all these changes my form looked something like this:

<div>
  <vee-form :validation-schema="schema">
    <!-- Email -->
    <div class="mb-3">
      <label class="inline-block mb-2 text-white">Email</label>
      <vee-field 
        name="email"
        type="email" 
        placeholder="Enter your email" 
        class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" 
       />
      <ErrorMessage class="text-[#CF6679]" name="email" />
    </div>
    <!-- Password -->
    <div class="mb-3">
      <label class="inline-block mb-2 text-white">Password</label>
      <vee-field 
        name="password" 
        type="password" 
        placeholder="Create password" 
        class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" 
       />
      <ErrorMessage class="text-[#CF6679]" name="password" />
    </div>
    <!-- Confirm Password -->
    <div class="mb-3">
      <label class="inline-block mb-2 text-white">Confirm Password</label>
      <vee-field 
        name="confirm_password" 
        type="password" 
        placeholder="Confirm password" 
        class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded" 
       />
      <ErrorMessage class="text-[#CF6679]" name="confirm_password" />
    </div>
    <!-- Submit Btn -->
    <button 
      type="submit" 
      class="block bg-[length:400px_200px] mt-6 w-52 bg-gradient-to-r from-[#1F1C2C] via-[#928DAB] to-[#1F1C2C] text-white py-1.5 px-3 rounded enabled:hover:bg-[right_center] enabled:transition-all enabled:duration-500"
     >
      Submit
    </button>
  </vee-form>
</div>

Next, I filled out the schema object inside the AppForm.vue component.

<script>
export default {
  name: "AppForm",
  data() {
    return {
      schema: {
        email: "required|email|min:3|max:100",
        password: "required|min:7|max:50|excluded:password,qwerty",
        confirm_password: "passwords_mismatch:@password",
      },
    };
  },
};
</script>

To add the rules to the schema object, you create key-value pairs, where the key is the name attribute on the input, and the value is the rule/s. The form has 3 input fields or vee-fields, so I have three key-value pairs in the schema object. Each rule has to be separated by a vertical line ‘|’.

Below are a few short descriptions of what each rule means:

Required: field has to be filled out
Email: input value has to be of type email
Min: the minimum amount of characters a value has to have
Max: the maximum amount of characters a value can have
Excluded: (the validator function is called not_one_of, but I imported it as excluded for easier comprehension) the input can’t have the values specified. In the form I created the password field can’t have the values ‘password’ or ‘qwerty’
passwords_mismatch:(the validator function is called confirmed) the input must be the same value as the confirmation field. The confirmation field is passed in after the ‘@’ sign.

At this point, on an incorrect entry, an error message would appear under the input field saying ‘field is not valid’. The user does not know the rules that an input field’s value is validating against, so it can become unclear as to why the value is wrong and why the system is rejecting it. This can quickly become annoying.

To avoid bad user experience I decided to display each error separately. The number of errors that would appear depends on how many validation rules the input breaks. This is not the default behaviour for vee-validate because vee-validate opts for a fast exit strategy for better performance. This means that when vee-validate comes across the first rule that is not met, it does not bother checking the rest of the rules, instead it exits the validation process.

For this registration form I wanted to display all the error messages for the password field, so I made the following changes to the password field:

<!-- Password -->
      <div class="mb-3">
        <label class="inline-block mb-2 text-white">Password</label>
        <vee-field name="password" :bails="false" v-slot="{ field, errors }">
          <input
            type="password"
            placeholder="Create password"
            class="block w-full py-1.5 px-3 text-gray-800 border border-gray-300 transition duration-500 focus:outline-none focus:border-black rounded"
            v-bind="field"
          />
          <div class="text-[#CF6679]" v-for="error in errors" :key="error">
            {{ error }}
          </div>
        </vee-field>
      </div>

Note: Don't forget to remove the ErrorMessage component that was added to the password field previously.

The first thing I did was to set the bails attribute on the vee-field to false. This lets vee-validate know that it has to check all rules even if it encounters one that already broke a validation rule. Basically, it cancels the fast exit strategy.

To render multiple error messages I had to tweak the behaviour of the vee-field component. The vee-field component makes use of scoped slots (v-slot) feature which allows rendering a complex group of markup. I created an opening and closing tag for the vee-field because I wanted to add more markup inside it, such as the input tag and the error messages. I moved the type, class, and placeholder attributes to the input tag. The default slot gave me access to the ‘field’ object and an ‘errors’ array. According to the VeeValidate docs:

The most crucial part of rendering fields with v-slot is that you bind the field object to your input element/input, the field object contains all the common attributes and listeners required for the field to be validated.

After I made these changes, I added a div tag, looped through the errors array, and displayed each message. (Docs for further explanation: https://vee-validate.logaretm.com/v4/api/field/#rendering-complex-fields-with-scoped-slots)

At this point, the error messages showed up separately. The next problem I had to solve was to convert the messages into descriptive information because right now it even looks like the application is broken.

I fixed this by adding custom error messages to the validation rules. Back in the validation.js, I imported the configure function from vee-validate, and for each rule I added a custom message.

configure({
      generateMessage: (ctx) => {
        const messages = {
          required: `The field ${ctx.field} is required.`,
          min: `The field ${ctx.field} is too short.`,
          max: `The field ${ctx.field} is too long.`,
          email: `The field ${ctx.field} must be a valid email.`,
          excluded: `You are not allowed to use this value for the field ${ctx.field}.`,
          passwords_mismatch: `The passwords don't match.`,
        };
        const message = messages[ctx.rule.name]
          ? messages[ctx.rule.name]
          : `The field ${ctx.field} is invalid.`;
        return message;
      },
    });

The generateMessage function comes from vee-validate and it has to return a string. To register the generateMessage function I used the configure function from vee-validate. I accessed the FieldContext (above as ‘ctx’) interface to have the information on the field name, value, and rule name (Docs for further explanation: https://vee-validate.logaretm.com/v4/guide/i18n#global-message-generator ). I then created an object called messages with the rule names and the custom error messages I wanted. I defined the message variable’s value using a quick ternary operator, and after I returned the correct string.

At last, the password field displays all the broken rules with a descriptive message.