VueJS

Firebase for user authentication in Vue.js

Published Feb 5, 2020

Updated Feb 14, 2023

11 min read

Fire the base of Vue.js! - 2 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.

And the Firebase goes on!

In the first installment of this series, I covered how fast you can kick off your dev life cycle by using the Mirage.js library as a local, and client-side, backend with a REST API in-memory service for your app.

In my second, and most recent, [installment] (https://dev.to/thisdotmedia/vue-the-mirage-from-this-angle-352p), I replaced Mirage.js with Cloud Firestore, a serverless database service offered by Firebase. This, of course, makes our app function in a more realistic manner, giving us an overview of it.

In this article, I will introduce Firebase User Authentication module to authenticate and authorize users accessing the Notes Writer app.

Since my last article, I’ve done a complete face-lift for the Notes Writer app in preparation for user authentication. The app is now more responsive and mobile friendly.

Here is a quick preview of the completed app after the addition of the User Authentication Module.

The login page, needless to say, is self explanatory.

The home page lists the existing notes, allows deleting or editing those notes and the ability to create new ones. This page introduces the Logout button as well.

The app is shown on a mobile. You review your existing notes by clicking the burger button located on the left side of the app header bar.

The source code of this article can be cloned from this GitHub repo: Notes Writer.

Firebase Authentication

Firebase Authentication Engine utilizes several methods to authenticate a user on your app via means such as Email with a Password, Phone, Facebook, Twitter, Apple ID, and many other options as shown here.

For this article, I will be using the Email/Password provider to authenticate users on the Notes Writer app.

You can always consult with the amazing Firebase Authentication docs here.

The Firebase Authentication module is also capable of doing user authorization by allowing administrators to define rules on how users can read, write, delete and edit data stored in the Cloud Firestore. You can read more about securing data in the Cloud Firestore here.

Let’s move on, and start coding user authentication in our app!

Demo

We will be adding the authentication feature on top of the new UI branch of the Notes Writer app. Therefore, start by cloning the Git branch by running this command:

git clone --branch new-ui git@github.com:bhaidar/notes-writer.git

The command clones the remote new-ui branch by creating a local copy of the branch on your computer.

Install Vue Router

Start by installing the Vue Router NPM package by running this command:

npm install vue-router

This command adds the Vue Router library into the app to allow navigation from one route to another.

Locate the /src/views folder, and add a new file named Login.vue. Initialize an empty Vue component by pasting the following content into the new file:

<template>
</template>
<script>
</script>

Save the file and switch back to the router/index.js file.

Configure Vue Router and routes

Now that the Vue Router is installed, and the Login view is created, let’s configure the Vue Router in the app, and define the different routes available for the Notes Writer app.

Inside the router/index.js file, start by adding the following imports:

import Vue from 'vue'
import VueRouter from 'vue-router'
import Home from './../views/Home'
import Login from './../views/Login'
const fb = require('./../../firebaseConfig.js')

The firebaseConfig.js file is imported into this file, and is needed later on to check whether the current user is signed-in already.

Configure the Vue object to use the Vue Router plugin by adding this line of code:

Vue.use(VueRouter)

This step is required by the Vue engine to install the Vue Router plugin, and make its functionality available to the rest of the app.

Next, we need to create a new instance of the VuewRouter object, and define our routes as follows:

export const router = new VueRouter({
  mode: 'history',
  base: process.env.BASE_URL,
  routes: [
    {
      path: '*',
      redirect: '/'
    },
    {
      path: '/',
      name: 'home',
      component: Home,
      meta: {
        requiresAuth: true
      }
    },
    {
      path: '/login',
      name: 'login',
      component: Login
    }
  ]
})

The VueRouter instance defines a catch-all route to redirect users to the Home view. The Home route defines a meta object with a single property of requiresAuth. This boolean value is used later to decide whether the route requires the user to be signed-in before accessing it.

Finally, the Login route is defined to load the Login view component.

If you are new to Vue Router plugin I suggest you visit their docs website

The Vue Router defines navigation guards and hooks. These guard and hooks are extension points you can implement to change the default behavior of the Vue Router engine when handling a specific route.

In our case, we want to implement the beforeEach navigation guard to decide whether the user can access the route he/she intends to visit. The decision is based solely on whether the route at hand requires the user to be authenticated, and that the user is indeed authenticated, and signed-in to the app.

router.beforeEach((to, from, next) => {
  const requiresAuth = to.matched.some(x => x.meta.requiresAuth)
  const currentUser = fb.auth.currentUser

  if (requiresAuth && !currentUser) next({ path: '/login', query: { redirect: to.fullPath } })
  else if (!requiresAuth && currentUser) next('/')
  else if (!requiresAuth && !currentUser) next()
  else next()
})

This hook or navigation guard accepts a single callback function that defines three main input parameters:

to: The route you are navigating to.
from: The route you are coming from.
next: Is a function that is used to move forward to the next hook in the pipeline, to redirect to a new route, to throw an error, and to terminate the current navigation.

The callback function above started by checking whether the route the user is navigating to requires authentication. It then uses the Firebase Auth API to get a hand on the currently signed-in user.

You can read more about managing users in Firebase Auth API here.

If the route requires authentication, and the user is not signed-in, then redirect the user to the Login view to enter their credentials, and sign-in to the app before visiting the route.

If the route doesn’t require authentication, and the user is currently signed-in, then redirect the user to the Home view.

If the route doesn’t require authentication, and the user is not signed-in, then let the user continue with the current navigation. For instance, this applies to a user visiting the Login view, or Register view.

Finally, if none of the above applies, the user is allowed to route to the desired route. This applies to the Home view. This route requires authentication, and if the user is currently signed-in, then the user is automatically redirected to the Home view.

To try this navigation guard, run the app by issuing the following command, and try to navigate to the root page /:

npm run serve

You are instantly redirected to the login page to sign-in, and access the app.

The final step is to tell the Vue about the routes that we defined above. Locate, and open the main.js file, and make sure to pass over the routes object to the root Vue instance as follows:

import Vue from 'vue'
import App from './App.vue'
import { store } from './store'
import { router } from './router'
const fb = require('./../firebaseConfig.js')

Vue.config.productionTip = false

let app
fb.auth.onAuthStateChanged(user => {
  if (!app) {
    app = new Vue({
      store,
      router,
      render: h => h(App)
    }).$mount('#app')
  }
})

Also notice that I’ve moved the initialization of the Vue root app inside the Firebase onAuthStateChanged event handler. This event is usually fired when a change occurs on the currently signed-in user. The user has signed-in, or the user has signed-out. This way, the app won’t initialize before Firebase is fully initialized.

Naturally, the next step is to implement the Login view so that users can start accessing the app.

Paste the following inside the Login.vue view component:

<template>
  <div class="login">
    <section class="session">
      <div class="left"></div>
      <section>
        <header>
          <h1>Notes Writer</h1>
          <p>Welcome to Notes Writer App! Login to your account to manage your notes:</p>
        </header>
        <form
          class="form"
          @submit.prevent
        >
          <div class="form__field">
            <input
              id="email"
              type="text"
              placeholder="Email"
              autocomplete="off"
              v-model.trim="loginForm.email"
            >
            <label for="email">Email:</label>
          </div>
          <div class="form__field">
            <input
              id="password"
              type="password"
              placeholder="Password"
              autocomplete="off"
              v-model.trim="loginForm.password"
            >
            <label for="password">Password:</label>
          </div>
          <button
            @click="login"
            class="btn form__btn--submit"
          >Log In</button>
          <p
            class="errors"
            :style="{visibility: showErrors ? 'visible' : 'hidden'}"
          >Wrong username or password! Try again.</p>
        </form>
      </section>
    </section>
  </div>
</template>

<script>
import { mapMutations } from 'vuex'
const fb = require('./../../firebaseConfig.js')

export default {
  data () {
    return {
      loginForm: {
        email: '',
        password: ''
      },
      errors: null
    }
  },
  computed: {
    showErrors () {
      return this.errors
    }
  },
  methods: {
    ...mapMutations(['setCurrentUser']),
    login: async function () {
      try {
        const user = await fb.auth.signInWithEmailAndPassword(this.loginForm.email, this.loginForm.password)
        this.setCurrentUser(user.user)
        this.$router.push('/')
      } catch (error) {
        this.errors = error
      }
    }
  }
}
</script>

<style lang="scss" scoped>
@import "@/styles/components/login.scss";
</style>

The component defines a basic Login form with two fields: Email and Password.

Upon clicking the Log In button, the event handler fires:

login: async function () {
      try {
        const user = await fb.auth.signInWithEmailAndPassword(this.loginForm.email, this.loginForm.password)
        this.setCurrentUser(user.user)
        this.$router.push('/')
      } catch (error) {
        this.errors = error
      }
    }

The login() function makes use of the Firebase Auth API to sign-in the user using the signInWithEmailAndPassword() function. This function accepts as input both the user’s email and password.

If the request is successful, this function returns the currently signed-in user. The code then calls a Vuex Store mutation to store the current signed-in user. In addition, the user is redirected to the home page to start managing the notes.

In the case of an error, the code catches it, and informs the user that their sign in attempt failed.

The above introduces a new piece of state that we need to manage inside the Vuex Store instance: the currentUser. Let’s build it.

Navigate to the store/index.js file, and add the following to the state object:

state: {
    notesList: [],
    note: {},
...
currentUser: {},
  },

Also, add the mutation function as:

setCurrentUser (state, user) {
state.currentUser = user
},

Now the store is ready!

Before you can sign-in using the above Login view, we need to set the Firebase sign-in provider on this app.

Navigate to the Firebase Console.

Click on your app.
Click the Authentication menu item.
Select the Sign-in method tab.
Hover over the first row labeled Email/Password and click the pencil icon to enable this option.

Once you enable this provider, make sure to hit the Save button.

Next, you need to create a new user on the Firebase Console to test the app with.

Select the Users tab.
Click the Add user button.

Enter a valid email, a strong password and hit the Add user button to save the new user credentials.

Now that the backend Firebase is ready, let’s run the app, and test the work that has been done so far!

To run the app, issue the following command:

npm run serve

You enter your newly created user credentials and the app should sign you in to start managing your notes.

Add Author ID on Note model

Now that you can sign-in to the app, it’s time to introduce the field Author ID onto the Note model object. Every time you create a new Note, the app will grab the ID of the currently signed-in user and attach it on the Note model object to be stored in the Database.

Every Note should have an author or owner! This change is minor and affects only the saveNo0te() action inside the Vuex Store instance. Navigate to the /store/index.js file and amend the saveNote() action as follows:

async saveNote ({ commit, state }) {
      const { id, body, title } = state.note
      const authorId = state.currentUser.uid

      if (id) { // update
        commit('setPerformingUpdate', true)
        await fb.notesCollection.doc(id).update({
          body,
          title,
          updatedOn: fb.firebase.firestore.Timestamp.now()
        })
        commit('setPerformingUpdate', !state.performingUpdate)
      } else { // add
        commit('setPerformingAdd', true)
        await fb.notesCollection.add({
          body,
          title,
          **authorId,**
          createdOn: fb.firebase.firestore.Timestamp.now(),
          updatedOn: fb.firebase.firestore.Timestamp.now()
        })
        commit('setPerformingAdd', !state.performingAdd)
      }
      commit('setNote', {})
    }

When creating a new Note record, the code retrieves the currently signed-in User ID and stores this value inside a local variable named authorId. This variable is then passed over to the notesCollection.add() function when creating a new Note record as I’ve just shown in the source code.

That’s all! Now every Note created in the system has an owner or author. You will see shortly how we are going to use this feature to query for customized and owned Notes only.

Integrate Authentication into the Vuex Store

The Vuex Store instance should be updated whenever the status of the currently signed-in user changes. To cater for that, we will refactor the code inside the store object as follows:

fb.auth.onAuthStateChanged(user => {
  if (user) {
    store.commit('setCurrentUser', user)

    // realtime updates from our notes collection
    fb.notesCollection.orderBy('createdOn', 'desc').onSnapshot(querySnapshot => {
      let notesArray = []

      querySnapshot.forEach(doc => {
        let note = doc.data()
        note.id = doc.id
        notesArray.push(note)
      })

      store.commit('loadNotes', notesArray)
    })
  }
})

Now the store watches real-time changes on the notesCollection inside the onAuthStatechanged event handler callback.

If there is a valid user passed over, the store is updated accordingly. Then the store starts watching any changes on the notesCollection object.

Query for User’s own Notes only

So far the Vuex Store instance is watching the entire notesCollection object. However, what’s needed is to query only the notes that belong to the currently signed-in user. To achieve this goal, navigate to the store/index.js file, and replace the following line of code:

fb.auth.onAuthStateChanged(user => {
  if (user) {
    store.commit('setCurrentUser', user)

    // real-time updates from our notes collection
    **fb.notesCollection.orderBy('createdOn', 'desc').onSnapshot(querySnapshot => {**
      let notesArray = []

      querySnapshot.forEach(doc => {
        let note = doc.data()
        note.id = doc.id
        notesArray.push(note)
      })

      store.commit('loadNotes', notesArray)
    })
  }
})

With the following line of code:

fb.auth.onAuthStateChanged(user => {
  if (user) {
    store.commit('setCurrentUser', user)

    // real-time updates from our notes collection
    fb.notesCollection.where('authorId', '==', user.uid).orderBy('createdOn', 'desc').onSnapshot(querySnapshot => {
      let notesArray = []

      querySnapshot.forEach(doc => {
        let note = doc.data()
        note.id = doc.id
        notesArray.push(note)
      })

      store.commit('loadNotes', notesArray)
    })
  }
})

The code now fetches Note records that belong to the currently signed-in user!

Configure Authorization rules on Firebase

Previously in this series, I created the Database and opted for the Start in test mode. This mode allows anyone to read and write to the database for 30 days.

Now that we have authentication in place, let’s reassess the Cloud Firestore rules and allow only authenticated users to read, update, create and delete.

Follow the steps below to setup authorization on your Cloud Firestore:

Visit the Firebase console and login to your account.
Locate and click the Database menu item..
Click the Rules tab.

Replace the content there with:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, create, update, delete: if request.auth.uid != null
    }
  }
}

