Learning Vue 3 composables by creating an invoice generator

2025-01-06T00:00:00+00:00

The latest major version of Vue, Vue 3, has new features that are not present in Vue 2, such as Teleport, Suspense, and support for multiple root elements per template. Vue 3 provides smaller bundle sizes, better performance, better scalability, and better TypeScript IDE support.

What are Vue 3 composables?

Writing repetitive code can be a real pain in the frontend development realm. We can use Vue 3 composables to encapsulate and reuse stateful logic in our components. In this blog post, we will look at how we can use composables to reuse business logic by building an invoice generator.

An invoice generator, simply said, is an application that creates and manages invoices. We will focus on creating Vue 3 composables to properly separate business logic while reusing it across different features.

Core functionalities for invoice generator

Adding, editing, and removing invoices and items
Calculating totals with discounts, taxes, and shipping
Generating PDF invoices

To implement these functionalities, we’ll focus on:

Creating composables to handle business logic
Reusing this logic across features and components

Prerequisites

Basic understanding of:

Vue 3 and Composition API
JavaScript/TypeScript fundamentals

Tools:

Node.js and npm installed
Vite
Tailwind CSS (optional)

Setting up the project

First, initialize the Vue 3 project:

$ npm create vite@latest ep-invoice-generator
Need to install the following packages:
create-vite@6.0.1
Ok to proceed? (y) y
√ Select a framework: » Vue
√ Select a variant: » TypeScript

Scaffolding project in G:\PersonalWork\blog\ep-invoice-generator...

Done. Now run:

  cd ep-invoice-generator
  npm install
  npm run dev

Create folders for the project structure:

src/components/ for adding UI components
src/composables/ for adding composables
src/router/ for adding Vue Router routes
src/types/ for adding type definitions
src/views/ for adding pages to render based on Vue Router routes

Create first composable for invoice: `useInvoice`

The composable is named useInvoice.ts and it will serve the following purposes:

Handle data for invoice and invoice items
Add methods for adding, editing, and removing invoice items
Calculate totals automatically using item’s rate and amount as well as discount, tax, and shipping
Reset invoice

Define interfaces for `Invoice` and `InvoiceItem`

export interface InvoiceItem {
    id: number,
    description: string,
    rate: number,
    quantity: number,
}

export interface Invoice {
    logo: string,
    name: string,
    number: number,
    ponumber: string,
    date: string,
    duedate: string,
    sender: string,
    buyer: string,
    items: InvoiceItem[];
    notes: string,
    terms: string,
    discount: {
        isUsed: boolean,
        isPercentage: boolean,
        value: number,
    },
    tax: {
        isUsed: boolean,
        isPercentage: boolean,
        value: number,
    },
    shipping: {
        isUsed: boolean,
        value: number,
    },
    total: number,
    paid: number,

    sentToContact: boolean,
    status: Status,
}

First we make an Invoice object to create and edit an invoice. The code state.storage.value.currentInvoiceNumber gets the current invoice number to use for the new invoice, we will learn more about it later.

We return the object containing the required data and methods that can be used by any single-file component (SFC). We will see the implementation of computed properties and methods in the next section.

export function useInvoice(invoiceId?: number) {

    const invoice = reactive<Invoice>({
        logo: "",
        name: "",
        number: state.storage.value.currentInvoiceNumber,
        ponumber: "",
        date: format(date, "yyyy-MM-dd"),
        duedate: "",
        sender: "",
        buyer: "",
        items: [
            {
                id: 1,
                description: "",
                rate: 0,
                quantity: 0,
            },
        ],
        notes: "",
        terms: "",
        discount: {
            isUsed: false,
            isPercentage: false,
            value: 0,
        },
        tax: {
            isUsed: false,
            isPercentage: false,
            value: 0,
        },
        shipping: {
            isUsed: false,
            value: 0,
        },
        total: 0,
        paid: 0,
        sentToContact: false,
        status: Status.Draft,
    });

    const subtotal = computed(() => ...)
    const afterDiscount = computed(() => ...)
    const afterTax = computed(() => ...)
    const afterShipping = computed(() => ...)
    const total = computed(() => ...)
    const balance = computed(() => ...);

    const updateLineItem = (value: InvoiceItem, index: number) => ...);
    const addLineItem = () => ...)
    const removeLineItem = (index) => ...)

    return {
        // data helpers
        invoice,
        subtotal,
        afterDiscount,
        afterTax,
        afterShipping,
        total,
        balance,

        // Methods
        addLineItem,
        updateLineItem,
        removeLineItem,
    }
}

Adding business logic

Now we implement the business logic for various methods — adding an invoice item, updating an invoice item, etc. — as well as calculating the various dynamic amounts.

The following methods add an invoice item to the invoice as a line item, which can be rendered on the UI. Then, the user can update the line item’s rate and quantity, which calls updateLineItem to update the invoice item data.

/**
 * Add a line item to the invoice line items array
 */
const addLineItem = () => {
    invoice.items.push({
        id: invoice.items.length + 1,
        description: "",
        rate: 0,
        quantity: 0,
    });
};

/**
 * @param {invoice line item} value
 * @param {index of invoice line item} index
 * @returns
 */
const updateLineItem = (value: InvoiceItem, index: number) => (invoice.items[index] = { ...value });

/**
 * Remove items from invoice items array
 * @param {*} index index of item to remove
 */
const removeLineItem = (index) => {
    invoice.items.splice(index, 1);
};

Based on the invoice item data, we then calculate:

subtotal
subtotal after discount, if available
subtotal after tax, if available
subtotal after shipping, if available

Moreover, discount and tax can be stored as an amount or as a percentage value, so we update the logic to evaluate discount and tax based on the type of the entered values and calculate the subtotal. We can also include a previously overpaid amount and calculate the balance at the end of the calculations.

// useInvoice.ts
const subtotal = computed(() =>
    invoice.items.reduce((prev, acc) => prev + acc.rate * acc.quantity, 0)
);

/**
 * Compute total value after applying discount
 * based on `discount` percentage or value and `subtotal` value
 */
const afterDiscount = computed(() => {
    if (invoice.discount.isUsed) {
        if (invoice.discount.isPercentage) {
            return subtotal.value - (subtotal.value * invoice.discount.value) / 100;
        } else {
            return subtotal.value - invoice.discount.value;
        }
    }
    return subtotal.value;
});

/**
 * Compute total value after applying tax
 * based on `tax` percentage or value and `afterDiscount` value
 */
const afterTax = computed(() => {
    if (invoice.tax.isUsed) {
        if (invoice.tax.isPercentage) {
            return (
                afterDiscount.value + (afterDiscount.value * invoice.tax.value) / 100
            );
        } else {
            return afterDiscount.value + invoice.tax.value;
        }
    }
    return afterDiscount.value;
});

/**
 * Compute total value after applying shipping
 * based on `shipping` value and `afterTax` value
 */
const afterShipping = computed(() => {
    if (invoice.shipping.isUsed) {
        return afterTax.value + invoice.shipping.value;
    }
    return afterTax.value;
});

const total = computed(() => {
    return afterShipping.value;
});

// later if we track the payment done for the clients, we can easily
// come up with the balance based on the payment and invoices
const balance = computed(() => total.value - invoice.paid);

Rendering the invoice with composable functions

We create the InvoiceGenerator.vue SFC, utilizing the useInvoice composable we created. We use the <script setup> syntax for importing and using the composable. <script setup> help us use Composition API inside SFCs instead of the Options API. Using the <script setup> syntax removes boilerplate code while providing the ability to declare props, emitted events, and many more advantages.

<!-- InvoiceGenerator.vue-->
<script setup>
import { useInvoice } from "../composables/useInvoice";

const {
  // data
  invoice,

  // computed / read only
  subtotal,
  total,
  balance,

  // methods
  addLineItem,
  updateLineItem,
  removeLineItem,
  resetInvoice
} = useInvoice(
</script>

I have already defined the LineItems.vue component, where we render the line items which have text boxes to enter description, rate, and amount. The totals for each item are calculated using the computed property. Let’s see an example showing how we can use it with invoice items:

Use items prop to render the invoice items
Emit update-item event when any value for an invoice line item changes
Emit add-item when user adds a new line item
Emit close when user removes a line item

<LineItems
    :items="invoice.items"
    @update-item="updateLineItem"
    @close="removeLineItem"
    @add-item="addLineItem"
    />

Similarly, we use invoice.discount, invoice.tax, and invoice.shipping properties from the composable in a text box where the user can enter the value and type of the value. All of them have helper properties named isUsed and isPercentage, which we use to make the input box user-friendly. The CustomInput, CustomToggleSwitch and WithLabel are three custom components that are already created and they can be used as follows:

<WithLabel label="Discount">
    <CustomInput
        v-model.number="invoice.discount.value"
        is-used
        label="Discount"
        toggle
        :currency="!invoice.discount.isPercentage"
        @close="invoice.discount.isUsed = false"
    >
        <CustomToggleSwitch
        v-model="invoice.discount.isPercentage"
        :for-value="'invoice-discount'"
        />
    </CustomInput>
</WithLabel>

<WithLabel label="Tax">
    <CustomInput
        v-model.number="invoice.tax.value"
        is-used
        label="Tax"
        toggle
        :currency="!invoice.tax.isPercentage"
        @close="invoice.tax.isUsed = false"
    >
        <CustomToggleSwitch
        v-model="invoice.tax.isPercentage"
        :for-value="'invoice-tax'"
        />
    </CustomInput>
</WithLabel>

<WithLabel label="Shipping">
    <CustomInput
        v-model.number="invoice.shipping.value"
        label="Shipping"
        is-used
        currency
        @close="invoice.shipping.isUsed = false"
    >
    </CustomInput>
</WithLabel>

All other properties can also be rendered, but we would like some input fields, like PO Number, Invoice Date, and Amount Paid to be rendered differently. Using custom components like CustomInput and CustomToggleSwitch can help us get more control of the visual and functional aspects of the UI component.

<WithLabel label="PO Number">
    <CustomInput
    v-model="invoice.ponumber"
    label="PO Number"
    type="text"
    />
</WithLabel>

<WithLabel label="Date">
    <CustomInput
    v-model="invoice.date"
    label="Date"
    type="date"
    />
</WithLabel>

<WithLabel label="Amount Paid">
    <CustomInput
    v-model.number="invoice.paid"
    label="Amount Paid"
    currency
    />
</WithLabel>

Create a second composable for using localStorage to save and retrieve invoice data

The useInvoice composable only gives us the invoice data along with computed properties, but now we have to save it somewhere so we can use it later. We can use localStorage to save the invoices. VueUse is a very good library that has a collection of Vue composition utilities that can be used with Vue 2 as well as Vue 3.

For accessing localStorage reactively, we will use a composable from VueUse called useStorage, which uses localStorage by default. We will define saveInvoice, updateInvoice, deleteInvoice, and findInvoices methods that use the reactive variable from useStorage to perform the required operations.

We will create another composable called useInvoiceStorage.ts, where we initialize our storage using useStorage, which also stores the current invoice number.

// useInvoiceStorage.ts

const storage = useStorage<InvoiceStore>('invoice-store', {
    currentInvoiceNumber: 10000,
    invoices: {}
}, localStorage);

Then we define and implement the methods discussed above for saving, updating, deleting, and finding invoices. The update of the current invoice number happens in the saveInvoice method.

// useInvoiceStorage.ts

export default function useState() {
    const state = reactive(storage);

    function saveInvoice(invoice: Invoice) {
        state.value.invoices[invoice.number] = { ...invoice };
        state.value.currentInvoiceNumber = invoice.number + 1;
    }

    function updateInvoice(invoice: Invoice) {
        state.value.invoices[invoice.number] = { ...invoice };
    }

    function deleteInvoice(invoiceId: number) {
        state.value.invoices = Object.keys(state.value.invoices)
            .filter(x => x != invoiceId.toString())
            .reduce((acc, curr) => {
                return {
                    ...acc,
                    [curr]: state.value.invoices[curr]
                }
            }, {})
    }

    function findInvoices(searchText: string) {
        searchText = searchText.toLowerCase();
        return Object.keys(state.value.invoices).filter(x => {
            const invoice = state.value.invoices[x];
            return invoice.number.toString().indexOf(searchText) > -1
                || invoice.buyer.toString().toLowerCase().indexOf(searchText) > - 1
                || invoice.date.toString().toLowerCase().indexOf(searchText) > - 1
                || invoice.total.toString().indexOf(searchText) > - 1
        })
            .map(x => ({ ...state.value.invoices[x] }))

    }
    return {
        // variables
        storage: state,

        // methods
        saveInvoice,
        updateInvoice,
        deleteInvoice,
        findInvoices
    }
}

Now, we can use data and methods from the useInvoiceStorage composable to show the latest invoice number as well as save, update, delete, and find invoices. The composable useInvoice also uses useInvoiceStorage to set the current invoice number for the new invoice. Whenever a user creates a new invoice, the current invoice number is automatically assigned to the invoice obtained from the useInvoiceStorage composable.

Moreover, the useInvoice composable is updated to support the new invoice and edit invoice features. Support for editing an invoice is achieved by passing invoiceId to the useInvoice composable, the invoiceId is then checked in the storage returned by useInvoiceStorage, if the invoice exists, the useInvoice composable returns the correct invoice data from storage.

The following code checks for the invoice in the storage:

// If the invoice is already in storage, use it
if (invoiceId) {
    const invoiceToUse = state.storage.value.invoices[invoiceId];
    if (invoiceToUse) Object.assign(invoice, invoiceToUse);
}

Printing Invoice

For printing invoices, we can simply use print styles from Tailwind CSS to style the elements that we want to print. A simple example is the CustomButton component in the source code. We don’t want to show any buttons on the PDF, so we use the Tailwind CSS style print:hidden to hide the buttons on the print view. We then need to call the method below on the invoice page to print the current page.

const print = () => window.print();

Bonus: create a third composable for showing dashboard data

The dashboard is important for looking at the high-level data and is crucial to any application. So, we add a new composable called useDashboardData.ts that will give us the total invoice amount, total paid amount, total due amount, and total drafted amount. It can be further expanded to include any other business logic as well. We will again use the useInvoiceStorage composable to get the list of invoices.

// useDashboardData.ts
import useState from "./useInvoiceStorage";
import { Status } from "../types/index.type";

export function useDashboardData() {
    const state = useState();

    const totalInvoiceAmount = computed(() => {
        const invoices = state.storage.value.invoices;
        const amount = Object.keys(invoices).reduce((acc, item) => acc + invoices[item].total, 0);
        return amount.toFixed(2)
    })

    const totalPaid = computed(() => {
        const invoices = state.storage.value.invoices;
        const amount = Object.keys(invoices).reduce((acc, item) => {
            if (invoices[item].status === Status.Paid) {
                return acc + invoices[item].total
            }
            return acc;
        }, 0);
        return amount.toFixed(2);
    })

    const totalDue = computed(() => {
        const invoices = state.storage.value.invoices;
        const amount = Object.keys(invoices).reduce((acc, item) => {
            if (invoices[item].status === Status.Overdue) {
                return acc + invoices[item].total
            }
            return acc;
        }, 0);
        return amount.toFixed(2);
    })

    const totalDrafted = computed(() => {
        const invoices = state.storage.value.invoices;
        const amount = Object.keys(invoices).reduce((acc, item) => {
            if (invoices[item].status === Status.Draft) {
                return acc + invoices[item].total
            }
            return acc;
        }, 0);
        return amount.toFixed(2);
    })

    return {
        // variables
        totalInvoiceAmount,
        totalPaid,
        totalDue,
        totalDrafted
    }
}

After that we create the Dashboard.vue component to use data from useDashboardData.ts and display the data on the dashboard. We can keep adding business logic to useDashboardData.ts to display data on the dashboard, and we can use it elsewhere to support other business logic.

<!-- Dashboard.vue -->
<template>
    <section class="max-w-[1800px] mx-auto">
        <div class="grid grid-cols-4 gap-x-4 mt-4">
            <Card>
                <template #header>Total Amount</template>
                <span>${{ totalInvoiceAmount }}</span>
                <template #footer></template>
            </Card>
            <Card>
                <template #header>Paid Amount</template>
                <span>${{ totalPaid }}</span>
                <template #footer></template>
            </Card>
            <Card>
                <template #header>Due Amount</template>
                <span>${{ totalDue }}</span>
                <template #footer></template>
            </Card>
            <Card>
                <template #header>Drafted Amount</template>
                <span>${{ totalDrafted }}</span>
                <template #footer></template>
            </Card>
        </div>
        <Invoices />
    </section>
</template>

<script setup lang="ts">
import Card from '../components/shared/Card.vue';
import { useDashboardData } from '../composables/useDashboardData';
import Invoices from './Invoices.vue';

const { totalInvoiceAmount, totalPaid, totalDue, totalDrafted } = useDashboardData();
</script>

The source code is available at GitHub.

An application demo is also available.

Next Steps

Use a REST API for saving the invoices to the database
Use Pinia to store the retrieved invoices so we can easily use the invoices
Add a composable to switch between different types of templates for printing PDFs

Conclusion

We learned about Vue 3 composables and how to use Composition API to create composables. We saw how composable functions are a game changer for building complex, maintainable, and scalable applications by encapsulating the business logic, organizing the code, and making it reusable. It helps to simplify the process and boost productivity.

Introduction to Nuxt3 and Rendering Modes

2024-07-12T00:00:00+00:00

Nuxt is a free and open-source framework which helps us build performant full-stack web applications and websites with Vue.js. Nuxt is built on top of Vue, so it is also called a meta-framework. Nuxt uses conventional style directory structure to streamline repetitive tasks and allow developers to focus on more important operational tasks. The configuration file can be used to customize the default behaviors.

Nuxt3 features

File-based routing. Nuxt generates routes based on the Vue files and folder structure within the pages/ directory. For example, if we have a pages/contact.vue file, Nuxt will generate a corresponding route at /contact. It also supports dynamic routing: pages/product/[sku].vue includes the route /product/APPLE, giving the [sku].vue single-file component access to the value APPLE.
Auto-imports. Components, composables, and helper functions have their respective directories which can be used across the project without importing them. This feature enhances the developer experience by removing the long list of imports. Nuxt also supports automatic importing of Vue APIs. It can be configured to import third-party packages using the nuxt.config file. Auto import can also be disabled using nuxt.config.
Server-side rendering. Nuxt has built-in server-side rendering (SSR) support, without having to configure the server. It has benefits such as loading pages quickly, improved search engine optimization, caching, and many more. We will talk more about other rendering methods later.
Data-fetching utilities. Nuxt provides composables to handle SSR-compatible data fetching as well as different strategies.
TypeScript support. Nuxt3 fully supports TypeScript.
Modules. Nuxt provides a module system to extend the framework core and simplify integrations.

Rendering Modes

The process of interpreting JavaScript code to convert Vue components to HTML elements is called rendering. This can happen both in the browser and the server. Nuxt supports the following rendering modes and we will discuss them more in detail:

1. Universal Rendering (SSR + CSR)

This is the default rendering mode which provides a great user experience, good performance, and optimized search engine indexing. The rendering mode can be switched by changing the ssr value in nuxt.config.

In this mode, the server returns a fully rendered HTML page to the browser on request. Nuxt runs the Vue code in the server, which produces HTML content. Users get the content of web application which can be displayed in browser.

After the page is loaded from the server, the browser loads the JS code to make content interactive and dynamic. The browser re-interprets the Vue code to enable interactivity. This process of making a page interactive in the browser is called “hydration”.

Universal rendering provides quick page load times while preserving the benefits of client-side rendering. It enhances SEO because HTML content is already present for crawling.

Pros:

Performance. Browsers display static content faster, hence users can see the page content almost immediately. Nuxt also preserves the interactivity of the web application using hydration.
SEO. Web crawlers can index the page’s content easily as universal rendering delivers the entire HTML content of the page to the browser.

Cons:

Development constraints. Some APIs don’t work in both the browser and the server; for example, the window object is only available in the browser, so it can’t be accessed on the server. It can be time consuming to write code that runs on both sides. Nuxt does provide guidelines and variables to help with this.
Cost. Unlike hosting static files, universal rendering requires a server to generate the full HTML content. Using a server adds cost.

2. Client-Side Rendering (CSR)

A traditional Vue application loads the JavaScript code on the browser first, then interprets the code to generate the HTML elements and interface.

Pros:

Development speed. Writing client-side-only code improves development speed as we don’t have to worry about supporting server-side compatibility.
Cheaper. The code can be hosted on a simple web server without the need for a application server, and can run in the browser, reducing the server-side cost.
Offline. Once the JavaScript has been sent to the client, the code only runs in the browser. This means the web application can keep working even if there is no internet.

Cons:

Performance. Because the browser has to first download files and then run JavaScript files to generate the HTML document, the page can be slow to load initially. This depends on the network download speed as well as the performance of the user’s device for executing the JS code. This negatively affect page load times and user experience.
SEO. Crawlers takes more time indexing and updating the content delivered. Based on the above performance drawback, the crawler may not wait until the interface is fully rendered, and will report slower load speeds.

Client-side rendering is the preferred choice for heavy interactive web applications such as SaaS and back-office applications that don’t require indexing.

Enabling client-side only rendering with Nuxt can be done by updating nuxt.config:

export default defineNuxtConfig({
  ssr: false
})

3. Hybrid Rendering

Hybrid rendering allows different caching rules per route using Route Rules which can dictate the server response for each new request.

Without hybrid rendering all the routes/pages of the application use the same rendering mode—either universal or client-side.

With hybrid rendering, some pages which have static content can be generated at build time while pages which have dynamic content (e.g. dashboard or orders pages) can be generated client-side.

Nuxt3 provides a way to support hybrid rendering using routeRules in nuxt.config:

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true }, // Pre-render or SSG
    '/country': { ssr: false }, // CSR (SPA)
    '/university': { ssr: false }, // CSR (SPA)
    '/isr/country': { isr: true }, // ISR without TTL
    '/isr/university': { isr: 60 }, // ISR with TTL
    '/swr/country': { swr: true }, // SWR without TTL
    '/swr/university': { swr: 60 }, // SWR with TTL
    '/prerender/country': { prerender: true }, // Pre-render or SSG
    '/prerender/university': { prerender: true }, // Pre-render or SSG
  }
)

