b-table: Filter Debounce does not work with computed properties or data attributes in the custom filter function

[WillGoldstein]

Describe the bug

filter-debounce no longer works if the custom filter-function attempts to access a data or computed property.

Steps to reproduce the bug

This fiddle will illustrate the issue:
https://jsfiddle.net/0jd54wpn/1/

Notice you can try it by accessing the computed property, the data property, or both. Just comment out and see the results. Comment both if statements in filterFunction to see debounce working as expected.

Expected behavior

I expect the debouncer to work no matter what you need or try to access from within the custom filter function.

Versions

Libraries:

• BootstrapVue: 2.0.2
• Bootstrap: 4.3.1
• Vue: 2.6.10

Environment:

• Device: Windows
• OS: 10 Pro
• Browser: Chrome
• Version: 77.0.3865.90

Demo link

JSFiddle

Additional context

[tmorehouse]

This is strange. Must have some kind of trigger in Vue during reactive checks (getter triggering a setter/getter somewhere)

I wonder if downgrading to a lower version of Vue (say 2.6.1 or similar) has this effect...

[WillGoldstein]

Tried that here and get these errors:

Is there another version, perhaps more recent, that you would recommend?

[tmorehouse]

Not sure...

[WillGoldstein]

My fault, I was loading vue js after bootstrap vue in that fiddle. Trying vue 2.6.1 like you suggested has the same effect:
https://jsfiddle.net/azorvgjk/1/

For giggles I went back to vue 2.5.10 and it doesn't work in that version either :/. Same goes for vue 2.4.0.

[tmorehouse]

@WillGoldstein After a bit of digging, we've discovered one thing.

Whenever a prop changes on a component, even if it isn't directly (or indirectly) used during render, causes the component to re-render (since Vue doesn't track what causes a render function to update - any data or prop change will cause a render - unlike computed props which track what changes).

Therefor, whenever the filter prop changes, even when debounced, will cause the table component to re-render (although the filtering wont be applied until after the debounce).

What we will probably do (in release v2.1.0) is:

• add a debounce feature to <b-form-input> (and by nature <b-form-textarea>)
• add new prop lazy to <b-form-input>(and by nature <b-form-textarea>), which updates the v-model on change/blur (PR feat(b-form-input, b-form-textarea): add lazy modifier prop to update v-model on change/blur event #4169)
• deprecate the filter debounce feature of <b-table> in favour of the input debounce

This will decouple the filter criteria value change, optimizing the render updates

[WillGoldstein]

Bravo @tmorehouse , thanks for looking closer and planning a fix for a future release. Looking forward to implementing it - it’ll be a big boost in performance for us.

[tmorehouse]

@WillGoldstein As a workaround, you could implement your own debounce routine on an input that, once debounced, passes the filter criteria to b-table:

Using a watcher:

<template>
  <div>
    <b-form-input v-model="rawInput" type="search"></b-form-input>
    <b-table :items="items" :fields="fields" :filter="criteria"></b-table>
  </div>
</template>

<script>
export default {
  data() {
    return {
      rawInput: '',
      criteria: '',
      // ...
    }
  },
  created() {
    // Use a non-reactive property to prevent
    // unnecessary re-renders of your component
    this.$_timeout = null
  },
  beforeDestroy() {
    // Ensure that any pending timeout is cleared on destroy
    clearTimeout(this.$_timeout)
  },
  watch: {
    rawInput(newVal, oldVal) {
      clearTimeout(this.$_timeout)
      this.$_timeout = setTimeout(() => {
        this.criteria = newVal
      }, 150) // set this value to your preferred debounce timeout
    }
  }
}
</script>

Or using event on the input

<template>
  <div>
    <!-- update is the event that updates the v-model on b-form-input -->
    <b-form-input @update="handleFilter" type="search"></b-form-input>
    <b-table :items="items" :fields="fields" :filter="criteria"></b-table>
  </div>
</template>

<script>
export default {
  data() {
    return {
      criteria: '',
      // ...
    }
  },
  created() {
    // Use a non-reactive property to prevent
    // unnecessary re-renders of your component
    this.$_timeout = null
  },
  beforeDestroy() {
    // Ensure that any pending timeout is cleared on destroy
    clearTimeout(this.$_timeout)
  },
  methods: {
    handleFilter(val) {
      clearTimeout(this.$_timeout)
      this.$_timeout = setTimeout(() => {
        this.criteria = val
      }, 150) // set this value to your preferred debounce timeout
    }
  }
}
</script>

[WillGoldstein]

Thanks @tmorehouse . Unfortunately, I am having trouble getting those workarounds to work. My filter prop on my <b-table> has to hit a custom filter function, and that function has to access data properties, which brings us full circle back to the original issue. I don't believe that work around works.

I was able to confirm this by returning true right away in my custom filter function. This made the workaround behave just like the original filter-debounce prop. But, once I removed that return true and allowed the custom filter function to hit data properties, the workaround stopped working and behaved just like the original issue.

Do you have an idea/timeline on 2.1, or at least a fix for this bug?