This rule targets any document in the current database and allows any requests that hold an auth object with an uid that’s not null. Only requests sent by an authenticated user, will carry a valid auth object.

That’s it! Pretty easy. Now we can be sure that anonymous requests won’t find their way into our database.

Add Logout button

Finally, let’s add support for a Logout button for the user.

Navigate to the components/Navbar.vue component, and insert the following inside the links section:

<div class="links">
      <a
        href="#"
        title="Logout"
        v-if="showLogout"
        @click="logout"
      ><span class="logout">Logout</span></a>
    </div>

Let’s implement the logout() function as follows:

async logout () {
      await fb.auth.signOut()
      this.clearData()
      this.$router.push('/login')
    },

The code calls the signOut() function on the Firebase Auth API to sign-out the user, and clear any local cookies or data related to the currently signed-in user.

In addition, it clears the data stored about the currently signed-in user inside the Vuex Store instance.

Finally, it redirects the user to the Login page.

Let’s add the clearData() action onto the Vuex Store instance. Navigate to the store/index.js file, and add the following action:

clearData ({ commit }) {
      commit('setCurrentUser', {})
      commit('loadNotes', [])
      commit('setNote', {})
    },

The action clears out the signed-in user, all loaded Notes records, and the current Note object.

Conclusion

We’re done! We’ve implemented user authentication in the Notes Writer app using Firebase Authentication API. The Firebase Authentication is rich in features, and offers more functionalities than we could possibly cover in this article. My suggestion: always refer to the Firebase Authentication docs website to learn more about the different options available.