Routes can have various properties such as:

ssr. This is used to disable or enable server-side rendering for the given route. It can be used to make SPA app like dashboard and orders page for serving dynamic content with ssr: false.
swr. SWR means state-while-revalidate. This is a caching technique which enables the server to provide cached data for a configurable Time to live (TTL). We can define a time value in seconds, which is used to set TTL, or just pass true, which sets the TTL with maximum age. Without TTL, the response is cached until there is change in the content. With TTL, the response is cached until the TTL expires. The response of the page upon first request is generated and cached.
isr. This stands for “incremental static regeneration.” It is similar to swr, with the main difference being that the response is cached on the CDN. It can also be configured with TTL and without TTL.
prerender. This generates pages based on routes at build time and serves them as static pages.

There are many more properties that we can use to define how each route will act.

I’ve created a demo app showing hybrid rendering. This app shows list of countries and universities with details pages.

The /country and /university routes are defined as single-page applications (SPA—this means they use client-side rendering). We can see that the time on the server and the time on the client are almost same, with the difference being hydration time.
The /prerender/country and /prerender/university routes are defined as prerendered or static-site generated (SSG), which means the pages are generated at build time. The server time shows the time when the build was run to generate the pages, and does not change.
The /prerender/country/{countries starting from a to m} routes are defined as prerendered, which means the countries whose name starts with a to m are generated at build time. We can browse any of the prerendered country pages, like /prerender/country/Canada, where we see that the server times are build times. However, if we browse a country page which isn’t prerendered, like /prerender/country/Nigeria, we see that server times are the same as browser times.
The /isr/country, /isr/country/**, /swr/country/**, and /swr/country routes are defined as ISR and SWR respectively, with the maximum TTL set. These pages will serve cached content until the response changes.
The /isr/university, /isr/university/**, /swr/university/** and /swr/university routes are defined as ISR and SWR with a TTL of 120 seconds. This means that when first browsed, the pages will serve the initial response and cache it for 2 minutes.

You can see the code for the demo app on GitHub.

Passing Data Between Components in Vue.js: An Overview

2024-04-03T00:00:00+00:00

Artwork: Still Life with Artichokes and a Parrot, 17th century, Italian. CC0.

Vue.js, with its simplicity and flexibility, is one of the most popular JavaScript frameworks on the web. One of the key aspects of building dynamic and interactive web applications with Vue is efficiently passing data between components. In this blog post, we will explore methods and good practices for data communication between Vue components.

Props

Usage

Directional data flow: Props are primarily used for establishing a unidirectional flow of data from parent components to child components — they allow parents to pass data down to their children.

Pros:

Simplicity: Props provide a simple and straightforward mechanism for passing data.

Cons:

One-Way Binding: It’s a one-way data binding mechanism, meaning that data flows from parent to child only, not from child to parent.

// ParentComponent.vue
<template>
  <ChildComponent :data-prop="parentData" />
</template>

<script>
export default {
  data() {
    return {
      parentData: "Hello from parent!",
    };
  },
};
</script>

// ChildComponent.vue
<template>
  <div>{{ dataProp }}</div>
</template>

<script>
export default {
  props: ['dataProp'],
};
</script>

Custom Events: Emitting Changes from Child to Parent

Usage:

Child to Parent Communication: Custom events are useful when a child component needs to communicate changes or send data back to its parent component.

Pros:

Bidirectional Communication: Enables two-way communication between parent and child components.
Flexibility: Allows children to notify parents about specific events or changes.

Cons:

Limited Scope: Best suited for parent-child relationships; might become cumbersome in complex component hierarchies.

// ChildComponent.vue
<template>
  <button @click="emitData">Send Data to Parent</button>
</template>

<script>
export default {
  methods: {
    emitData() {
      this.$emit('child-event', 'Data from child!');
    },
  },
};
</script>

// ParentComponent.vue
<template>
  <ChildComponent @child-event="handleChildEvent" />
</template>

<script>
export default {
  methods: {
    handleChildEvent(data) {
      console.log('Received data from child:', data);
    },
  },
};
</script>

EventBus: A Centralized Event Hub

Usage:

Non-Parent-Child Communication: EventBus provides a centralized event hub that allows components not directly related in a parent-child hierarchy to communicate.

Pros:

Flexibility and Decoupling: Components can emit and listen for events without tight coupling, enhancing flexibility.
Global Communication: Suitable for scenarios where communication needs to happen across various components.

Cons:

Global Scope: Might lead to unintended side effects if events are not managed carefully.

// EventBus.js
import Vue from 'vue';
export const bus = new Vue();

// ChildComponent.vue
<template>
  <button @click="emitData">Send Data to Anywhere!</button>
</template>

<script>
import { bus } from '../EventBus';

export default {
  methods: {
    emitData() {
      bus.$emit('customEvent', 'Data from child!');
    },
  },
};
</script>

// AnyComponent.vue
<template>
  <div>{{ receivedData }}</div>
</template>

<script>
import { bus } from '../EventBus';

export default {
  data() {
    return {
      receivedData: '',
    };
  },
  created() {
    bus.$on('customEvent', (data) => {
      this.receivedData = data;
    });
  },
};
</script>

Vuex: State Management for Larger Applications

For more complex applications, especially those with multiple components sharing state, Vuex is the recommended solution. Vuex is Vue’s official state management library, providing a centralized store for managing application-level state.

// store.js
import Vue from 'vue';
import Vuex from 'vuex';

Vue.use(Vuex);

export default new Vuex.Store({
  state: {
    sharedData: 'Shared state data!',
  },
  mutations: {
    updateData(state, newData) {
      state.sharedData = newData;
    },
  },
});

// AnyComponent.vue
<template>
  <div>{{ sharedData }}</div>
</template>

<script>
import { mapState } from 'vuex';

export default {
  computed: {
    ...mapState(['sharedData']),
  },
};
</script>

While Vuex is a powerful state management solution, it’s not always necessary for every Vue.js application. Here are some scenarios where you should consider using Vuex:

Large and Complex Applications: Vuex becomes more valuable as your Vue.js application grows in size and complexity. If your application has numerous components that need to share and synchronize state, managing the state centrally with Vuex can greatly simplify the development process.
Shared State Between Components: When multiple components need access to the same state data, prop drilling (passing data through multiple layers of components) can become unwieldy. Vuex provides a centralized store, eliminating the need for complex and deep prop chains.
Predictable State Management: If you require a clear and predictable pattern for managing state changes, mutations in Vuex provide a straightforward and traceable way to update the state. This is especially beneficial in applications where understanding and debugging state changes are crucial.
Asynchronous Operations: If your application involves asynchronous operations, such as fetching data from an API or handling complex workflows, Vuex actions provide a structured way to handle these operations and update the state accordingly.
Reusable and Composable Code: If you want to create modular and reusable code, Vuex allows you to define actions, mutations, and getters in a centralized store. This makes it easier to maintain and extend your application as new features are added.
Consistent State Across Components: In scenarios where maintaining consistent state across multiple components is crucial, using Vuex ensures that modifications to the state are handled in a controlled and synchronized manner.
Testing Requirements: If your application requires extensive unit testing for state-related logic, Vuex provides a structured architecture that makes it easier to test mutations, actions, and getters in isolation.

By understanding and utilizing props, custom events, EventBus, and Vuex, you can effectively manage and communicate data in your Vue.js applications. Choose the approach that best fits your project’s requirements, keeping in mind the scalability and maintainability of your code.

Building Ecommerce Search Using Algolia

2023-10-12T00:00:00+00:00

A common request that developers receive when embarking on a new website project is for the website to have “Google-like search.” For many years, this meant writing custom code to replicate the intelligent and user-friendly aspects of Google search, which was no easy feat. However, now we have many search-as-a-service offerings that do the hard work for us and make this process much easier.

In this blog post, we’ll dive into one of these search-as-a-service platforms, Algolia. We recently worked on an ecommerce website and used Algolia in an interesting way, both as a search engine and as a lightweight backend database to hold product data managed in Salesforce. Algolia worked beautifully, offering users fast and accurate search results, and also allowing us to launch the site within a relatively short time frame.

We will look at how to load Algolia with data, configure search options, and connect the search to the frontend using Algolia’s Vue library.

Loading the index with data

To start using Algolia’s search, you need to load up an index with data. You have the option of manually uploading a JSON file, or using Algolia’s API to programmatically load records. For our backend, we chose to use Algolia’s JavaScript API client in some lightweight TypeScript scripts that are triggered by cron. These scripts allowed us to sync inventory data between Salesforce and the index in Algolia.

Using the Algolia JavaScript client is quite simple. Regardless of where your data comes from—be it in a database, a platform like Salesforce, or elsewhere—once it is in JSON format, you can load it into Algolia with a few lines of code:

import * as algolia from "algoliasearch";

const products = [{
    name: "Fender F-5 Acoustic",
    make: "Fender",
    model: "F-5",
    category: "Guitars",
    status: "Used",
    objectID: "Fender-001"
  }, {
    name: "Fender Player Jaguar",
    make: "Fender",
    model: "Jaguar (Player)",
    category: "Guitars",
    status: "New",
    objectID: "Fender-002"
  }];


const index = algolia.default(process.env.ALGOLIA_APP_ID, process.env.ALGOLIA_API_KEY).initIndex("store_products");
await index.saveObjects(products);

Note the objectID property, which is used by Algolia as a primary key. If the objectID does not exist, a new record will be created. If it does exist, the record will be updated. This makes it easy to run a data sync process using a single saveObjects command, without having to worry about differentiating between create and update operations.

Configuring the index

Once you have your index loaded, you’ll want to configure it. Algolia does a good job of walking you through this process using a built-in tutorial when you first load your index. Basically, you will be selecting the searchable properties/attributes from your JSON data, setting how results are ranked and sorted, and adjusting more advanced aspects of search like typo tolerance, stop words, etc.

An important feature we utilized on our recent project is faceting. Faceting allows users to easily drill down and refine search by categories, and is also easy to develop using the handy frontend libraries that Algolia provides (more on that in the next section). This feature is powerful and can be used to both refine search and drive homepage category/subcategory links. When you configure your index, you can select which attributes of your data should be used for faceting.

Setting up search on the frontend

We used Nuxt to build the frontend of the website, and we leveraged Algolia’s Vue InstantSearch library for the UI. This library really speeds along development, as it wraps all of the search-related functionality in simple widgets, providing the search bar, results, refinements, filtering, and more.

The ais-instant-search widget is the parent widget. It serves the search state to its children, which allows you to show the search bar, search hits, hierarchical menus, etc. Here is a simple example of the ais-instant-search widget with a search bar and hits (pulled directly from Algolia’s Vue docs):

<template>
  <ais-instant-search :search-client="searchClient" index-name="demo_ecommerce">
    <ais-search-box />
    <ais-hits>
      <template v-slot:item="{ item }">
        <h2>{{ item.name }}</h2>
      </template>
    </ais-hits>
  </ais-instant-search>
</template>


<script>
import algoliasearch from 'algoliasearch/lite';
import 'instantsearch.css/themes/algolia-min.css';


export default {
  data() {
    return {
      searchClient: algoliasearch(
        '[Your app ID]',
        '[Your API key]'
      ),
    };
  },
};
</script>


<style>
body {
  font-family: sans-serif;
  padding: 1em;
}
</style>

I mentioned faceting above when discussing how to configure your index. Once you have selected the attributes in your JSON data that can be used for faceting (e.g., category, subcategory), you can feed those attributes to the ais-hierarchical-menu widget for display on the frontend.

Here is a bit of sample code from the website we built, which offers expandable category refinement via ais-hierarchical-menu.

<div class="sidebar-segment">
  <p class="sidebar-segment-title">Category</p>
  <ais-hierarchical-menu
    :limit="100"
    :attributes="categoryAttrs"
    :sort-by="hierarchicalMenuSort"
  >
    <div slot-scope="{ items, refine, createURL }">
      <hierarchical-menu-list
        :items="items"
        :refine="refine"
        :create-url="createURL"
      />
    </div>
  </ais-hierarchical-menu>
</div>

Above, we are using the limit property to set the maximum number of items to 100. The attributes property, which targets the JSON attributes in your index data that represent your categories, is set to the following:

categoryAttrs: ['categories.lvl0', 'categories.lvl1', 'categories.lvl2'],

These represent the three levels of categories in our data (zero-based), and are used to build the hierarchical menu.

Finally, the sort-by attribute points to a simple function that uses the JavaScript localeCompare method to provide alphanumeric sorting:

function hierarchicalMenuSort(a, b) {
  return a.name.localeCompare(b.name, undefined, {
    numeric: true,
    sensitivity: 'base',
  })
}

Wrapping up: seeing Algolia in action

If you’d like to see Algolia in action on the site that we built, head over to eiffeltrading.com. If you search the site, you’ll see autocomplete, fast results (thanks to both Algolia and Nuxt), and other aspects of good search that we have all come to expect from modern ecommerce sites.

Next time you are faced with a build involving full-text search, consider search-as-a-service offerings like Algolia. They could save you time and headaches over rolling your own search functionality. Sometimes it’s good to let others do the hard work!

Have questions or feedback on the topic? Let us know in the comments section below.

Upgrade Vue to TypeScript

2023-08-28T00:00:00+00:00

It’s important to keep your code up to date so that time can be dedicated to improving an application instead of version-related mishaps. This is especially true for web development as the landscape changes so quickly.

I recently upgraded a Vue project to exclusively use Vuex. This was a great opportunity to also upgrade the project from JavaScript to TypeScript. This article will cover the steps I took.

Some of the changes can be difficult to understand if you are not familiar with TypeScript. I recommend reading the TypeScript Handbook to become more familiar.

Several features of Vue, originally written in JavaScript without types, are hard to convert to TypeScript. These include this.$parent, this.$refs, and this.$emit. These allow you to access the parent component, child components, and emit events respectively. We will make changes to these features along with adding types to the global state handler provided by Vuex.Store.

Installation

Before you begin, make sure the necessary dependencies are installed:

~$ vue add typescript

Also make sure that Vuex is installed:

~$ yarn add vuex@next

Convert your component files

There are several changes that must be made to component files, such as App.vue.

Add lang="ts" to the <script> tag.
Replace the default export with a class that extends Vue and uses the @Component decorator.
Replace props with class properties marked with the @Prop decorator.
Replace data with individual class properties.
Add a typed $refs class property.
Replace computed with getter and setter class properties.
Lifecycle hooks simply become class methods, so they can be copied directly.
Replace methods with individual class methods.
Replace this.$emit with class methods using the @Emit decorator.

Let’s look at each change separately.

Add `lang="ts"` to the `<script>` tag

This is the easiest change. Simply add lang="ts" to the <script> tag.

-<script>
+<script lang="ts">

Replace the default export with a class that extends `Vue` and uses the `Component` decorator

This change can be complicated to visualise, but the @Component decorator provided by vue-class-component makes it easy to convert a component incrementally by accepting existing properties of the default export as arguments to allow backwards compatibility.

First, replace the default export with a class component:

-export default {
-  name: 'App',
-  components: {
-    HelloWorld
-  },
-  props: ['msg'],
-}
+import Component from 'vue-class-component'
+import { Vue } from 'vue-property-decorator'
+
+@Component({
+  components: {
+    HelloWorld
+  },
+  props: ['msg'],
+})
+export default class App extends Vue {}

Note that the name property is no longer necessary. The name of the component is now the name of the class.

Also, to illustrate the capability of the @Component decorator, the props property is passed as an argument. This allows the component to be used as before with no other changes. Next, we will replace props with class properties marked by the @Prop decorator.

Replace `props` with class properties marked by the `@Prop` decorator

The @Prop decorator is used to mark class properties as props. It accepts an optional argument to specify the type of the prop. If no argument is provided, the type is inferred from the default value.

import Component from 'vue-class-component'
import { Prop, Vue } from 'vue-property-decorator'

@Component
export default class App extends Vue {
  @Prop() msg!: string
  @Prop({ type: Number }) count!: number // type can also be specified explicitly
  @Prop(Boolean) disabled!: boolean // shorthand for { type: Boolean }
}

Now, when a prop is referenced in a function or the template, it will be typed correctly.

Replace `data` with individual class properties

The data property is replaced with individual class properties.

export default {
  name: 'App',
  data() {
    return {
      count: 0,
      msg: 'Hello World',
      complex: { /* ... */ },
    },
  },
}

