Using VueJS to apply filters to an object causes a decrease in my application's performance

Question

Using VueJS to apply filters to an object causes a decrease in my application's performance

Recently, I've been working on implementing a filter for a search bar.

However, I've noticed that whenever I input something into the search bar, there is a noticeable delay as it loads the entries. I'm not sure if this issue is related to rendering problems or if my approach is simply not suitable given the size of the object, which contains around 2500 entries.

The object structure includes keys such as:

{
  key1: {
    title: 'title',
    description: 'description',
    footerContent: 'footerContent'
  },
  key2: {
    title: 'title',
    description: 'description',
    footerContent: 'footerContent'
  },
  key3: {
    title: 'title',
    description: 'description',
    footerContent: 'footerContent'
  }
}

To filter this object, I have created the following computed function:

filteredItems() {
  if(this.searchQuery) {
    return Object.fromEntries(
      Object.entries(this.items).filter(([key]) => {
        return this.searchQuery
        .toLocaleLowerCase()
        .split(" ")
        .every(
          (word) =>
          key.toLocaleLowerCase().includes(word)
        )
      })
    )
  }
  return this.items
}

Subsequently, in the template, I use a v-for loop like so:

<tbody>
  <tr v-for="item, key in filteredItems" :key="key">
    <td class="align-middle">{{key}}</td>
    <td><input type="text" class="form-control" v-model="item.title"/></td>
    <td><input type="text" class="form-control" v-model="item.description"/></td>
    <td><input type="text" class="form-control" v-model="item.footerContent"/></td>
  </tr>
</tbody>

javascript vue.js

Answer 1

Answer №1

Expensive costs in web design are not only associated with filtering, but also with rendering. Developing "autocomplete" or "typeahead" functionalities has stemmed from challenges like re-rendering a large HTML table with 2.5k rows on every keystroke - a task that would be equally slow in React, Angular, Svelte, or vanilla JS.

Rendering such a high number of rows translates to managing 12.5k DOM nodes due to the nature of HTML tables where each cell impacts its row and column dimensions. Table rendering is notoriously resource-intensive among DOM layout operations.
Interestingly, companies like Google and Microsoft opted for <div>s with display:flex over traditional Excel grid implementations in their online versions.

In optimizing performance, one efficient solution involves implementing pagination to restrict the number of rendered rows at a time based on viewport capacity. This approach enhances filtering responsiveness without excessive effort.

Pagination should primarily serve as a visual enhancement, keeping all items active in memory while displaying only a limited subset determined by a defined pageSize.

Alternatively, if pagination proves insufficient for presenting your data efficiently, employing a virtual scroller technique could serve as a viable solution. Virtual scrolling typically requires custom calculations using lower-level DOM APIs but can be facilitated through suitable packages.

The concept of a virtual scroller entails creating an empty container to generate scrollbars (referred to as SC) alongside a display window (DW) rendering currently visible content. Subsequent updates to DW contents are synced with SC scroll actions.

For uniform row heights and widths across columns, calculating DW contents is straightforward. Check out this demo simulating 10 billion cells (100k × 100k).

Although complex layouts with variable row heights or flexible column widths necessitate complete rendering initially to lock down respective dimensions, subsequently storing these values allows dynamic positioning of DW contents at different scroll positions.

To implement a virtual scroller with custom cell sizes, follow these steps:

Create a parsing container at table mount solely for dimension calculation purposes
Store calculated row heights, top positions, and column widths before discarding parsing container
Continue with standard virtual scroller set-up, adjusting calculations for specific row display logic
Update calculation method upon resize events or data changes
Maintain current first visible row in DW for smooth resizing transitions
Establish criteria for when stored position data should be refreshed

Educating yourself on the mechanics underlying performance issues equips you to make informed decisions tailored to your use case. Should you choose to tackle the challenge of implementing a virtual scroller and encounter difficulties, I'm available for assistance post your initial attempt. Create a prototype on platforms like codesandbox.io to gauge progress and identify potential roadblocks.

Answer 2