In the next installment, we’ll make use of Firebase Cloud Functions to both extend the features of the Notes Writer app, and demonstrate the capabilities of the Cloud Functions.

Stay tuned!

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

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

SSR Finally a First-Class Citizen in Angular?

I am sure you've already heard about server-side rendering (SSR). Generally, it's a technique used to deliver the HTML content generated by the server to the client. The client-side JavaScript framework then hydrates that HTML content to provide a fully interactive application. SSR provides numerous benefits if used correctly, including improved initial load times, better content indexing by search engines, and improved performance on lower-tier devices. Driven by the need for faster, more efficient web applications, with the rise in popularity of Node.js and, thus, server-side JavaScript, SSR has become a de facto standard in modern web development frameworks. At first, SSR was being provided as a part of meta-frameworks like Next.js, Nuxt, or Analog.js. Then, React introduced React Server Components, which marked a significant milestone in the way we think about front-end development. We think of front-end frameworks as being effectively full-stack, and a purely SPA approach is falling out of favor. However, I'm willing to bet that if you're a developer focused mostly on Angular, you may not have heard as much about SSR as your React counterparts. For a long time, Angular has been mostly focused on the SPA approach, and while we had Angular Universal or Analog.js, it was not as widely adopted. And that makes sense, given that Angular was widely regarded as best suited for complex, interactive applications, such as SaaS products or internal company tools, where SEO and initial load times were not as critical as they are for consumer-facing applications. Nevertheless, we have been blessed with the so-called Angular Renaissance, which has, among other things, brought SSR to the forefront of Angular development with the @angular/ssr package. Let's look at what Angular SSR is, how it works, and how you can get started. @angular/ssr The @angular/ssr package is not new; it was written from scratch. It's still Angular Universal. However, it's been pulled into the Angular CLI repository, and the appropriate schematics have been added to make it easier to use. What that means is that you can now add SSR to your Angular application with a single command: ` and you can generate a new SSR application with: ` And to make SSR a first-class citizen, the Angular team is planning to make it the default in the next version. But surely, it's not only rebranding and some CLI commands, you may say. And you're right. You may remember that hydration in Angular Universal has not been optimal as it was destructive and required essentially a complete re-render of the application, thus pretty much negating the benefits of SSR. With the introduction of non-destructive hydration in Angular 16 and its stability in Angular 17, the Angular team has taken a significant step forward in making SSR a first-class citizen. How to Make an SSR-capable Angular Application Let's look at how to use Angular SSR in practice by creating a simple SSR app. First, we need to create a new Angular application with SSR support: ` That will generate a few server-specific files: - server.ts, which is an Express server configured to handle Angular SSR requests by default but can also be extended to handle API routes, or anything else that Express can handle. - src/app/app.config.server.ts provides configuration for the server application similar to your app.config.ts, which defines the configuration for your client application. Both export an instance of ApplicationConfig - src/main.server.ts bootstraps the server application in a similar way to what main.ts does for your client app by calling the bootstrapApplication function. You should have an SSR application ready just like that. You can verify that by running ng serve. The terminal output should show you information about the server bundles generated, and you should be able to see the default app when going to http://localhost:4200. Open the Developer Tools and check the console to see that hydration is enabled. You'll see a message with hydration-related stats, such as the number of components and nodes hydrated. Speaking of hydration... Client Hydration If you open the src/app/app.config.ts in your new SSR application, you'll notice one interesting provider: provideClientHydration(). This provider is crucial for enabling hydration - a process that restores the server-side rendered application on the client. Hydration improves application performance by avoiding extra work to re-create DOM nodes. Angular tries to match existing DOM elements to the application's structure at runtime and reuses DOM nodes when possible. This results in a performance improvement measured using Core Web Vitals statistics, such as reducing the Interaction To Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). Improving these metrics also positively impacts SEO performance. Without hydration enabled, server-side rendered Angular applications will destroy and re-render the application's DOM, which may result in visible UI flicker, negatively impact Core Web Vitals like LCP, and cause layout shifts. Enabling hydration allows the existing DOM to be reused and prevents flickering. Event Replay and Improved Debugging With Angular 18, event replay, a feature that significantly enhances the SSR experience, came into developer preview. Event replay captures user interactions during the SSR phase and replays them once the application is hydrated. This ensures that user actions, such as adding items to a cart, are not lost during the hydration process, providing a seamless user experience even on slow networks. To enable event replay, you can add withEventReplay to your provideClientHydration call: ` Furthermore, Angular 18 takes another step towards making SSR a first-class citizen by enhancing the debugging experience with Angular DevTools. Now, DevTools include overlays and detailed error breakdowns, empowering developers to visualize and troubleshoot hydration issues directly in the browser. Constraints However, hydration imposes a few constraints on your application that are not present without hydration enabled. Your application must have the same generated DOM structure on both the server and the client. The hydration process expects the DOM tree to have the same structure in both environments, including whitespaces and comment nodes produced during server-side rendering. Direct DOM Manipulation The fact that server and client DOM structures must match means that components that manipulate the DOM using native DOM APIs or use innerHTML or outerHTML will encounter hydration errors. The errors are thrown because Angular is unaware of these changes and cannot resolve them during hydration. Examples include accessing the document, querying for specific elements, and injecting additional nodes using appendChild. Detaching DOM nodes and moving them to other locations will also cause errors. Direct DOM manipulation is generally considered bad practice in Angular, so I recommend refactoring your components to avoid it regardless of hydration. However, in warranted cases where refactoring is not feasible, you can use the ngSkipHydration attribute until a hydration-friendly solution can be implemented. You can use it directly in a template: ` or as a host binding: ` > Note: The ngSkipHydration attribute forces Angular to skip hydrating the entire component and its children. So use this attribute carefully, as, for example, applying it to your root application component would effectively disable hydration for the entire application. Valid HTML Structure Another constraint is that invalid HTML structures in component templates can result in DOM mismatch errors during hydration. Common issues include: - without a - inside a - inside an - inside another Again, if you have an invalid HTML, you should fix this regardless of hydration. If you are unsure about your HTML's validity, you can use the W3 validator to check it. Zoneless apps or custom Zone.js Hydration relies on a signal from Zone.js when it becomes stable. Custom or "noop" Zone.js implementations may thus disrupt the timing of this event, triggering the serialization or cleanup process too early or too late. This configuration is not yet fully supported. While Zoneless is already available in developer preview and we could assume this issue will be resolved when it lands as stable, there is no explicit ETA mentioned in the official roadmap. I18n One of the biggest blockers for adoption of client hydration was the lack of support for internationalization with hydration. By default, Angular 17 skipped hydration for components that used i18n blocks, re-rendering them from scratch. In Angular 18, however, hydration for i18n blocks got into developer preview. To enable hydration for i18n blocks, you can add withI18nSupport to your provideClientHydration call. ` Third-Party Libraries with DOM Manipulation The last thing to consider is third-party libraries that manipulate DOM, such as D3 charts. They could cause DOM mismatch errors when hydration is enabled. You can use the ngSkipHydration attribute to skip hydration for components rendered using these libraries. Conclusion The Angular team has been doing great work to make the framework more modern and competitive, hearing the community feedback and adjusting the roadmap accordingly. And SSR is an excellent example of that. With the introduction of non-destructive hydration in Angular 16 and making it stable in Angular 17, the Angular team has taken a significant step forward in making SSR a first-class citizen in Angular. The @angular/ssr package is now part of the Angular CLI, making adding SSR to your Angular application easier. The Angular team plans to make SSR the default in the next version, further solidifying its position in the Angular ecosystem. However, as with any new feature, there are some constraints and best practices to follow when using SSR with Angular. You should be aware of hydration's limitations and ensure your application is compatible with it. However, if you follow the guidelines provided by the Angular team, you should be able to take advantage of the benefits of SSR without any significant issues....