Becomes:

@Component
export default class App extends Vue {
  count = 0
  msg: string = 'Hello World'
  complex: ComplexType = { /* ... */ }
}

As before, types can be specified explicitly or inferred from the default value.

Add a typed `$refs` class property

The $refs property is typed by adding a class property with the same name and type.

@Component
export default class App extends Vue {
  $refs!: {
    input: HTMLInputElement
  }
}

Now, references to $refs.input will be typed correctly.

Replace `computed` with getter and setter class properties

The computed property is replaced with getter and setter class properties.

export default {
  name: 'App',
  computed: {
    count() {
      return this.$store.state.count
    },
    msg() {
      return this.$store.state.msg
    },
  },
}

Becomes:

@Component
export default class App extends Vue {
  get count() {
    return this.$store.state.count
  }
  set count(value: number) {
    this.$store.commit('setCount', value)
  }
  get msg() {
    return this.$store.state.msg
  }
  set msg(value: string) {
    this.$store.commit('setMsg', value)
  }
}

Now the getters and setters can accept and return the correct types.

Lifecycle hooks become class methods

Lifecycle hooks such as created and mounted are represented as class methods.

export default {
  name: 'App',
  created() {
    this.$store.commit('setCount', 0)
    this.$store.commit('setMsg', 'Hello World')
  },
}

Becomes:

@Component
export default class App extends Vue {
  created() {
    this.$store.commit('setCount', 0)
    this.$store.commit('setMsg', 'Hello World')
  }
}

Replace `methods` with individual class methods

The methods property is replaced with individual class methods. Not much about the methods needs to change.

export default {
  name: 'App',
  methods: {
    increment() {
      this.$store.commit('increment')
    },
    decrement() {
      this.$store.commit('decrement')
    },
  },
}

Becomes:

@Component
export default class App extends Vue {
  increment() {
    this.$store.commit('increment')
  }
  decrement() {
    this.$store.commit('decrement')
  }
}

Replace `this.$emit` with class methods using the `@Emit` decorator

The @Emit decorator is used to mark class methods as emitters. It accepts an optional argument to specify the event name. If no argument is provided, the event name is the name of the method.

export default {
  name: 'App',
  methods: {
    setValue(value) {
      this.$emit('set-value', value)
    },
  },
}

Becomes:

@Component
export default class App extends Vue {
  @Emit('set-value') setValue(value: string) {
    return value
  }
}

This would be called from the parent component in the same way:

<template>
  <app @set-value="onSetValue" />
</template>

Now that your components have been converted, let’s look at the store.

Convert your store

State in Vuex is managed using the Vuex.Store object. Below is a basic example:

import Vue from 'vue'
import Vuex from 'vuex'

Vue.use(Vuex)

export default new Vuex.Store({
  state: {
    count: 0,
    msg: 'Hello World',
  },
  mutations: {
    setCount(state, value) {
      state.count = value
    },
    setMsg(state, value) {
      state.msg = value
    },
    increment(state) {
      state.count++
    },
    decrement(state) {
      state.count--
    },
  },
  getters: {
    count: state => state.count,
    msg: state => state.msg,
  },
  actions: {
    increment(context) {
      context.commit('increment')
    },
    decrement(context) {
      context.commit('decrement')
    },
  },
})

Inside a component, access to the store can be typed using the @State, @Mutation, @Getter, and @Action decorators.

import { Component } from 'vue-property-decorator';
import { Mutation, Getter, Action } from 'vuex-class';

@Component
export default class MyComponent extends Vue {
    @State count!: number
    @State msg!: string
    @Mutation setCount!: (value: number) => void
    @Mutation setMsg!: (value: string) => void
    @Mutation increment!: () => void
    @Mutation decrement!: () => void
    @Getter count!: number
    @Getter msg!: string
    @Action increment!: () => void
    @Action decrement!: () => void
}

Parts of the store can also be namespaced using the modules key in the store object:

import Vue from 'vue'
import Vuex from 'vuex'

Vue.use(Vuex)

export default new Vuex.Store({
  modules: { ExampleModule },
});

Where a module is an object with the same structure as the store object. See the Vuex module documentation for more information.

The namespaced state can then be typed and accessed from components:

import { Component } from 'vue-property-decorator';
import { namespace } from 'vuex-class';

const Store = {
  ExampleModule: namespace('ExampleModule'),
};

@Component
export default class ImportExample extends Vue {
  @Store.ExampleModule.Action('import') import!: ({ file, config }: { file: File; config: ExampleConfig }) => Promise<boolean>;
}

Note that this adds types to the store access points within components, but does not fully statically type the store itself. For more information on how to do this, refer to this excellent article: Vuex + TypeScript.

Conclusion

In conclusion, despite the number of steps needed to convert your Vue components and store, the process is relatively simple. The result is a fully typed Vue application that is easier to maintain and refactor. You won’t regret the ability to trace the flow of data through your application. Additionally, currently developed packages for Vue such as Vuetify and Vuelidate are fully typed and will work seamlessly with your new Vue application.

How to write end-to-end & component tests with Cypress in Vue.js

2022-12-10T00:00:00+00:00

Is writing tests painful for you? In this tutorial, I explain how to handle UI testing with Cypress and hope to convince you that writing tests is not always so tedious and expensive, but can be fun instead.

Cypress is a purely JavaScript-based front-end testing tool built for the modern web. it can test anything that runs in a browser and has built-in support for testing modern frameworks such as Vue.js, React, and Angular. See the full list of front-end frameworks Cypress supports.

As an example we are going to use a to-do app built using Vue. We will learn:

How to install and set up Cypress.
How to create a simple to-do app with Vue 3.
How to write end-to-end tests.
How to write component tests.

How to install and set up Cypress

First let’s create a new Vue project using the Vue CLI.

Install Vue CLI if you don’t have it in your machine:
```
npm install -g @vue/cli
```
Create a project (pick the Vue 3,babel,eslint preset):
```
vue create todo-app
```
cd into the todo-app project and install Cypress:
```
npm install cypress --save-dev
```
No dependencies, extra downloads, or changes to your code are required!
Edit package.json. In the scripts section, add a command, "cypress:open": "cypress open". See the example below.
```
"scripts": {
    "cypress:open": "cypress open"
}
```
Launch Cypress:
```
npm run cypress:open
```

When Cypress opens up you should be able to view the Cypress launchpad as shown in this screenshot:

We will use the Launchpad to configure both E2E Testing and Component Testing. Cypress will automatically generate configuration files as you configure the tests in the Launchpad. If you get stuck, please visit the docs for Launchpad.

How to create a simple to-do app with Vue 3

Open the todo-app project in your favourite editor and add the following single-file components:

src/components/BaseTextInput.vue

BaseTextInput will contain a text input and a button for adding new to-do items.

<template>
    <form class="add-todo-form">
        <input type="text" class="input" placeholder="Add a new todo" v-model="todo">
        <input type="submit" value="Add" @click="emitNewTodoEvent">
    </form>
</template>

<script>
export default {
    data() {
        return {
            todo: ''
        }
    },
    methods: {
        emitNewTodoEvent(e) {
            e.preventDefault();
            this.$emit('newTodo', this.todo);
            this.todo = '';
        }
    }
}
</script>

<style scoped>
.input {
    width: 100%;
    padding: 8px 10px;
    border: 1px solid #32485F;
}

.add-todo-form {
    width: 100%;
    display: flex;
    align-items: center;
}

input[type="submit"] {
    margin-left: 5px;
    padding: 8px 10px;
    border: 1px solid #32485F;
    background-color: #32485F;
    color: #fff;
    font-weight: bold;
    cursor: pointer;
}

input[type="submit"]:hover {
    background-color: #00C185;
}
</style>

src/components/TodoListItem.vue

TodoListItem displays a to-do along with a button for removing that to-do.

<template>
    <li>
      {{ todo.text }}
      <button @click="$emit('remove', todo.id)">
        X
      </button>
    </li>
  </template>

  <script>
  export default {
    props: {
      todo: {
        type: Object,
        required: true
      }
    }
  }
  </script>

src/components/TodoList.vue

TodoList component lists all to-dos.

<template>
  <div>
    <BaseTextInput
      @newTodo="addTodo"
    />
    <ul v-if="todos.length">
      <TodoListItem
        v-for="todo in todos"
        :key="todo.id"
        :todo="todo"
        @remove="removeTodo"
      />
    </ul>
    <p class="empty-state-message" v-else>
      Nothing left in the list. Add a new todo in the input above.
    </p>
  </div>
</template>

<script>
import BaseTextInput from './BaseTextInput.vue';
import TodoListItem from './TodoListItem.vue';

let nextTodoId = 1;

export default {
  components: {
    BaseTextInput, TodoListItem
  },
  data () {
    return {
      todos: []
    }
  },
  methods: {
    addTodo (todo) {
      const trimmedText = todo.trim();
      if (trimmedText) {
        this.todos.unshift({
          id: nextTodoId++,
          text: trimmedText
        });
      }
    },
    removeTodo (idToRemove) {
      this.todos = this.todos.filter(todo => {
        return todo.id !== idToRemove;
      });
    }
  }
}
</script>

Edit src/App.vue to include code that will render the Todo App.

<template>
  <div id="app">
    <h1>My Todo App!</h1>
    <TodoList/>
  </div>
</template>

<script>
import TodoList from './components/TodoList.vue';

export default {
  components: {
    TodoList
  }
}
</script>

<style>
*, *::before, *::after {
  box-sizing: border-box;
}

