Custom operators

[noxify]

Hey,

currently we have a hard list of operators based on the column definition.

E.g. using .text() supports currently only "contains" and "does not conains" as operator.
I have seen, we could extend the types and the code to support other operators.

What do you think about a new method operators() for the createColumnConfigHelper?

I would assume, this is an optional method and

• if not defined, the default operators are used
• if defined, it will override the default operators

Example:

const dtf = createColumnConfigHelper()

  return [
    dtf.text().id("id").displayName("ID").operators(["equals", "notEquals"]).build(),
    dtf.text().id("id").displayName("ID").build(), 
  ] as const

[linear[bot]]

UI-146 [Feature] Support custom operators

[kianbazza]

This is a great idea! We'll need a bit more complexity, since we have the following interface for a filter operator:

export type FilterOperatorTarget = 'single' | 'multiple'

export type FilterOperatorDetailsBase<
  OperatorValue,
  T extends ColumnDataType,
> = {
  /* The i18n key for the operator. */
  key: string
  /* The operator value. Usually the string representation of the operator. */
  value: OperatorValue
  /* How much data the operator applies to. */
  target: FilterOperatorTarget
  /* The plural form of the operator, if applicable. */
  singularOf?: FilterOperators[T]
  /* The singular form of the operator, if applicable. */
  pluralOf?: FilterOperators[T]
  /* All related operators. Normally, all the operators which share the same target. */
  relativeOf: FilterOperators[T] | Array<FilterOperators[T]>
  /* Whether the operator is negated. */
  isNegated: boolean
  /* If the operator is not negated, this provides the negated equivalent. */
  negation?: FilterOperators[T]
  /* If the operator is negated, this provides the positive equivalent. */
  negationOf?: FilterOperators[T]
}

We also have to consider internationalization - we keep the display names for these operators in JSON files for each locale. Before we had i18n support, we simply had a displayName property on the above interface.

Perhaps we could bring this back as a fallback to use, when we can't find the key for an operator in the chosen locale. Then, we could just pass in the displayName directly when defining the custom operators.

Another obstacle is how we'll handle the filtering logic.

Right now, we have the filter functions (filterFns) defined here: https://github.com/bazzalabs/ui/blob/canary/packages/filters/src/lib/filter-fns.ts

We've hard-coded the operators, so it doesn't have built-in extensibility for user-defined operators. Perhaps we add a new property to our operator definition - a filter callback we can use? Basically a sub-filterFn?

{
  value: 'startsWith',
  displayName: 'starts with',
  target: 'single',
  fn: (input: string, filterValue: FilterModel<'text'>) => return input.startsWith(filterValue[0].toLowerCase().trim())
  /* ... */
}

A bit "all over the place", but do let me know what you think!

[doluk]

sounds like a reasonable plan for the implementation! Would love to see that

[d-stoll]

An alternative could be allowing to limit pre-defined operators in the column config builder.

Use case for this would be server side filtering where you know you can't support specific operators in the server such as "does not contain" or "does not start with".