Jun 26, 2024

8 mins

AngularJavaScriptExpress.js

Introducing the release of Vue 3

Back in October 2018, Evan You announced plans to start building the third version of VueJS. Featuring 30+ RFCs, over 2,600 commits, 628 pull request from 99 contributors, Vue 3's release reflects tireless ingenuity, passion, and hard work. Its release, no doubt, is a cause for celebration for all of the Vue community members who have been eagerly awaiting it. I, for one, am thrilled to share some resources that I believe will help developers migrate to Vue 3: - Vue 2 -> Vue 3 Migration Guide - Vue Router 3.0 -> Vue Router 4.0 Migration Guide - Vuex 4 - Chrome Vue JS DevTools - FireFox DevTools Here at This Dot, we have tracked Vue 3's development from the onset. We have written blog posts, published a book, hosted Vue Meetups, debuted JavaScript Marathon, shared Modern Web Podcasts, and more! Today, we’ll take a guided tour through all the material we have shared on Vue 2 and Vue 3. Blog Posts Here are our latest blog posts on Vue 3: - How to Set Up Storybook in Vue 3 - Async Components in Vue 3 - Your first Vue 3 app using TypeScript - Teleporting in Vue 3 - Content Distribution in Vue 3 - Custom Directives in Vue 3 - Vue 3 Composition API, do you really need it? You may access the remaining blog posts at This Dot Labs Blog. A Complete Guide to VueJS In April 2020, This Dot released A Complete Guide to VueJS by Bilal Haidar. This book is a precise, and detailed resource for learning VueJS, and highlights some top courses for Vue and JavaScript. Most importantly, it gives a brief introduction to almost all the new features in Vue 3. Grab your own copy for free! Vue Meetups We have hosted more than 10+ Vue Meetups in the past year with dozens of speakers, including Evan You, other Vue Core team members, and Vue developers interested in the future of the framework. To watch past meetup recordings, follow this link to get access to all the meetups on one page. JavaScript Marathon This Dot's team delivered six free live Vue JS tutorials during the JavaScript Marathon. Here’s a list of all the VueJS live sessions recordings: - 1 Hour to Learn Vue - Master State Management in Vue with VueX - Master PWA in Vue - Learning Unit Testing in Vue - Pro Tips on Using AWS with Vue - Debugging Vue: Quick Tips and Tricks Modern Web Podcasts This Dot's team delivered more than 40+ podcasts in the last two years. Here’s a link to the Vue JS Podcasts: - S07E1 Modern Web Podcast - Introducing Vite - Evan You’s new project + Vue 3 Updates - S06E12 Modern Web Podcast - Vue 3, Code Education, & the Vue Community - S06E4 Modern Web Podcast - Vue Updates with Chris Fitz, Jake Dohm, and Rob Ocel The Future of Vue The team at This Dot is hardly finished tracking Vue's progress, as well as the progress of many other web based technologies. To join us on our technical exploration journey, be sure to follow This Dot Media on Twitter! If you have specific questions about how to begin your Vue 3 migration, or have general questions about Vue 3, don't hesitate to reach out to us at hi@thisdot.co....