#app {
  max-width: 400px;
  margin: 0 auto;
  line-height: 1.4;
  font-family: 'Avenir', Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  color: #00C185;
}

h1 {
  text-align: center;
}
</style>

Then, run:

npm run serve

and visit http://localhost:8080 to view your Todo App!

How to write end-to-end tests

End-to-end (E2E) testing is used to test an application flow from start to finish. Tests are designed to use the application the same way that a user would.

In our example we are going to test the whole Todo app with the following test cases:

The user should see a message when the to-do list is empty.
The user should be able to view a list of to-dos.
The user should be able to add a new to-do.
The user should be able to remove an existing to-do.

Cypress is built on top of Mocha and Chai. If you’re familiar with writing tests in JavaScript, then writing tests in Cypress will be a breeze.

Visit the official Cypress docs to learn more about how to start testing a new project in Cypress.

Without futher ado lets start testing our Todo app.

Inside the cypress folder that was added during installation create a file, cypress/e2e/todo.cy.js, and add the following tests.

Please visit the folder structure docs to learn more about how to organise tests in Cypress and understand the generated Cypress folder structure.

/* eslint-disable no-undef */

// describe() function is used to group tests
describe('Todo tests', () => {
  it('should display empty state message', () => {
    // cy.visit() used to visit a remote url
    // learn more about it here: https://docs.cypress.io/api/commands/visit#Syntax
    cy.visit('http://localhost:8080');

    // cy.get() command Gets one or more DOM elements by selector or alias
    // learn more about Cypress commands/api here: https://docs.cypress.io/api/table-of-contents
    cy.get('.empty-state-message')
    .contains('Nothing left in the list. Add a new todo in the input above.')
    .should('be.visible');
  });

  it('should add todo', () => {
    cy.visit('http://localhost:8080');

    // add todo by typing in the input and pressing enter
    cy.get('input[type="text"]').type('new todo{enter}');

    // check if the todo is added
    cy.get('ul').contains('new todo').should('be.visible');
    cy.get('ul').find('li').should('have.length', 1);


    // add another todo by typing in the input and pressing 'add' button
    cy.get('input[type="text"]').type('more todo');
    cy.get('input[type=submit]').click();

    // check if the todo is added
    cy.get('ul').contains('more todo').should('be.visible');
    cy.get('ul').find('li').should('have.length', 2);
  });

  it('should delete todo', () => {
    cy.visit('http://localhost:8080');

    // delete the first todo
    cy.get(':nth-child(1) > button').click();

    // check if the todo is deleted
    // cy.should() command is used to assert that the todo list has only one todo
    // learn more about Cypress assertions here: https://docs.cypress.io/guides/references/assertions
    cy.get('ul').find('li').should('have.length', 1);
  });
});

To make Vue available at http://localhost:8080, run:

npm run serve

Then, to launch Cypress, run:

npm run cypress:open

On the Cypress launcher select “End2End Tests” and click on the todo.cy.js spec to run your tests.

How to write component tests

Cypress Component Test Runner executes your component tests in the browser as a user would by simulating real interactions. Since it runs in the browser, you get to debug your components using your favourite developer tools.

To demonstrate how to write component tests using Cypress let’s write tests for the following components:

BaseTextInput.vue
TodoListItem.vue

Component tests for BaseTextInput.vue

Here we are going to assert the following;

Text input is rendered with placeholder text “Add a new todo”.
When the “add” button is clicked a newTodo event is emitted with a payload containing text that was typed in the text input.

First create a spec, src/components/BaseTextInput.cy.js, then add the following code:

/* eslint-disable no-undef */
import BaseTextInput from './BaseTextInput.vue';

describe('<BaseTextInput />', () => {
  it('renders base text input component', () => {
    // Renders the component in DOM.
    // cy.mount() is a custom command.
    // Learn more about cypress custom commands here:
    // https://docs.cypress.io/api/commands/mount#Creating-a-New-cy-mount-Command
    cy.mount(BaseTextInput);

    // Asserts that the text input is rendered with the correct placeholder
    cy.get('input').should('have.attr', 'placeholder', 'Add a new todo');

    // asserts that when the 'add' button is clicked, an event is emitted
    // with the payload containing the value of the text input
    cy.get('input[type="text"]').type('new todo');
    cy.get('input[type=submit]').click().then(() => {
      // Cypress.vueWrapper provides access to the Vue Test Utils.
      // With this wrapper you can access any Vue Test Utils API.
      // Learn more about Vue Test Utils here: https://vue-test-utils.vuejs.org/
      // e.g. cy.vueWrapper().emitted() returns all the events emitted by the BaseTextInput component
      cy.wrap(Cypress.vueWrapper.emitted()).should('have.property', 'newTodo');
      expect(Cypress.vueWrapper.emitted().newTodo[0]).to.deep.equal(['new todo']);
    });
  })
});

To run the test, launch Cypress using cypress:open. This time select “component testing”, then click on BaseTextInput.cy.js to run tests.

Component tests for TodoListItem.vue

Here we are going to assert the following:

A Todo list item is rendered with correct text.
When the “remove” button is clicked, a “remove” event is emitted with payload containing the ID of the Todo to be removed.

First create a spec, src/components/TodoListItem.cy.js, and add the following code:

/* eslint-disable no-undef */
import TodoListItem from './TodoListItem.vue';

describe('<TodoListItem />', () => {
  it('renders todo list item', () => {
    const text = 'new todo';
    const id = 1;
    // mount the component with props
    // see: https://test-utils.vuejs.org/guide/
    cy.mount(TodoListItem, {props: {todo: { id, text }}});

    // asserts that the todo list item is rendered with the correct text
    cy.get('li').contains(text);

    // asserts that when 'x' button is clicked, 'remove' event is emitted with the correct payload
    cy.get('button').click().then(() => {
      cy.wrap(Cypress.vueWrapper.emitted()).should('have.property', 'remove');
      expect(Cypress.vueWrapper.emitted().remove[0]).to.deep.equal([id]);
    })
  })
});

To run the test, launch Cypress using cypress:open. Select “component testing” again, then click on TodoListItem.cy.js to run tests.

The final source code with all the tests can be found in my GitHub todo-app repo.

Next steps

This article is meant to provide you with knowledge on how to set up and run tests using Cypress. However, you may need to further learn Cypress and its API to write better and efficient tests. I recommend you continue learning with:

Integrating Contentful with NuxtJS

2022-10-07T00:00:00+00:00

Some time ago, I had the opportunity to collaborate on a cool NuxtJS project. I’m still somewhat new to Vue.js and its related frameworks, meaning I’m discovering exciting new tools and third-party services that can be integrated with them every time a new requirement appears. And there is a particular concept that I heard of, but never worked with until this project: using a Headless CMS to deliver content.

Essentially, a headless CMS permits creating a custom content model, making it accessible through one (or several) APIs that we can query, allowing us to choose whatever presentation layer we prefer to handle the display. This approach decouples the content management part (the “body”) of a project from the design, templates, and frontend logic (the “head”), becoming particularly useful when we have several application types that will interact with the same data, such as a website, a mobile app, or an IoT device.

With that in mind, let’s have a quick look at Contentful: It’s a headless CMS that is offered under the concept of content-as-a-service (CaaS), meaning the content is delivered on demand from a cloud platform to the consumer by implementing an API or web service.

Pricing

For individual or small websites, the free option should be sufficient. It has a limit of 5 users and a size limit of 50MB for assets, and the technical support area is disabled. The next option (Medium, $489/month) also includes an additional role (author), additional locales, and the possibility to create up to ten different user accounts. The asset size is also extended up to 1000MB.

You can review the full pricing details on Contentful’s website.

Creating content

In order to start creating content, there are two essential steps:

We will need to set up a new space. A space is an area where the content will be grouped into a single project.
We need to define the model for our content. The model is the type and structure that our content will have. For the integration below, we will need a new “Page” model, that will contain two fields to save the information that we need for a static page: title and content. We can also include a publishDate field, just to know when each page was created.

Integration

With our space created and our content model ready, it’s time to add Contentful to our NuxtJS app. The integration process is quite simple, thanks to the JavaScript client library provided by Contentful. The library is based on the axios client, allowing it to run on the client as well as on the server, for SSR. If we have npm set up, we can add it to our project by running:

npm install --save contentful

The most efficient way to use it across our app and have it ready for client and server-side rendering is to declare a new plugin. All we need to do is create a new file named contentful.js under our project’s plugins folder:

const contentful = require('contentful')

const config = {
  space: process.env.CONTENTFUL_SPACE_ID,
  accessToken: process.env.CONTENTFUL_API_ACCESS_TOKEN,
}

module.exports = {
  createClient() {
    return contentful.createClient(config)
  },
}

Next, we need to add the new environment variables to our project’s .env file. The values that we need to provide are our space ID and the access token for querying the API:

CONTENTFUL_SPACE_ID={our_space_id}
CONTENTFUL_API_ACCESS_TOKEN={our_access_token}

We’re all set! Now, we have our plugin ready to use. One neat extra step that we did for this particular project is creating a ContentfulPage component that will automatically pull the contents from Contentful based on the given entry ID. By doing that, we can simply use the component in all the static pages that we have on our website.

First, let’s create the component, containing a simple wrapper for the template section, and an entryId property that we will use to query the API. We can save it under ~/components/ContentfulPage.vue:

<template>
  <div :id="entryId">
    <p v-if="$fetchState.pending">Loading...</p>
    <div v-else>
      <h1>
        {{ page.fields.title }}
      </h1>
      <div class="page-content" v-html="$md.render(page.fields.content)" />
    </div>
  </div>
</template>

<script>
  import { createClient } from '~/plugins/contentful'
  const contentful = createClient()

  export default {
    name: 'ContentfulPage',
    props: {
      entryId: {
        type: String,
        required: true,
      },
    },

    data() {
      return {
        page: {},
      }
    },

    async fetch() {
      this.page = await contentful.getEntry(this.entryId)
    },
  }
</script>

This component will asynchronously fetch the entry from Contentful, and display a “loading” legend while it does so. Once the query is complete, the content will be shown inside the div element with the page-content class. The component expects the returned page to have at least two attributes: title and content.

With the new component added to our project, we are ready to create a page (for example, index.vue) that uses it to render our content like this:

<template>
  <div>
    <contentful-page entry-id="{index_entry_id}" />
  </div>
</template>

<script>
  import ContentfulPage from '~/components/ContentfulPage'
  export default {
    components: {
      ContentfulPage,
    },
  }
</script>

All we need to do is get the entry ID from the content we created in Contentful, pass it to the entry-id parameter of the component, and that’s it! Our content will be fetched from the API and displayed to the user. It will also work when rendering on the client, as well as for SSR.

Alternatives

There are several alternatives to Contentful out there: Prismic CMS or GraphCMS — which is based entirely in GraphQL — are the most popular. There are also downloadable products, like SilverStrap CMS. Their pricing plans are varied, but all of them offer a free community plan for starters or small websites.

Have you used any other headless CMS not listed here? We would love to hear your comments!

Building a search suggestions feature with Node.js and Vue

2021-11-27T00:00:00+00:00

Photo by Kasper Rasmussen on Unsplash

The backstory

Some time ago, I worked on a project to improve the usability of a search component for our clients. Similar to Google and other search interfaces, the user was presented with a number of suggested search terms as they typed into the search box. We wanted to add keyboard support and give the component a visual facelift. When the customer used the up, down, Esc, or Enter or Return keys, the component would allow them to choose a particular search term, clear their search, or navigate to the results for their chosen search term.

This is what the new and improved UI looked like:

As developers, it can sometimes feel like we’re stuck when working on older, well established projects. We gaze longingly at newer and shinier tools. Part of my objective while building this feature was to prove the viability of a newer approach (Node.js and Vue) to the other engineers on the project as well as the client.

The feature existed already but we wanted to improve the UX and performance. Having added several Vue-powered features to this site in the past, I was very comfortable with the idea and have written about that previously. It would also be very easy to roll back if needed since this project was limited in scope, and very easy to compare the new solution with the code it replaced.

Picking a route and configuring it

This project was running on Interchange, nginx, and MySQL, but our approach would work in other stacks (e.g. with Apache). One key concept is that we’re using nginx as a reverse proxy to route requests to our various apps, serve static files, etc. Using nginx in this way allows us to stitch together the different services for a given project. In this case I created an endpoint for the search suggestions endpoint in our nginx config file. This enabled requests made to /suggestions/ to be passed along to our Node.js app. You can read more about reverse proxying with nginx if you like.

# Node.js powered endpoint for search suggestions
location /suggestions/ {
    proxy_pass http://0.0.0.0:8741/;
}

If your project is running on Apache or another platform there will likely be a similar configuration option to route the requests to your Node.js app as I did.

Node.js time

I wrote a little app with the MySQL driver for Node.js and Express. The app connects to MySQL and uses the nifty built-in connection pooling. It accepts POST requests from the site and responds with an array of search suggestion objects in JSON format.

Enter Vue

For the front-end part of the feature I created Vue components for the search input and for the display of the results. As the customer types, results are fetched and displayed. Using the arrow keys navigates up and down and Esc clears out the search. Once the customer has the search they want they can either press Enter or click on the Search button.

It’s worth mentioning that this search feature works without JavaScript. When you enter a search term and press Enter or click the Search button, you will get results. However, if you do have JavaScript enabled (and if our suggestions app is up and running) you’ll get suggestions as you type. This is a good thing.

Performance wins

The new endpoint returns results in less than 100ms — a 3x or 4x improvement over the Perl script it replaced. We get a response faster, meaning the experience is much more smooth for the user!

Managing the Node.js process

We used pm2 and systemd to manage the Node.js processes and ensure they are started up when the server is rebooted. In my experience this has been very stable and has not required any babysitting by our operations folks.

Great success!

Have you done anything similar in your projects? Do you have vintage/legacy app that could benefit from learning some new tricks? Let us know!

Vue GraphQL integration using Apollo Client

2021-10-08T00:00:00+00:00

Photo by Mathew Benoit on Unsplash

Introduction

In this post I’ll go over everything you need to know to get your Vue app using GraphQL to send and receive data. This post only covers the frontend — stay tuned for my next post on making a GraphQL server using Django and graphene-python!

For the uninitiated: GraphQL is a query language that aims to replace the traditional REST API. The idea is that, instead of having separate endpoints for each resource in your API, you use one endpoint that accepts GraphQL queries and mutations for all of your resources. Overall, this makes data access on the frontend more like querying a database. Not only does it give you more control over your data, but it also can be much faster than using a REST API, providing a better user experience.

Getting started

To get your Vue app set up using GraphQL we’ll need to do two things. First, we’ll install vue-apollo (a Vue plugin for the Apollo GraphQL client) as well as apollo-boost, which bootstraps the configuration of Apollo. With these you’ll be able to:

Manually run GraphQL queries and mutations from any Vue component via the this.$apollo helper
Automatically map GraphQL queries to a component’s data fields by adding the apollo property to your component

These queries will also lazy load data from Apollo’s cache to minimize requests across multiple components.

Second, we’ll add webpack configuration so that you can store your GraphQL queries and mutations in separate files (.gql or .graphql), and import them directly into your component files.

Let’s begin by installing the required npm packages:

npm install graphql vue-apollo apollo-boost graphql-tag

Setting up VueApollo

To set up the VueApollo plugin, we’ll use the ApolloClient helper from apollo-boost, and pass it the URL of your GraphQL API endpoint:

main.js

import Vue from 'vue';
import App from './App.vue';
import ApolloClient from 'apollo-boost';
import VueApollo from 'vue-apollo';

// Create the apolloProvider using the ApolloClient helper
// class from apollo-boost
const apolloProvider = new VueApollo({
  defaultClient: new ApolloClient({
    uri: '<YOUR_GRAPHQL_ENDPOINT_HERE>'
  })
});

// Add VueApollo plugin
Vue.use(VueApollo);

// Instantiate your Vue instance with apolloProvider
new Vue({
  apolloProvider,
  render: h => h(App),
}).$mount('#app')

