Request new features or modifications

Post by Robert Hirst »

The Grid component has been a great time-saver, and almost everything I've wanted to achieve has been possible.

The main limitation currently I'm encountering relates to filtering.

Specifically, that there are only a few different filtering presets, and these presets are unable to apply multiple filter operators at once.

This limits the ability to narrow down to fine ranges of values on number and date fields, and I also have user requests to implement other operators such as Starts With or Not Containing on text column filtering.

You see see this in effect by viewing the examples for filtering at

  1. Click the Filter on the Age Column, then enter < 40.

  2. Click the Filter again (without clearing the < filter) and enter > 20.

  3. Click the Filter again, and observe that the < filter has been deleted without user interaction.

The main focus of this feature request is for the ability to define and register new filter types, in a similar way to custom columns, however within this new system, it would also be useful to store each operator value separately.

A custom filter definition might look something like this (very simplified):

export class ExcludeFilter extends WidgetFilter {
  static get type() {
    return 'excludeFilter';

  get popupWidgets() {
        type        : 'text',
        clearable   : true,
        label       : 'Contains',
        operator    : 'Contains'
    }, {
        type        : 'text',
        clearable   : true,
        label       : 'Does Not Contain',
        operator    : 'NotContains'
get menuItems() { [{ text : 'Contains', icon : 'b-icon-filter-equal', name : 'filterContains', operator : 'Contains' }, { text : 'Does Not Contain', icon : 'b-icon-filter-not-equal', name : 'filterNotContains', operator : 'NotContains' } } }

And then be registered:


Using non-default filters/operators such as those in the example will usually require a custom sorter param, or custom store implementation, so such a system should be optional to configure, and the current default filter types should still be available.

The example filter type above demonstrates how the UI customisation could work, however in tandem with this, I'd also like to see a "filter per operator" type capability added, allowing a separate value to be stored simultaneously for each operator. Perhaps a property specifying the operator types would also be required for this.

I appreciate this is a great deal of work, and would likely require reworking the current filter system and separating the current filter types from the Filter and FilterBar plugins, however I believe this would greatly increase the power and capability of the product in regards to filtering, and provide further empowerment to users in terms of extension and configuration.

Please let me know if I can provide further clarification, and thank you for your amazing products.

Post by alex.l »

Hi Robert,

Thank you for your post! It sounds reasonable to us, here is a feature request:
We will extend Filter feature with this behaviour.
Btw, our StoreFilter mixin does support multi filters now:

All best,

All the best,

Post Reply