Sep 18, 2020

4 mins

VueJavaScriptWeb Development

Svelte 5 is Here!

Svelte 5 was finally released after a long time in development. Fortunately, we've been able to test it for some time, and now it has a stable release. Let's dig into its features and why this is such a significant change, even though Svelte 4 code is almost 100% compatible. Svelte syntax everywhere This is one of my favorite additions. Previously, Svelte syntax was limited to a component element. Refactoring code from a component and moving it to a JavaScript file worked differently. Now you can use the .svelte.js or .svelte.ts extension, which allows you to use the same syntax everywhere. It's important to note that it's a way to express that this is not just JS, and what you write may be compiled to something else, just like .svelte files are not just html even though they look very similar. Runes The introduction of runes is one of the most significant changes in Svelte. Many users felt attracted to variables being instantly reactive in previous versions. ` There was, however, a lot of magic underneath and a considerable amount of work from the compiler to make it behave reactively. $state In Svelte 5, a reactive variable has to be explicitly declared using the $state rune, which brings a clear distinction between what is reactive and what isn’t. ` In the previous code, $state is not an actual function being called; it's a hint for the compiler to do something special with this declaration. Rune names always start with a dollar sign ($) and do not need to be imported. However, there’s much more to the changes than just the way we declare reactive variables. Runes bring a lot of new features that make Svelte 5 a great improvement. In Svelte 5, objects or arrays use Proxies to allow for granular reactivity, meaning that individual properties in an object are reactive, even if they are nested objects or arrays. If you modify a property, it will only update that property and will not trigger an update on the whole object. It also supports triggering updates when methods like array.push are called. In previous versions, an assignment was required to trigger an update: ` To have a similar behavior of svelte 4 (no deep reactivity), use the $state.raw() rune. This syntax of .* is common for related features of a rune: $state.raw() will require an assignment to trigger reactivity. ` Because proxies are used, you may need to extract the underlying state instead of the proxy itself. In that case, $state.snapshot() should be used: ` $derived We will use $derived and $derived.by to declare a derived state. The two runes are essentially the same, except one allows us to use a function instead of an expression, allowing for more complex operations to calculate the derived values. ` $effect Effects are useful for running something triggered by a change in state. One of the things you'll note from the $effect rune is that dependencies don't need to be explicit. Those will be picked from reactive values read synchronously in the body of the effect function. ` Something to bear in mind is that these dependencies are picked each time the effect runs. The values read during the last run become the dependencies of the effect. ` Depending on the result of the random method, foo or bar will stop being a dependency of the effect. You should place them outside the condition so they can trigger reruns of the effect. *Variants* of the effect rune are $effect.pre, which runs before a DOM update, and $effect.tracking(), which checks for the context of the effect (true for an effect inside an effect or in the template). $props This rune replaces the export let keywords used in previous versions to define a component's props. To use the $props syntax, we can consider it to return an object with all the properties a component receives. We can use JavaScript syntax to destructure it or use the rest property if we want to retrieve every property not explicitly destructured.. ` $bindable If you want to mutate a prop so that the change flows back to the parent, you can use the $bindable prop to make it work in both directions. A parent component can pass a value to a child component, and the child component is able to modify it, returning the data back to the parent component. ` $inspect The $inspect rune only works in dev mode and will track dependencies deeply. By default, it will call console.log with the provided argument whenever it detects a change. To change the underlying function, use $inspect.with().with): ` $host The host rune gives access to the host element when compiling as a custom element: ` ` Other changes Another important change is that component events are just props in Svelte 5, so you can destructure them using the $props() rune: ` A special children property can be used to project content into a component instead of using slots. Inside the components, use the [@render[(https://svelte.dev/docs/svelte/@render) tag to place them. ` Optional chaining (?.) prevents from attempting to render it if no children are passed in. If you need to render different components in different places (named slots before Svelte 5, you can pass them as any other prop, and use @render with them. Snippets Snippets allow us to declare markup slices and render them conveniently using the render tag (@render). They can take any number of arguments. ` Snippets can also be passed as props to other components. ` ` Conclusion Some exciting changes to the Svelte syntax were introduced while, at the same time, maximum compatibility efforts were made. This was a massive rewrite with numerous improvements in terms of performance, bundle size, and DX. Besides that, a new CLI has been released, making the whole experience of starting a project or adding features delightful. If you haven't tried Svelte before, it's a great time to try it now....

Nov 27, 2024

4 mins

Svelte

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.

Firebase for user authentication in Vue.js

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

Firebase Authentication

Demo

Install Vue Router

Configure Vue Router and routes

Add Author ID on Note model

Integrate Authentication into the Vuex Store

Query for User’s own Notes only

Configure Authorization rules on Firebase

Add Logout button

Conclusion

Bilal Haidar

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

SSR Finally a First-Class Citizen in Angular?

Introducing the release of Vue 3

Svelte 5 is Here!

Let's innovate together!

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

SSR Finally a First-Class Citizen in Angular?

Introducing the release of Vue 3

Svelte 5 is Here!

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

Firebase Authentication

Demo

Install Vue Router

Configure Vue Router and routes

Implement Login view

Add Author ID on Note model

Integrate Authentication into the Vuex Store

Query for User’s own Notes only

Configure Authorization rules on Firebase

Add Logout button

Conclusion

Bilal Haidar

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

SSR Finally a First-Class Citizen in Angular?

Introducing the release of Vue 3

Svelte 5 is Here!

Let's innovate together!

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

SSR Finally a First-Class Citizen in Angular?

Introducing the release of Vue 3

Svelte 5 is Here!