With this configuration in place, you now have access to this.$apollo in all your components, and you can add smart queries to them using the apollo property.

GraphQL file imports

To enable GraphQL file imports, update vue.config.js to use the included GraphQL loader from graphql-tag to parse all files with a .graphql or .gql extension:

vue.config.js

module.exports = {
    chainWebpack: (config) => {
        // GraphQL Loader
        config.module
          .rule('graphql')
          .test(/\.(graphql|gql)$/)
          .use('graphql-tag/loader')
          .loader('graphql-tag/loader')
          .end();
      },
};

Once this configuration is in place, you can create a .gql or .graphql file, and import it directly into your JavaScript files:

import MY_QUERY from "./my-query.gql";

This imported query (named MY_QUERY in the example) is a DocumentNode object, and can be passed directly to Apollo.

As a side note: If you have an existing GraphQL server, it’s usually possible to export your schema into a .gql file that contains the queries and mutations your server uses. Not only does this save a lot of time, but it helps minimize inconsistencies between the queries on the frontend and what the backend actually does.

Loading data with Apollo queries

With Apollo, you can configure any Vue component to map GraphQL queries to fields in its data object. You can do this by adding an apollo option to your component. Each field on this object is an Apollo Smart Query, which will automatically run the query (lazily loading from the cache) and then map the query results to a field in the component’s data. The name of the mapped data field will be the same as the field name within the apollo object.

For example, let’s say we needed to make a component load a list of blog posts, given a user ID, and display the total number of posts for that user. To do this using Apollo, you’ll need to define a GraphQL query that accepts userId as a variable and queries for that user’s posts. Here’s how that query might look:

posts.gql

query ($userId: String!) {
    posts(userId: $userId) {
        id 
        content
    }
}

We can then define an apollo object on the component that loads the data from the query into our component’s data:

posts.vue

<template>
    <p>
        Total number of posts: {{posts.length}}
    </p>
</template>
<script>
import POSTS_BY_USER from "./posts.gql";

export default {
    name: 'NumPosts',
    props: ['userId'],
    data() {
        return {
            // This value is updated by apollo when the query
            // is run and receives data
            posts: [],
        }
    },
    // This smart query will automatically run the POSTS_BY_USER
    // query when the component is mounted. It also responds to 
    // changes in any of its variables, and will automatically 
    // rerun the query if the userId changes.
    apollo: {
        posts: {
            query: POSTS_BY_USER,
            variables() {
                return { userId: this.userId };
            },
        },
    },
}
</script>

The smart query accepts a GraphQL query and a variables object where the keys are the variable names and the values are the variable values. What this will do is run the POSTS_BY_USER query when the component mounts, and store the results of that query in the posts data field. Then, any time one of the variables changes (in this case, it would happen if the userId prop receives a new value), the query will be rerun and posts will again be updated. Additionally, the results of the query are stored in Apollo’s cache. So, if another component has the same smart query in it, only one actual request will be made.

Updating data with Apollo mutations

To update existing objects using GraphQL, we use mutations. GraphQL mutations look similar to queries, except that on the server, they will update or create new resources. For example, a mutation to update an existing user’s post would look like this:

mutation ($id: Int!, $content: String!) {
    updatePost(id: $id, content: $content) {
        id
        content
    }
}

Running this mutation will cause the server to update the post with the specified $id. To run GraphQL mutations from your component, you can use the Apollo mutate method:

this.$apollo.mutate({
    mutation: UPDATE_POST,
    variables: { id: this.post?.id, content: this.newContent }
});

This function sends the UPDATE_POST mutation to the server to be run, and then updates the cache for all occurrences of the post with the given id when it receives the response.

For updating existing objects, Apollo is able to automatically handle updating the cache. However, when creating a new object, the cache needs to be updated manually. I’ll demonstrate this in the next section.

Creating data and handling cache updates

Apollo has a global cache of query results, which prevents duplicate requests from being made when the same query is run again in the future. In the cache, each query is indexed using the query itself, and the variables it was run with.

When you run a mutation that updates an existing object, Apollo is smart enough to update the cache because it can use the ID of that object (from the mutation’s variables) to find all cached queries that include it. However, when creating new objects, Apollo won’t update the cache because there’s no object in any cached queries with the ID of the new object. This is why you’ll have to either update the cache yourself, or specify which queries need to be re-fetched after running the mutation.

While specifying the queries to re-fetch makes the code much simpler, it might make more sense to do a manual update if the query to be re-fetched is costly.

Continuing with our blog posts example, let’s assume we have a query POSTS_BY_USER, which returns a list of all posts for a given user ID. If we wanted to create a new post, we’d need to update the cached results for POSTS_BY_USER with the given user ID to include the new post.

To create a new post, and then re-fetch the POSTS_BY_USER query, it would look like this:

this.$apollo.mutate({
    mutation: ADD_POST,
    variables: { content: this.newPostContent },
    refetchQueries: [
        {
            query: POSTS_BY_USER, 
            variables: { userId: this.currentUser.id }
        }
    ]
});

To do the same exact thing with a manual cache update, it would look like this:

this.$apollo.mutate({
    mutation: ADD_POST,
    variables: { content: this.newPostContent },
    update: (cache, result) => {
        // The new post returned from the server. Notice how 
        // the field on data matches the name of the mutation 
        // in the GraphQL code.
        let newPost = result.data.addPost;

        // Queries are cached using the query itself, and the
        // variables list used.
        let cacheId = {
            query: POSTS_BY_USER,
            variables: { userId: this.currentUser.id },
        };

        // Get the old list from the cache, and create a new array
        // containing the new item returned from the server along 
        // with the existing items.
        const data = cache.readQuery(cacheId);
        const newData = [...data.postsByUser, newPost];

        // Write the new array of data for this query into 
        // the cache.
        cache.writeQuery({
            ...cacheId,
            data: { postsByUser: newData },
        });
    },
    // By specifying optimistic response, we're instructing apollo 
    // to update the cache before receiving a response from the 
    // server. This means the UI will be updated much quicker.
    optimisticResponse: {
        __typename: "Mutation",
        addPost: {
            __typename: "Post",
            id: "xyz-?",
            content: this.newPostContent,
            userId: this.currentUser.id,
        },
    },
});

There’s a few things to note about the above code. First, it specifies an optimisticResponse field on the mutation. This field can be used to pass a response to Apollo before the server actually responds. If you know exactly what the response will look like, you can use it to enhance the user experience by making the UI respond right away instead of waiting while the server processes the request.

As you can see, manually updating the cache requires quite a bit of code to accomplish, and is a bit hard to read. In my own projects, I found it best to abstract the Apollo mutations into separate helper functions that just accept the variables object. This way, the cache updates stay separate from the business logic of the components, and aren’t scattered throughout the codebase.

Conclusion

And that’s it! My experience converting an existing Vue codebase to use Apollo/GraphQL was a very positive one. The resulting code had much better performance than manually sending requests and updating a Vuex store, and was a lot easier to work on.

Have any questions? Feel free to leave a comment!

Vue 3 is out with exciting new features

2020-12-08T00:00:00+00:00

Photo courtesy of NASA

Vue 3 was officially released on September 18, 2020 with improved performance and some exciting new features.

Composition API

The Composition API is one of the most significant changes. It helps with logically grouping related fragments of components. In Vue 2, we used the Options API to pass various options during component configuration:

// src/components/ProductList.vue
<template>
  <div class="child">
    <h3>Vue2</h3>
    <div>
      <div class="add-product">
        <h2>Add Product</h2>
        <div>Name: <input name="name" v-model="newProduct.name" /></div>
        <div>Price: <input name="name" v-model="newProduct.price" /></div>
        <button @click="addProduct">Add</button>
      </div>
      <div class="search-product">
        <h2>Search Product</h2>
        <input name="name" v-model="filterText" placeholder="Start typing to search" />
      </div>
    </div>
    <div class="list-product">
    <h1>Product List</h1>
    <ul>
      <li v-for="product in filteredProducts" :key="product">{{product.name}}:{{product.price}}</li>
    </ul>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      newProduct: {name: '', price: 0.00},
      productList: [
        {name: 'Milk', price: 2},
        {name: 'Carrot', price: 12},
        {name: 'Sugar', price: 8},
        {name: 'Cheese', price: 20}
        ],
      filterText: ''
    }
  },
  methods: {
    addProduct: function(){
      this.productList.push({...this.newProduct})
    }
  },
  computed: {
    filteredProducts: function () {
      if(this.filterText.trim().length > 0){
        return this.productList.filter(p => p.name.toLowerCase().indexOf(this.filterText.toLowerCase())>-1)
      }
      return this.productList;
    }
  }
}
</script>

This component’s functions have several responsibilities, and as the code grows more functions with different responsibilities will be needed, making it more difficult to understand and implement new changes. Moreover, the related parts of code are scattered throughout each component’s options (data, computed, methods).

The new Composition API enables us to organize related code. setup is a new component option in Vue 3, acting as the entry point for the Composition API. setup is executed before the component is created, and after the props are resolved, which means this cannot be accessed inside setup, but props and context can.

The following code uses the Composition API to recreate the earlier ProductList example component.

// src/components/ProductList3.vue
<template>
  <div class="child">
    <h3>Vue3 Composition API</h3>
    <div>
      <div class="add-product">
        <h2>Add Product</h2>
        <div>Name: <input name="name" v-model="newProduct.name" /></div>
        <div>Price: <input name="name" v-model="newProduct.price" /></div>
        <button @click="addProductToList">Add</button>
      </div>
      <div class="search-product">
        <h2>Search Product</h2>
        <input name="name" v-model="filterText" placeholder="Start typing to search" />
      </div>
    </div>
    <div class="list-product">
      <h1>Product List</h1>
      <ul>
        <li v-for="product in filteredProducts" :key="product">{{product.name}}:{{product.price}}</li>
      </ul>
    </div>
  </div>
</template>

<script>
import useProducts from '@/composables/useProducts'
import useProductNameSearch from '@/composables/useProductNameSearch'
import { ref } from 'vue'

export default {
  setup () {
    const newProduct = ref({name: '', price: 0.00})
    const { products, addProduct } = useProducts();
    const { filterText, filteredProducts } = useProductNameSearch(products)

    return {
      newProduct,
      addProduct,
      filterText,
      filteredProducts
    }
  },

  methods: {
    addProductToList: function(){
      // process product data before adding to list
      this.addProduct({...this.newProduct})
    }
  },
}
</script>

// src/composables/useProducts.js
import { ref } from "vue";

export default function userProducts(){
  const products = ref([
    {name: 'Milk', price: 2},
    {name: 'Carrot', price: 12},
    {name: 'Sugar', price: 8},
    {name: 'Cheese', price: 20}
  ]);

  const addProduct = (product) => products.value.push(product);

  return {
    products,
    addProduct
  }
}

// src/composables/useProductNameSearch.js
import { computed, ref } from "vue";

export default function useProductNameSearch(products){
  const filterText = ref('');

  const filteredProducts = computed(()=>{
    if(filterText.value.trim().length > 0){
      return products.value.filter(p => p.name.toLowerCase().indexOf(filterText.value.toLowerCase())>-1)
    }
    return products.value;
  })

  return {
    filterText,
    filteredProducts
  }
}

The two functions using the Composition API are now in two separate files, imported by our ProductList component. Similarly, we can add more functions with isolated responsibility in different files and use them in our component. This will the make code easier to understand and to make changes to the component.

Take a look at the demo and source code if you like.

Summary

setup() is the entry point for composition API and can be used as a standalone composition function in a separate file. To learn more about setup check out the Vue 3 docs.
ref can be used to make a variable reactive, and .value is used to access its value inside the setup function.
computed properties can be created using the function imported from Vue. .value should also be used here to access the value of computed properties.

There are more options, like lifecycle hooks, watch, and toRefs, which we don’t use in the above code.

Lifecycle hooks can be used in setup by prefixing with on. For example, mounted becomes onMounted. Visit the docs to learn about all of the lifecycle hooks.
To setup watch and know more about it read the docs.
toRefs is another option which helps make props which are passed to the setup function reactive. To learn more visit the docs.

Teleport

Teleport is another interesting feature which helps in making our HTML structure cleaner and more logical. Previously when we wanted to use a global modal or a notification/alert, it required deeply nested code. With teleport, the placing of components in the required location is easier. Let’s take a look:

The screenshot below shows the rendered DOM (without teleport code), where the Vue app is inserted into the DOM in div#app.
Now we are going to add <div id="destination"></div> just above the Vue application. This div is highlighted in the screenshot below. Notice that the div we added is outside of the Vue application.
Now in the Vue component we will add <teleport to="#destination">Teleported outside Vue App component</teleport>. This code uses the to prop to pass a reference of which element to use as parent instead of the Vue app.
After adding the teleport code, we can see that its contents, “Teleported outside Vue App component”, are rendered in HTML outside the Vue app. Normally, it would be rendered in its place in the app (the red region) but due to teleport it’s rendered in the teleport destination (the green region).
We can see in the browser that the teleported code is at the top of the page rather than within the Vue app.

With teleport we can render a piece of HTML code anywhere in the DOM tree. Teleported code will render with the Vue component and even update with it when props change. Note that the destination should be outside the component tree.

Fragments

In Vue 2, multi-root components were not supported, so multiple components needed to be wrapped in a single <div>. But in Vue 3, having multi-root components is possible.

Vue 2:

<!-- Layout.vue -->
<template>
  <div>
    <header>...</header>
    <main>...</main>
    <footer>...</footer>
  </div>
</template>

Vue 3:

<!-- Layout.vue -->
<template>
  <header>...</header>
  <main>...</main>
  <footer>...</footer>
</template>

Emits component option

In Vue 2, props for a component are declared in props option, making it easy to see which props are being used. But for custom events, we had to search the whole component to see what events are used. Now, custom events can be declared just like props via the emits option. Since this option accepts object notation, validators for arguments can be defined similar to validators in the props option.

Below you can see that we are passing custom events from the parent component to the child component and using the emits option to declare the custom event in the child component.

// src/App.vue
<template>
  <div class="parent">
    <product-list />
    <product-list-3 @update-inventory="addToInventory"/>
  </div>

  <div id="inventory">
    <span v-show="inventory.length === 0">Inventory is empty.</span>
  <div v-show="inventory.length > 0">
    <h3>Inventory</h3>
    <ul>
      <li v-for="item in inventory" :key="item.name">{{item.name}}: {{item.price}}</li>
    </ul>
      Total: ${{inventory.reduce((acc,product)=>acc=acc+(+product.price),0)}}
  </div>
  </div>

  <teleport to="#destination">Teleported outside Vue App component</teleport>
</template>

<script>
import ProductList from "./components/ProductList.vue";
import ProductList3 from "./components/ProductList3.vue";

export default {
  name: "App",
  components: {
    ProductList,
    ProductList3
  },
  data(){
    return {
      inventory: []
    }
  },
  methods: {
    addToInventory(products){
      this.inventory = [...this.inventory, ...products];
    }
  }
};
</script>

// src/components/ProductList3.vue
<template>
  . . .
    <div class="list-product">
      <h1>Product List</h1>
      <button @click="updateInventory()">Update Inventory</button>
      <ul>
        <li v-for="product in filteredProducts" :key="product">
          {{ product.name }}:{{ product.price }}
        </li>
      </ul>
    </div>
  . . .
</template>

<script>
import useProducts from "@/composables/useProducts";
import useProductNameSearch from "@/composables/useProductNameSearch";
import { ref } from "vue";
import ChildComponent from "./ChildComponent.vue";

export default {
  components: { ChildComponent },

  emits: ["update-inventory"],

  . . .

  methods: {
    . . .
    updateInventory: function() {
      this.$emit("update-inventory", [...this.filteredProducts]);
      this.emptyProducts();
    }
    . . .
  }
};
</script>

Some breaking changes from Vue 2

New method in the Global API, createApp. Calling this returns the app instance which can be used to mount the root instance.

Vue 2:

import Vue from 'vue'
import App from './App.vue'

Vue.config.productionTip = false

new Vue({
  render: h => h(App),
}).$mount('#app')

Vue 3:

import { createApp } from 'vue'
import App from './App.vue'

createApp(App).mount('#app')

Global API methods like nextTick, set, observable and others are now restructured with tree-shaking support.

Vue 2:

import Vue from 'vue'

Vue.nextTick(() => {
  // something DOM-related
})

Vue 3:

import { nextTick } from 'vue'

nextTick(() => {
  // something DOM-related
})

Here is a list of more breaking changes.

Many Vue libraries are yet to implement the changes that would work with Vue 3. For example, we use Vuetify in various client projects and this is not supported in Vue 3 as of writing this blog. There is a roadmap planned for Vue 3 support in Vuetify, with the alpha release in Q4 2020 and target release in summer 2021.

For information about migrating Vue 2 projects check out the migration guide.

COVID-19 Support for the Kansas Department of Health and Environment

2020-09-14T00:00:00+00:00

Kansas’s existing EpiTrax system

End Point has worked on Kansas’s disease surveillance systems since 2011. In 2018 we migrated them from their legacy TriSano application to the open source EpiTrax surveillance system created by Utah’s Department of Health. The new EpiTrax system had been in full production for about eight months when COVID-19 cases started to grow in the United States.

COVID-19: Help needed

In March 2020, the Director of Surveillance Systems at the Kansas Department of Health and Environment (KDHE) asked us at End Point to create a web-based portal where labs, hospitals, and ad-hoc testing locations could enter COVID-19 test data. While systems existed for gathering data from labs and hospitals, they needed a way to quickly gather data from the many new and atypical sites collecting COVID-19 test information.

Our approach

Since the portal was intended for people who were unfamiliar with the existing EpiTrax application, we were able to create a new design that was simple and direct, unconstrained by other applications. It required a self-registration function so users could access the system quickly and without administrative overhead, and users needed to understand how to use it without extensive training.

We at End Point agreed to create the portal and dashboard for test results reporters immediately, while planning for later development of additional administrative functions. We used Ruby on Rails and Vue.js to build the portal due to their usefulness for rapid development. The Vue.js front-end JavaScript framework allowed us to quickly put together the portal UI and integrate it with the Rails back-end web services.

Once approved, our team got to work setting up the environment, developing the portal application, and rigorously testing it.

Here are some screenshots of the application:

Portal home page

User registration page

Dashboard

Reporters’ entry screens

The portal was launched on April 30.

Contact tracers support

After the EpiTrax portal for COVID-19 was up and running, Kansas made urgent plans to hire 400 contact tracers. We updated the EpiTrax portal to accommodate this new type of user, showing contact tracers only the data they are authorized to view, while providing them the ability to make limited contact record updates and to create tasks. The project is ongoing, and eventually will be used for all diseases.

EpiTrax for Missouri

Late this Spring, after learning of Kansas’s use of the EpiTrax platform and the powerful capabilities that it provides to the Kansas public health system, the State of Missouri reached out to us at End Point to request their own EpiTrax implementation. End Point and Missouri quickly came to agreement, and since July we have been working together build out a full production EpiTrax surveillance system for them.

Contact us!

To discuss an EpiTrax project, contact us. Our expert team is ready to help you meet your requirements.

Our Vue Storefront “Proof of Concept” Experience

2020-08-10T00:00:00+00:00

Recently we experimented internally with integrating Vue Storefront and Magento 2.3. Vue Storefront is an open source Progressive Web App (PWA) that aims to work with many ecommerce platforms.

What initially piqued our interest was the possibility of integrating Vue Storefront with the venerable ecommerce back-end platform Interchange, which many of our clients use. Vue Storefront’s promise of ease of integration with any ecommerce backend made us curious to see whether it would make a good modern front-end for Interchange.

Since Vue Storefront seems to be most commonly used with Magento, we decided to start our experiment with a standard Vue Storefront/Magento 2.3 proof-of-concept integration.

PoC of Vue Storefront/Magento 2.3

OK, to be honest, at the beginning we blindly expected that Vue Storefront would be a copy/paste front-end template solution that would fairly easily be made to work with its standard integration to a Magento backend. Sadly, this was not the case for us.

Before beginning our journey here, to summarize the Vue Storefront integration with Magento let’s have a look at this diagram to see what components are included:

Figure 1

At first, we wanted to see how all these components can be installed and run on a single server with modest resources.

I walked through the Vue Storefront documentation and a few blog posts to figure out Vue Storefront and Magento integration.

Preparing the Environment

I downloaded and installed the following:

OS: CentOS Linux 7 (64-bit)
PHP 7.2.26
Magento 2.3 with sample data
Elasticsearch 5.6
Redis
Docker
Vue Storefront API
Vue Storefront
mage2vuestorefront bridge

Installation of those components is fairly easy. We started our virtual server with 4 GB of memory, which we thought should be plenty for a toy setup.

Indexing Elasticsearch with mage2vuestorefront

PHP and Magento 2.3 had a series of memory usage issues. While running the mage2vuestorefront indexer Magento used most of the memory and caused Elasticsearch to go down each time I tried to index Elasticsearch. Then I configured PHP and Apache httpd server to use a very modest amount memory and made Magento 2.3 work on this server without making it crash due to unavailable memory but the performance became a nightmare on the PHP & Magento 2.3 side. mage2vuestorefront ran without issue, but very slowly.

I am not very familiar with the Magento 2 API, but while indexing Elasticsearch with mage2vuestorefront it makes several individual API calls. Especially if you have several products in Magento 2, mage2vuestorefront calls the Magento API for almost all products. Due to PHP and Magento’s high memory usage available memory might become a problem during indexing.

The Vue Storefront developers explain a big reason why they chose Elasticsearch as one of the essential components of this integration:

Vue Storefront defines itself backend-agnostic PWA e-commerce solution where Vue Storefront is a storefront as the name dictates, and Elasticsearch works as a datastore for catalog and its sibling data such as taxrule, products and so on.

I am unsure if the backend-agnostic approach even really applies to the suggested implementation of Vue Storefront with Magento 2, or if does apply with significant headaches. I’ll detail my concerns about this later.

Viewing the Vue Storefront Application

The responsive and offline supportive design of Vue Storefront is elegant. It uses Elasticsearch via vue-storefront-api as its indexing search engine to provide a seamless user experience. Although the overall integration and the produced data structure looks complex there are only a few catalog data stores that need to be indexed on Elasticsearch. Also, since this is an ecommerce integration, you can expect that only products and product-related data are going to be available in such an integration.

In the Vue Storefront and Vue Storefront API app home directories (vue-storefront/ and vue-storefront-api/) I ran npm start to start the Node.js apps, then navigated to the Vue Storefront homepage to view its default template:

Figure 2

There is a hamburger menu in the top-left which opens the categories menu of Vue Storefront:

Figure 3

As I mentioned, the data being viewed is relatively simple according to the count of the catalog types (essentially Products, Categories, Attributes, and Tax Rules) which are already categorized and these are a bunch of specific sets of data.

By searching through the categories Women > Tops > Jackets, the search output list is shown by Vue Storefront:

Figure 4

Designing a New Approach for Interchange

When exploring the features and components of Vue Storefront we discussed how we can adapt Interchange to use Vue Storefront. We ended up with two main options:

Keep the same approach of Vue Storefront’s current integration with Magento and other ecommerce backends using Elasticsearch and vue-storefront-api as the backend gateways
Remove the Elasticsearch and vue-storefront-api dependencies and create a new API in Interchange producing similar API outputs to the ones vue-storefront-api & Elasticsearch are creating. I also found a similar approach where they integrated SAP Hybris with Vue Storefront. I thought that this way would fit our intention.

Inspired By A Similar Approach of Vue Storefront + SAP Commerce

Vue Storefront + SAP Commerce: Open-source PWA Storefront Integration (+DEMO)

This article discusses several approaches, including Vue Storefront developers’ boilerplate integration and their custom solutions. In the following table they show different options and comments on their resolutions.

Figure 5

As you can see in Figure 5, they decided to go with the 4th option as their most suitable and least problematic solution. Here is their statement of why:

After some analysis, we have come to believe that using custom middleware only for a bunch of simple requests is an additional burden and thick layer of complexity. We decided to get rid of it as well.

So, option #4 turned out to be the best choice. For the option #4, we need to parse Magento and Elasticsearch APIs and generate the compatible responses.

Here is how their solution looks according to option #4:

Figure 6

Using this approach, they decided to remove the Elasticsearch and Vue Storefront API components from the Vue Storefront boilerplate integration and developed their SAP Commerce custom Vue Storefront API to produce responses similar to the responses taken from Elasticsearch through Vue Storefront API to pretend that Vue Storefront is taking its responses from Elasticsearch API + Magento API.

We decided to discard Elasticsearch when integrating Interchange with Vue Storefront for simplicity, and to cut down on the cost such additional search solutions create.

After our discussions, I was inspired by this SAP Commerce + Vue Storefront integration demo. We finally decided to move forward with creating an Interchange API to produce the similar responses to those from the Elasticsearch & Magento APIs, so we could make the Interchange API pretend to be the Elasticsearch API + Magento API.

We need to mention the Magento 2 API, or at least the Magento 2 data structure, because the Vue Storefront API and Vue Storefront boilerplate code is heavily designed to be taking ecommerce data (Products, Categories, Product Attributes, Tax Rules etc.) almost identical to the Magento API’s provided data.

So our Interchange + Vue Storefront integration looks like this:

Figure 7

Compare Figure 1 with Figure 7 to see the difference between this approach and Vue Storefront’s suggested solution.

Interchange API Prototype Design

In order to achieve the API prototyping for our Interchange/Vue Storefront integration, I cloned vue-storefront and vue-storefront-api, which I had previously integrated with Magento 2.3, into a new user, keeping all settings the same. This cloned Vue Storefront application started initially with the same configuration as vue-storefront-api and Elasticsearch were not excluded yet. So I decided to replace the vue-storefront-api endpoints that vue-storefront is calling with endpoints from the new Interchange API.

As the default SAP Commerce/Vue Storefront integration suggests, I walked through the outputs of search results in “product”, “category”, and “attributes”. Product data JSON output has some universal attributes like name or title, description, or price, but it also has some custom product attributes adapted from the Magento 2 API (specifically, the data structure of Magento is applied).

At this point I started questioning if Vue Storefront is not really platform agnostic, or if it is, but with some headaches. The next section will detail these headaches but to summarize, adapting the data structure of new ecommerce backends to Vue Storefront is a real pain. It forces you to use its data structure since that’s a part of core development, and they rely mainly on Elasticsearch, and I guess because of that the developers of Vue Storefront believe that Elasticsearch is an essential part of this “agnostic” approach. Refer to Getting data from Elasticsearch for custom implementations using the core Elasticsearch lib.

Anyway, I moved on and produced product and product categories outputs that Vue Storefront expects as the search results at the homepage and the search box output results.

Documentation is another pain. This is discussed further in the next section, but briefly, it’s hard to say that you could clearly pick the data structure that all kind of output results from the documentation. You need to dig into the TypeScript code, and the exact search output result is what is actually being expected.

One conflict was that the identifiers are required to be numeric, not strings. If your ecommerce data structure doesn’t provide its identifiers as numbers you’ll need to alter and add a new numeric unique identifier along with the existing one, which is what I did.

Product attributes also need to be adapted to Vue Storefront (really to Magento’s data structure). The attribute names, attribute lists, attributes’ assigned values, and categories attached to the products and configurable child products all come along with the product list on a search output. If your ecommerce data is not structured similarly to Magento’s data structure, you need to dig and restructure even for minimal changes like product attributes and configurable child products. For example, if your data structure doesn’t allow configurable child products then you can probably only provide each option (such as product color or size options) as a new product, which will be a real pain.

Most of Vue Storefront’s app endpoints are defined in config/default.json which is the default config on a new install. On the other hand, the ecommerce catalog data (which is indexed in Elasticsearch) is available through the Elasticsearch implementation which is by default defined in lib/search/adapter/api/searchAdapter.ts. In my case I needed to alter this implementation, which is generating the Elasticsearch (actually the Vue Storefront API) endpoints dynamically by looking up the related catalog index (product, category, attributes, taxes, etc.), and change the Elasticsearch definition in the Vue Storefront config file to the new Interchange API, adapted to emulate the Vue Storefront API and Elasticsearch:

...
  "elasticsearch": {
    "httpAuth": "",
    "host": "/api/catalog",
    "index": "vue_storefront_catalog",
...

I needed to set the Interchange API URL to the host property and not necessarily set an API-defining URL sub-path name to the index property above. This way our API would pretend to be the Elasticsearch endpoint as long as it can generate the JSON output that Vue Storefront expects.

These configuration changes generally satisfied Vue Storefront’s expectations.

Common and Exceptional Issues

Many concerns and challenges are discussed in this article on Vue Storefront + SAP Commerce integration which I mentioned earlier.

A review of some issues I detailed earlier:

Required numeric unique IDs for all catalogs (products, categories, etc.)
Poor documentation
Catalog data structure is managed on the Vue Storefront side, heavily relying on its own data types and models. Your backend may need to be adapted to meet Vue Storefront’s expectations, even if you are using Elasticsearch.
A structure which is constantly being reorganized, creating a big maintenance concern.

Conclusion

Despite my concerns, I thought we could still implement our Interchange API with a front-end framework, but I hadn’t asked the question: Is it reusable enough to mantain? Each of our clients would have different UI and UX expectations. One UI template model could never be enough, which would mean continuous front-end template design and enough maintenance to match the operational cost of existing Interchange front-end solutions. Adapting existing data to Vue Storefront’s new data model would bring more costs along with it.

While Vue Storefront’s offline working model is well designed, for the purpose of integrating with a non-Magento backend, this is overshadowed by its many issues. You would be better off looking elsewhere for a more modular, truly platform-agnostic, easier-maintained, component- and data model-independent front-end.

Cloudflare and Vue SSR; Client Hydration Failures

2019-06-11T00:00:00+00:00

Photo by freestocks, used under CC0 1.0

I recently worked on getting a client’s Vue application converted to use Server Side Rendering (SSR). SSR works by generating the app’s initial HTML structure using a server-side process and then using client-side JavaScript to initialize or “hydrate” the application state on the client-side.

This worked out well in development and testing, however when it came time to roll things out to production, we ended up with a non-functioning application. While the server-rendered content was displaying inline, the client hydration piece was failing, and I was seeing browser console errors that I had never encountered before:

The error in Chrome:

chunk-vendors.342a7610.js:21 Uncaught DOMException: Failed to execute 'appendChild' on 'Node': This node type does not support this method.
...

The error in Safari:

[Error] HierarchyRequestError: The operation would yield an incorrect node tree.
	get (chunk-vendors.342a7610.js:27:30686)
	er (chunk-vendors.342a7610.js:27:30565)
	Le (chunk-vendors.342a7610.js:27:27806)
	xe (product-listing.0773c46e.js:1:18553)
[Error] TypeError: undefined is not an object (evaluating 't.$scopedSlots') — chunk-vendors.342a7610.js:27:27998
	on (chunk-vendors.342a7610.js:27:12025)
	rn (chunk-vendors.342a7610.js:27:11937)
	nn (chunk-vendors.342a7610.js:27:11584)
	(anonymous function) (chunk-vendors.342a7610.js:27:12759)
	fn (chunk-vendors.342a7610.js:27:12135)
	promiseReactionJob

Since the client hydration was failing, this resulted in a non-functioning front-end application which we had to quickly roll back. I’d scratched my head over this quite a bit, as this had been well-tested in development and staging.

After testing direct access to the origin server via /etc/hosts modification, we determined that the server itself was returning content that was working fine, so this pointed to something about the caching layer.

The errors being generated were similar to errors I’d encountered before during development where the generated DOM in the SSR content was mismatched with the version of the client-side Vue application.

One of the big differences here was that production was being served via Cloudflare (CF), however we had not run into any issues with stale versions (i.e., older versions of code being returned) and the like in the past. Our resources were stamped hashes via webpack, so per-application version shouldn’t have been utilizing cached old versions of the generated resources in question.

Because we could not really debug this issue on production and this was still just a theory that CF was the issue, we ended up setting up a development environment behind Cloudflare.

Sure enough, the same issue started occurring in the development environment with Cloudflare fronting it; now, however, we had time to debug/diagnose without affecting production users.

After comparing the static JS for the app returned through CF against the raw source files, I noticed that they were slightly smaller. We had already minified the source as part of our production build, but CF was further minifying things, removing newlines and JS comments that had been left in the prod build. This made me realize that something on the CF side was minifying resources further.

After some research, it turns out the CF has an AutoMin setting to allow the automatic minification of served resources (JS, CSS, and HTML). This setting was contributing to the minification that I was seeing. However, this could not explain what I was seeing on the JS minification alone; these were verified non-functional changes that should not affect how the app ran.

I turned my attention to the HTML of the page itself. Comparing the CF-returned version with the version returned by the app, I quickly saw that minification was affecting this returned HTML as well, cleaning up spacing/formatting and HTML comments as well.

And herein lay the issue; Vue SSR sticks in HTML comments as placeholders for nodes which are non-visible at server render time. So for example, if you had a Vue component like so:

<template>
  <div>
    My component!
    <div v-if="display">
      <p v-for="l in list">
        {{ l }}
      </p>
    </div>
  </div>
</template>

<script>
export default {
  name: 'MyComponent',
  data () {
    return {
      list: [1, 2, 3]
    }
  }
  props: {
    display: {
      type: Boolean,
      default: false
    }
  }
}
</script>

This would render in Vue SSR as the following HTML (assuming the component was not shown by the calling app):

<div>My component!<!-----></div>

Here, the  placeholder is a significant HTML comment, standing in for a non-visible component in the virtual DOM (the false condition in the v-if directive). Rehydration requires this to be in place for proper handling, so when CF stripped out HTML comments from the returned page output this disrupted the generated server-side DOM. This meant that the server-side DOM no longer matched what Vue was expecting and the client-side hydration failed and the app failed to init properly.

I tested disabling AutoMin for the test site, which resulted in a functioning application, verifying this was the issue. We did not want to turn off AutoMin globally, so I looked around for ways to narrow this down to only the affected pages (all of which had a common URL prefix).

I came across CF’s Page Rules settings, which let you modify its handling of specific URLs. I added an exception for the pages in question, turning off only the AutoMin setting for these pages, and voilà, the app worked while leaving this setting on for the rest of the site.

TL;DR:

Cloudflare’s AutoMin setting can interfere with Vue SSR output by removing significant HTML comments. The fix is to disable AutoMin on the relevant pages using Page Rules.

Vue.js Remote Devtools Review

2019-06-01T00:00:00+00:00

Photo by Marco Verch, used under CC BY 2.0

Most Vue.js developers will be familiar with Vue.js devtools in the form of Chrome or Firefox browser extensions/addons. The Vue.js devtools integrate nicely into Chrome and Firefox’s native developer tools in the form of a new ‘Vue’ tab that provides a developer with the ability to browse their component hierarchy, investigate the state of their application’s Vuex store, and several other useful features.

I was a longtime Safari user who eventually became disappointed with its limited extension support (as compared to Chrome or Firefox-based browsers); there was once a Safari version of Vue.js devtools that required some manual installation, but development on that version ended back in early 2018.

An alternative for Safari users, or developers who want to debug Vue.js applications running on other clients such as mobile devices, is the standalone vue-remote-devtools app. vue-remote-devtools is an Electron app that runs in its own window and is loaded in a Vue.js application via a remote connection. I was curious to see how the developer experience of using vue-remote-devools compared to the Chrome browser extension that I was familiar with.

Installation of vue-remote-devtools was simple, with just a single yarn global add @vue/devtools command. Once installed, I was able to run the app with a vue-devtools command which opened a new window on my desktop:

Then it was a matter of updating my Vue.js application to connect to Vue.js remote devtools running locally on my laptop. I added the <script src="http://localhost:8098"></script> tag to my application’s index page as described in the vue-remote-devtools documentation. When I loaded my Vue.js application in Safari I was confronted with a new problem: a Content-Security-Policy error preventing the browser from connecting to local port 8098:

My Vue.js application is served from a Rails application via webpacker and already had a CSP in place, so it was relatively easy to update that with the needed configuration:

# config/initializers/content_security_policy.rb
Rails.application.config.content_security_policy do |policy|
  policy.script_src :self, :https, :unsafe_eval, :unsafe_inline, 'http://localhost:8098'
end

After restarting Rails to load the updated CSP initializer, my Vue.js application successfully connected to Vue.js remote devtools and I saw an interface that was almost identical to what I was used to from the Chrome Vue.js devtools extension:

I’m glad that vue-remote-devtools exists and provides feature parity with the browser-based devtools, especially for debugging Vue.js applications running on mobile devices where there are no alternatives, but I will be sticking with the Chrome extension for my everyday use. I didn’t like the additional configuration needed to add a separate script tag and make a change to the CSP just to get the remote devtools connection established; in a multi-developer project, the script tag would introduce “Failed to load resource” browser console errors for any other developers who didn’t happen to be running remote devtools on their machines. I also found myself missing the way that the Chrome/Firefox extensions integrate nicely alongside those browsers’ existing developer tools, making it easy to switch between the Vue.js devtools and the JavaScript console or Elements view.

Introduction to Snapshot Testing Vue Components

2019-05-02T00:00:00+00:00

Photo by freestocks, used under CC0 1.0

Snapshot Testing is one of the features of the Jest testing framework that most interested me when I began researching methods for testing Vue.js applications. Most of my testing experience has involved writing many verbose RSpec unit tests for Rails applications, and the promise of being able to use snapshot tests to cover more of a Vue component’s output while writing less code appealed to me. Snapshot testing does have its critics, so I have been interested to start exploring snapshot tests myself to see if they can be a valuable addition to my testing toolkit, or if they are not worth the effort.

Snapshot testing gets its name from the mechanism used to determine whether tests pass or fail by comparing them to a previously-approved reference point, or “snapshot”. With Jest snapshot testing of Vue components, the snapshot takes the form of a text file with a ‘.snap’ extension stored within a __snapshots__ subdirectory alongside the test files:

I decided to generate a new project using Vue CLI to do my first experiments with snapshot testing in a sample project. The project generated by Vue CLI includes one ‘HelloWorld’ component with a Jest unit test file included, so it made a good starting point for converting over to snapshot testing.

The generated test file was:

// HelloWorld.spec.js
import { shallowMount } from '@vue/test-utils'
import HelloWorld from '@/components/HelloWorld.vue'

describe('HelloWorld.vue', () => {
  it('renders props.msg when passed', () => {
    const msg = 'new message'
    const wrapper = shallowMount(HelloWorld, {
      propsData: { msg }
    })
    expect(wrapper.text()).toMatch(msg)
  })
})

and I converted it to use a snapshot test by changing one expect line:

// HelloWorld.spec.js
import { shallowMount } from '@vue/test-utils'
import HelloWorld from '@/components/HelloWorld.vue'

describe('HelloWorld.vue', () => {
  it('renders props.msg when passed', () => {
    const msg = 'new message'
    const wrapper = shallowMount(HelloWorld, {
      propsData: { msg }
    })
    expect(wrapper).toMatchSnapshot()
  })
})

Converting this test to a snapshot test allows me to test the entire output of the component in one pass by comparing it to a stored snapshot of itself.

Running jest for the first time with the new test file will generate a “known good” reference snapshot:

And running the same command a second time will now check the component against the stored snapshot:

In a contrived effort to see what a failing test looks like, I updated the template of the HelloWorld component being tested and changed its text interpolation:
from {{ msg }} to {{ msg.toUpperCase() }}.

The snapshot test for this component now fails and indicates how the rendered output differs from the previously-stored snapshot, where the interpolated string is converted to uppercase:

If the change I made to the template was a desired one, I could now run jest -u to update the stored snapshot, acknowledging that the change was intended and making this version the new reference. The Jest documentation recommends treating snapshots as code and committing them as you would any other type of code or test, so it would make sense to commit the updated snapshot alongside the change to the component itself.

This is a very basic example, but hints at the power available from using snapshot testing to provide a large amount of test coverage without much code by comparing the current output of a component against a previously-approved reference version of itself. I’m looking forward to putting this style of testing into practice in some of my Vue projects and seeing how useful snapshot tests turn out to be in a real-world workflow.

Adding Awesomplete to Vue Components

2019-01-31T00:00:00+00:00

IBM Model M SSK by njbair, used under CC BY-SA 2.0 / Cropped from original

Awesomplete is an “Ultra lightweight, customizable, simple autocomplete widget with zero dependencies, built with modern standards for modern browsers.”

Awesomplete caught my attention when I was looking for a lightweight autocomplete implementation to add to an existing, heavily styled form in a Vue.js single-file component. There are no fewer than 10 options on the Awesome Vue.js list of autocomplete libraries, but many of them brought their own dependencies or custom styling and I was looking for something simpler to add autocomplete features to my form.

I have created a live JSFiddle demo showing an implementation of Awesomplete in a Vue.js app, but the remainder of this post contains more details about adding Awesomplete to a single-file component in a larger Vue application.

Here is a screenshot and sample code for a simplified version of the Vue single-file component that I was working with:

<template>
  <div>
    <h2>Search by Name</h2>
    <p>
      <em>
        Options: {{ names.join(', ') }}
      </em>
    </p>

    <form>
      <input
        id="name-input"
        placeholder="Enter a name"
        type="text"
      >
    </form>
  </div>
</template>

<script>
export default {
  data () {
    return {
      names: [
        'Colin Creevey',
        'Seamus Finnigan',
        'Lee Jordan'
      ]
    }
  }
}
</script>

In my actual application I was populating the data object with API data via vue-apollo, but I’ve hard-coded the array of strings here for simplicity.

Adding autocomplete to my form with Awesomplete was as easy as adding the package to my project with yarn awesomplete and then updating the Vue component to load the library and attach it to my form:

<template>
  ...
</template>

<script>
import Awesomplete from 'awesomplete'

export default {
  data () {
    return {
      names: [
        'Colin Creevey',
        'Seamus Finnigan',
        'Lee Jordan'
      ]
    }
  },
  mounted () {
    let input = document.getElementById('name-input')
    new Awesomplete(input, { minChars: 3, list: this.names })

    input.addEventListener('awesomplete-select', (e) => {
      alert(`selected ${e.text.value}`)
    })
  }
}
</script>

All of the Awesomplete work is taking place in the component’s mounted() function, where the form input is stored in a variable, passed to a new Awesomplete instance along with an options object, and then a listener function is added to take some action when the user has selected an autocomplete value. That action would typically be a form submission, but I am just using an alert for the purposes of this demo.

Awesomplete has many options for customization and is well-documented in general. I encourage anyone looking to add autocomplete features to their projects to give it a try; I was impressed by how easily I was able to use it to add autocomplete features that integrated well with my project.

Vue, Font Awesome, and Facebook/Twitter Icons

2018-07-12T00:00:00+00:00

Overview

Font Awesome and Vue are both great technologies. Here I detail overcoming some issues when trying to get the Facebook and Twitter icons working when using the vue-fontawesome bindings in the hopes of saving others future debugging time.

Detail

Recently, I was working with the vue-fontawesome tools, which have recently been updated to version 5 of Font Awesome. A quick installation recipe:

$ yarn add @fortawesome/fontawesome
$ yarn add @fortawesome/fontawesome-svg-core
$ yarn add @fortawesome/free-solid-svg-icons
$ yarn add @fortawesome/free-brands-svg-icons
$ yarn add @fortawesome/vue-fontawesome

A best practice when using Font Awesome is to import only the icons you need for your specific project instead of the thousand+, as this just contributes to project bloat. So in our main.js file, we import them like so:

// Font Awesome-related initialization
import { library } from '@fortawesome/fontawesome-svg-core'
import { faEnvelope, faUser } from '@fortawesome/free-solid-svg-icons'
import { faFacebook, faTwitter } from '@fortawesome/free-brands-svg-icons'
import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome'

// Add the specific imported icons
library.add(faEnvelope)
library.add(faUser)
library.add(faFacebook)
library.add(faTwitter)

// Enable the FontAwesomeIcon component globally
Vue.component('font-awesome-icon', FontAwesomeIcon)

This allows you to include icons in your view components like so:

<template>
  <div class="icons">
    <font-awesome-icon icon="user"/>
    <font-awesome-icon icon="envelope"/>
  </div>
</template>

This worked fine for me until I tried to use the facebook and twitter icon:

<template>
  <div class="icons">
    <font-awesome-icon icon="user"/>
    <font-awesome-icon icon="envelope"/>
    <font-awesome-icon icon="twitter"/>  <!-- broken -->
    <font-awesome-icon icon="facebook"/> <!-- broken -->
  </div>
</template>

Only blank spots and errors in the browser console like so:

[Error] Could not find one or more icon(s) (2)
{prefix: "fas", iconName: "twitter"}
{}
[Error] Could not find one or more icon(s) (2)
{prefix: "fas", iconName: "facebook"}
{}

After turning up dry from a run to the Google well and scanning the docs, I determined that this must come down to a difference in the prefix; since the icons that worked were being imported from the free-solid-svg-icons library, it would seem that that was the source of the fas prefix. Since the non-working icons were coming from the free-brands-svg-icons library it stood to reason that somehow passing in a prefix parameter of fab would work.

I tested modifying things like follows, just to exercise potentially obvious answers. Sadly, this did not result in workage.

<template>
  <div class="icons">
    <font-awesome-icon icon="user"/>
    <font-awesome-icon icon="envelope"/>
    <font-awesome-icon icon="twitter" prefix="fab"/>  <!-- still broken -->
    <font-awesome-icon icon="fab-facebook"/>          <!-- also still broken -->
  </div>
</template>

I finally took to the original source for the FontAwesomeIcon component (every engineer’s favorite thing, aside from brown paper packages tied up with string), and noted the following:

function normalizeIconArgs (icon) {
  if (icon === null) {
    return null
  }

  if (typeof icon === 'object' && icon.prefix && icon.iconName) {
    return icon
  }

  if (Array.isArray(icon) && icon.length === 2) {
    return { prefix: icon[0], iconName: icon[1] }
  }

  if (typeof icon === 'string') {
    return { prefix: 'fas', iconName: icon }
  }
}

AHA! The icon parameter is what was passed in in the <font-awesome-icon> component, so I immediately attempted to utilize an object to pass the prefix and the iconName parameter (since this is the name in the object referenced here, it should be the key).

So I ended up trying:

<template>
  <div class="icons">
    <font-awesome-icon icon="user"/>
    <font-awesome-icon icon="envelope"/>
    <font-awesome-icon :icon="{ prefix: 'fab', iconName: 'twitter' }"/>
    <font-awesome-icon :icon="{ prefix: 'fab', iconName: 'facebook' }"/>
  </div>
</template>

(I am omitting the part where I stupidly left out the leading : to pass in an explicit object instead of a string equivalent.)

Everything worked! And there was much rejoicing! Hope this helps someone else who had the same issue as me.

Start basic application with Vue.js 2 and Drupal 8

2018-04-05T00:00:00+00:00

Introduction

The purpose of creating this post is to show how fast can you build web applications with Vue.js on the front-end and Drupal on the back-end side.

Let’s call our project “Awesome Nerds”.

What do we need?

Debian/Ubuntu system
Internet
30 minutes
Vagrant & VirtualBox
Git
Vim
Yarn

Step by step

Here’s what we’re going to do:

Install Vagrant, VirtualBox, and Git
Setup a new Drupal 8 project that will be our back-end project
Setup a new Vue.js project that will be our front-end application
Let’s code

Install Vagrant, VirtualBox, and Git

Open your console and run:

$ sudo apt-get install software-properties-common - getting some common libraries

$ sudo apt-add-repository ppa:ansible/ansible

$ sudo apt-get update

$ sudo apt-get install ansible - installing Ansible

$ wget ‘https://releases.hashicorp.com/vagrant/2.0.2/vagrant_2.0.2_x86_64.deb’ && dpkg -i vagrant_2.0.2_x86_64.deb - installing Vagrant

$ sudo apt-get install dkms

$ deb https://download.virtualbox.org/virtualbox/debian <mydist> contrib

$ wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -

$ wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -

$ sudo apt-get update

$ sudo apt-get install virtualbox-5.2 git vim nfs-kernel-server - installing VirtualBox

$ vagrant plugin install vagrant-vbguest

$ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -

$ echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

$ sudo apt-get update && sudo apt-get install yarn - installing Yarn

Now we can continue to the back-end project installation.

Install and setup back-end project

Create a new folder for the project:

$ mkdir awesome_nerds && cd awesome_nerds

$ mkdir frontend backend

We need to clone the DrupalVM repository. DrupalVM is a Drupal setup that helps to encapsulate services with Vagrant. Run:

$ cd backend

$ git clone git@github.com:geerlingguy/drupal-vm.git .

Let’s name our project:

$ vim default.config.yml

Look and set these two settings so they look like this:

vagrant_hostname: awesomenerds.backend                                   
vagrant_machine_name: awesomenerds_backend

Quit Vim and run:

$ vagrant up

It will take a while to set up everything, you can get a coffee or browse some memes or go to the next chapter and start creating our front-end project.

When it’s ready we will have a running Drupal 8 setup with MySQL, PHP 7, and Apache (you can configure this stack in default.config.yml if you prefer nginx for example).

Drupal project files are in the drupal directory and that’s the only folder that you would want to add to a project Git repository.

Setup new Vue.js project

We will use a minimal project skeleton from https://github.com/vuejs-templates/webpack.

Run:

$ cd awesome_nerds/frontend

$ git clone https://github.com/vuejs-templates/webpack .

$ yarn install -g vue-cli

$ vue init webpack awesome_nerds

Name the project “awesome_nerds” (yes!) and just hit enter to install with defaults.

When you run:

$ yarn run dev

you will get a fresh Vue.js application running on http://localhost:8080.

Let’s code!

Now we are ready for development. It can be really rapid, both Vue.js 2 and Drupal 8 are impressively good and it’s just a matter of finding a good idea for your new start-up.

In my next post I will continue and code a simple social application using the REST API of Drupal and our Vue.js front-end.

Thank you and good luck!

Vue in Ecommerce: Routing and Persistence

2018-03-01T00:00:00+00:00

I recently wrote about Vue in Ecommerce and pointed to a handful of references to get started. Today, I’ll talk about using vue-router in a small ecommerce application, combined with vuex-persist for state storage.

I forked this Vue Shop on GitHub from Matheus Azzi. It was a great starting point for to see how basic component organization and state management might look in a Vue ecommerce application, but it is a single page ecommerce app with no separate page for a product detail, checkout, or static pages, so here I go into some details on routing and persistence in a Vue ecommerce application.

Vue Router

In looking through the documentation, I don’t see a great elevator pitch on what it is that Vue Router does. If you are new to routing, it’s a tool to map the URL request to the Vue component. Since I’m coming from the Rails perspective, I’m quite familiar with the Ruby on Rails routing from URL pattern matching, constraints, resources to Ruby on Rails controllers and actions. Vue routing via vue-router has some similar elements.

When you create a basic Vue application via vue-cli, you are given the option to include vue-router:

vue init webpack myapp

? Project name myapp
? Project description A Vue.js project
? Author Steph <steph@endpoint.com>
? Vue build standalone
? Install vue-router? (Y/n)

If you select Yes here, the main differences you’ll see are that an application with vue-router installed will call <router-view/> to render the view for the current router, instead of a <HelloWorld/> component, and that a vue-router app will include src/router/index.js with basic routing configuration to your <HelloWorld/> component.

Without Routing

// App.vue without vue-router
<template>
  <div id="app">
    <img src="./assets/logo.png">
    <HelloWorld/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld'

export default {
  name: 'App',
  components: {
    HelloWorld
  }
}
</script>

With Routing

// App.vue with vue-router
<template>
  <div id="app">
    <img src="./assets/logo.png">
    <router-view/>
  </div>
</template>

<script>
export default {
  name: 'App'
}
</script>


// src/router/index.js
import Vue from 'vue'
import Router from 'vue-router'
import HelloWorld from '@/components/HelloWorld'

Vue.use(Router)

export default new Router({
  routes: [
    {
      path: '/',
      name: 'HelloWorld',
      component: HelloWorld
    }
  ]
})

Moving on, building out an ecommerce app with some basic page set up, not including user accounts, might look like the setup below, which includes basic components and routes for the Home, Cart, Checkout, Receipt, and About page. This simplified set-up doesn’t even include a product detail page, but one could accomplish that with a bit of URL matching via parameters.

// src/router/index.js
import Vue from 'vue'
import Router from 'vue-router'

import Home from '@/components/pages/Home'
import Receipt from '@/components/pages/Receipt'
import About from '@/components/pages/About'
import Cart from '@/components/pages/Cart'
import Checkout from '@/components/pages/Checkout'

Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    { path: '/', component: Home },
    { path: '/receipt', component: Receipt },
    { path: '/about', component: About },
    { path: '/cart', component: Cart },
    { path: '/checkout', component: Checkout }
  ]
})

History Mode

One thing you also might notice is the ‘history’ mode setting above, overriding the default hash mode. You can read about that here, but it leverages history.pushState to URL navigation. The history mode override must be combined with server configuration to ensure that non-static asset URL requests (i.e. all of our routes) hit the Vue index.html app in our Vue application, and then renders the component associated with the requested route. I’m using Apache for my Vue application, so I followed the instructions on that documentation for vue-router history mode configuration.

Using <router-link/>

One thing you also will want to use throughout your templates is <router-link/>, instead of hard-coding rigid URL paths. For example, instead of linking to the cart via <a href="/cart">Cart</a>, you’ll want to link via <router-link to="cart">Cart</router-link>. This will be resolve to the proper link upon rendering depending on your routing configuration.

Vuex PersistedState

If you are still reading, you’ve now seen the basic configuration for vue-router in an ecommerce application running on Vue. The ecommerce application I forked uses vuex, a state management pattern and library to store the state of our application. What you’ll notice with a shopping cart application, though, is that you need to persist the state of your cart for sessions. Without further setup, every page refresh on your application will result in losing the state of the cart.

To address this behavior, there are a few options to persist your state in Vue. I chose vuex-persist, which stores the state (for all modules or specific modules) in localStorage. After installing vuex-persist, I modified the following to include the shoppingCart module in my stored state:

// src/store/index.js
import Vue from 'vue'
import Vuex from 'vuex'
import VuexPersistence from 'vuex-persist'
// import other stuff

Vue.use(Vuex)
const vuexLocal = new VuexPersistence({
  storage: window.localStorage,
  reducer: state => ({
    shoppingCart: state.shoppingCart
  })
})

export default new Vuex.Store({
  // ...
  plugins: [vuexLocal.plugin]
})

It’s as simple as that to persist the state of your shopping cart using all the vuex-persist defaults, and there are some alternative Promise-based stores supported if you are interested.

What’s Next?

What’s next in building out your ecommerce application? From here, one might consider adding user authentication & authorization support, as well as support for retrieving and rendering products in the product list view. I hope to address those in upcoming blog posts in this series on Vue in ecommerce.

Vue and Ecommerce: An Introduction

2018-02-19T00:00:00+00:00

I speak the domain specific language of ecommerce, Ruby on Rails, JavaScript, and jQuery. Lately, I’ve been getting up to speed on Vue.js. I’ve been working on writing a small ecommerce site using Vue.js, because for me, creating an application addressing familiar paradigm in a new technology is a great way to learn.

Vue.js, initially released about 3 years ago, is a lightweight JS framework that can be adopted incrementally. In the case of my small example site, Vue.js serves the frontend shop content and connects to a decoupled backend that can be run on any platform of choice. On my path to get up to speed on Vue, I found great resources that I wanted to write about before I get into the details of my ecommerce app. Here they are:

First, I started with the Vue.js documentation. The documentation is great as a starting point to understand some of the terminology. I often don’t love the documentation that comes with technologies, but I found the Essentials section in the Vue documentation to be a great launching point.
After I worked through some of the Vue.js documentation, I did a simple search for “vue jsfiddle” and experimented with a few of those fiddles. Having come from a jQuery background (with mustache), I was familiar with how templating and logic inside a template might work, but less familiar with the vue instance and binding, so I targeted jsfiddles with this in mind.
Next, I looked for resources with Vue + ecommerce specifically. Here’s where I found some good stuff:
- Scotch.io Course on Vue + Ecommerce: This online course has a great amount of overlap with the main documentation of Vue, but some of the examples are ecommerce specific, which serves as a good introduction.
- Vue + Third Party Integration for Ecommerce: This Medium article talks about integrating third party tools used with Vue (Stripe, AWS S3, Heroku) to build an ecommerce site. While this post doesn’t go into the nitty gritty details of a Vue application, it does provide many code examples for checkout and payment integration, although noting that vue-stripe-elements is now the module of choice for Stripe integration in Vue.
- Vue API App + Magento Backend: This is a front-end open source Vue application designed to pair with a Magento backend, capitalizing on the popularity of Magento.
- Moltin: This company is providing backend microservices for ecommerce, with Vue.js support (and other technologies) to build out your store.
- Vue + Ecommerce with Vuex: Here’s another Medium article which features vuex, the state management library in Vue, essentially going through examples of state management to manage a shopping cart.
- CodePen Vue + Ecommerce Example: Here’s a standalone CodePen example of a Vue shopping cart. While I find this a little hard to parse because there’s a significant amount of code in the example, you can download and experiment with it.
- Stripe Integration Example: Here’s a GitHub repo that demonstrates Stripe integration in serverless Vue shop.
- Basic Vue Shop on GitHub: Why reinvent the wheel when someone has already built out product listing and cart functionality? After reviewing all the examples above, this was my choice for a starting point in building out a Vue shop, but it is a basic starter point, without the use of vue-router.

Vue Libraries / Dependencies

You might have noticed I mentioned a few Vue libraries and tools. Here are additional resources for getting up to speed on those dependencies:

Installing Node.js and npm, if you aren’t already familiar with it. Here is a great comparison if you are coming from the Rails space.
Already mentioned, vuex state management in Vue.
vue-router. In an ecommerce site, you would possibly have routing for the index, product detail, cart, checkout, user account, order detail pages.
vue-cli: simple command line interface for scaffolding Vue projects. Think “rails generate …” for Vue.
vue-resource, or a comparable module (vue-axios) for making API and AJAX requests.

Incremental Adoption

While I am writing a Vue ecommerce shop based on the shop-vue GitHub repo mentioned above, in the ecommerce space, we commonly take on incremental ecommerce updates rather than “The Big Rewrite”, as noted in Greg’s article. Components that could be introduced incrementally into existing ecommerce applications might include:

Dynamic marketing elements on homepage or product listing page, e.g. promo tools, “Customers Also Looked at”, “Products Recently Viewed”
Cart + Checkout process (standalone component)
Admin elements for data management and processing
User account section

Enhancing Your Sites with Vue.js

2017-12-26T00:00:00+00:00

Framework Fatigue

When developers consider and evaluate front-end frameworks they often think in terms of writing or rewriting their entire project in Framework X. “Should we use Vue, React, Preact?” or “I heard about Sapper the other day, has anyone tried that?” The running joke response (back-end developers especially love this one) is to the effect of: “If we wait a couple weeks there will be ten more choices!”

All joking aside, frameworks like Vue and React offer many great benefits and can be incrementally adopted to enhance existing sites. There is no need to rewrite your entire project as a Single Page Application to take advantage of what frameworks like Vue offer. I have taken this approach on a couple of my projects recently and been very happy with the results.

Start Small

One of the benefits of using a framework in this way is that you’re not forced to adopt its entire toolchain and specific workflow immediately, such as using ES6/2015, webpack, and Babel right off the bat. I simply loaded the minified, minimal version of Vue I needed on my page and I was off to the races.

If you are familiar with Angular, Vue has a similar concept of custom directives. I used this to build a small countdown timer directive for a customer who wanted to dynamically display the time left before promotions ended. By offloading the DOM updates and rendering to Vue, I was able to create a useful feature very quickly with lean and readable JavaScript code.

Here’s what the widget I delivered to the client looked like:

<countdown-timer start="{start date/time}" end="{end date/time}" />

They were able to drop this snippet onto their pages and use multiple instances of the widget on their product listing page with ease.

Wishlist Pagination

For another project I needed to display wishlists in the cart, below the items the customer had previously added. The wishlist feature is very popular and used by a large number of customers. Many customers have dozens (some hundreds!) of products in their wishlist at any given time.

For this project I was already using gulp to handle the front-end automation so I simply added Vue and vuejs-paginate to the project config and loaded those scripts asynchronously on the cart page. The vuejs-paginate plugin has a simple API that emitted the pagination related events I could tap into.

With a small Vue template and less than 100 lines of code I was able to create a dynamic and very responsive (read: fast!) pagination feature without any DOM manipulation code (e.g. updates, insertions, deletions, etc.).

With Vue (React and friends as well) you simply manage the state of your application (wishlist items in this case) and let the framework handle the rendering step. Give it a try—I think you’ll like it!

Learning Vue 3 composables by creating an invoice generator

What are Vue 3 composables?

Core functionalities for invoice generator

Prerequisites

Setting up the project

Create first composable for invoice: useInvoice

Define interfaces for Invoice and InvoiceItem

Adding business logic

Rendering the invoice with composable functions

Create a second composable for using localStorage to save and retrieve invoice data

Printing Invoice

Bonus: create a third composable for showing dashboard data

Next Steps

Conclusion

Introduction to Nuxt3 and Rendering Modes

Nuxt3 features

Rendering Modes

1. Universal Rendering (SSR + CSR)

2. Client-Side Rendering (CSR)

3. Hybrid Rendering

Passing Data Between Components in Vue.js: An Overview

Props

Usage

Pros:

Cons:

Custom Events: Emitting Changes from Child to Parent

Usage:

Pros:

Cons:

EventBus: A Centralized Event Hub

Usage:

Pros:

Cons:

Vuex: State Management for Larger Applications

Building Ecommerce Search Using Algolia

Loading the index with data

Configuring the index

Setting up search on the frontend

Using faceting for search refinement and filtering

Wrapping up: seeing Algolia in action

Upgrade Vue to TypeScript

Installation

Convert your component files

Add lang="ts" to the <script> tag

Replace the default export with a class that extends Vue and uses the Component decorator

Replace props with class properties marked by the @Prop decorator

Replace data with individual class properties

Add a typed $refs class property

Replace computed with getter and setter class properties

Lifecycle hooks become class methods

Replace methods with individual class methods

Replace this.$emit with class methods using the @Emit decorator

Convert your store

Conclusion

How to write end-to-end & component tests with Cypress in Vue.js

How to install and set up Cypress

How to create a simple to-do app with Vue 3

How to write end-to-end tests

How to write component tests

Component tests for BaseTextInput.vue

Component tests for TodoListItem.vue

Next steps

Integrating Contentful with NuxtJS

Pricing

Creating content

Integration

Other content types

Alternatives

Building a search suggestions feature with Node.js and Vue

The backstory

Picking a route and configuring it

Node.js time

Enter Vue

Performance wins

Managing the Node.js process

Great success!

Vue GraphQL integration using Apollo Client

Introduction

Getting started

Setting up VueApollo

Create first composable for invoice: `useInvoice`

Define interfaces for `Invoice` and `InvoiceItem`

Add `lang="ts"` to the `<script>` tag

Replace the default export with a class that extends `Vue` and uses the `Component` decorator

Replace `props` with class properties marked by the `@Prop` decorator

Replace `data` with individual class properties

Add a typed `$refs` class property

Replace `computed` with getter and setter class properties

Replace `methods` with individual class methods

Replace `this.$emit` with class methods using the `@Emit` decorator

PoC of Vue Storefront/Magento 2.3

Vue, Font Awesome, and Facebook/Twitter Icons