Integration of the FilterService into all components that have a filtration option

[lnsandn01]

Issue

Hi there, I am trying to implement custom filtration for all entities we have, which are iterated over in different PrimeNG components.
What I exactly would like to do is just being able to search for entities that haver sub or super texts in them by just entering their normal characters. Like one entity is called "H₂O", and it should be searchable via "H2O" as well.
But I think the need for different custom string replacements or other ways of filtration will come up in the future and being able to easily overwrite the filtration in PrimeNG components would be desirable in general.

I see three possible ways in achieving that:

• Overwriting the template part of the filter and use a self written component
  • downside: all template parts need to be overwritten manually, and some filter templates might differ in different PrimeNG components, so several custom filter components are needed to be implemented
• Adding a new property to all entities that has the field that should be searchable transformed in the way that I would like
  • downside: all entities need to have this property added. Could be done in a wrapper class with the added field, but even then i would need to map the right field that needs transformation in all entities; and it makes consistent data manipulation difficult (bc. of this extra field)
• Overwriting or replacing the underlying filtration of PrimeNG components in some easier way
  • downside: only implemented for treetables via the FiltrationService, otherwise you could maybe write wrappers for all PrimeNG components with the filtration somehow replaced, or would need to fork PrimeNG and change the filtration functionality internally of course

Suggested solution

Integrating the FilterService with its way of registering a new filter, and the column filter way of the choosing the filtration method in the template.
It is so easy to do without messing up the code base, but is as of now limited to the treetable and column filters.

I don't know if there is internal intrest in integration at Primefaces, but I would at least like put my request out there for discussion.
And maybe someone has a better way of doing what i want and could provide with a different solution as well, thank you very much for your interest.

I also saw a similar post p-tree table integration with filter service, but it is less precise about what the issue is, more specific in scope and might have a different solution from this one, so I created a new one but of course would be happy if both get merged.

[everton-dgn]

For TreeTable, Table and column filters this already works, FilterService.register is public:

const subMap: Record<string, string> = {
  '₀':'0','₁':'1','₂':'2','₃':'3','₄':'4','₅':'5','₆':'6','₇':'7','₈':'8','₉':'9',
  '⁰':'0','¹':'1','²':'2','³':'3','⁴':'4','⁵':'5','⁶':'6','⁷':'7','⁸':'8','⁹':'9',
};
const normalise = (s: string) => s.replace(/[₀-₉⁰-⁹]/g, c => subMap[c] ?? c);

constructor(private filterService: FilterService) {
  this.filterService.register('normalisedContains', (value, filter, locale) => {
    if (filter == null || String(filter).trim() === '') return true;
    if (value == null) return false;
    return normalise(String(value)).toLocaleLowerCase(locale)
      .includes(normalise(String(filter)).toLocaleLowerCase(locale));
  });
}

Then on the table: <p-table [filters]="{ name: [{ value: null, matchMode: 'normalisedContains' }] }">, or column filter matchMode="normalisedContains". The raw lookup is in Table.executeLocalFilter (table.ts line 2319-2325), where filterConstraint = filterService.filters[filterMatchMode], so any registered rule is accepted as a match mode.

Select and MultiSelect are the problem. Their filterMatchMode is typed as a string-literal union ('contains' | 'startsWith' | ...), see select.ts line 642 and multiselect.ts line 717, so even though both inject(FilterService) and call filterService.filter(...) internally, you can't pass a custom rule without an as any cast. That's the bit that'd need a real PR, widen the type to string, or add a separate customMatchMode input.

AutoComplete doesn't use FilterService at all, search() just emits completeMethod and you filter on your side, so drop the normalisation into your own completeMethod.

For H2O specifically, applying normalise on both sides covers it without touching your entity shape. Feature-wise, widening the Select/MultiSelect match-mode type feels like the minimal win; probably worth opening an issue for that.

[lnsandn01]

Thank you very much for your elaborate answer Éverton (ᵔ⩊ᵔ).
I implemented it in a similar way for p-tables, I like your string replace via a record much more though nice.

I could not replicate your issue with the single/multi-selects, my filter works with them, even when I use your code, no as any required. Or at which exact position do you need to cast?

I also noticed that this way of global table filtration does not work at all when you combine it with lazy loading, added an issue for that primefaces/primeng#19539

Thank you very much for getting the discussion started (＾▽＾).

[everton-dgn]

Glad it helped.

On the Select/MultiSelect typing: the cast is only needed at template-binding time (not at runtime), and only when Angular's strict template checking is on. In the current sources (v21.1.6, published 2026-04-13; same blobs on master for the files below), both components still declare filterMatchMode as a literal union rather than string:

• packages/primeng/src/select/select.ts:642
• packages/primeng/src/multiselect/multiselect.ts:717

Both identical:

@Input() filterMatchMode:
  'contains' | 'startsWith' | 'endsWith' | 'equals' | 'notEquals'
  | 'in' | 'lt' | 'lte' | 'gt' | 'gte' = 'contains';

Internally they both call filterService.filter(..., this.filterMatchMode, ...) (select.ts:1006, multiselect.ts:1256), and FilterService.filter itself takes filterMatchMode: string (filterservice.ts), so TS doesn't complain at the internal call site. The mismatch only shows up at the template binding against the literal union, which is why you only see it in strict-templates builds. The v21 default tsconfig from ng new emits strictTemplates: true explicitly in angularCompilerOptions.

If the error isn't showing up on your side, could you check whether strictTemplates (or strictInputTypes) is enabled in your angularCompilerOptions? That's probably where the difference is. Two other things that can hide it:

1. Using <ng-template pTemplate="filter"> and pre-filtering the list yourself with this.filterService.filter(list, fields, value, 'normalisedContains', locale), then binding the already-filtered array to [options]. In that path filterMatchMode is never touched, so nothing conflicts with the literal union. This is different from the official custom-filter showcase (apps/showcase/doc/select/customfilter-doc.ts), which goes the other way: it keeps the built-in filter algorithm and only swaps the input UI via options.filter(event) / options.reset().
2. Testing against <p-listbox>, whose filterMatchMode is typed as ... | string (listbox.ts:503) and accepts custom modes with no cast. That inconsistency between Select/MultiSelect and Listbox is part of why widening the type would help.

Two cleaner ways to avoid as any on strict-templates builds:

• [filterMatchMode]="$any('normalisedContains')". $any is Angular's built-in template global for this exact case (it's listed as a supported global in the Expression Syntax guide), and it reads as an intentional bypass rather than a generic cast.
• The pTemplate="filter" + pre-filter approach above, which sidesteps the typed Input entirely.

Widening the Input to ... | (string & {}) on the library side would preserve autocomplete on the known literals while accepting registered custom modes. Probably worth a PR.

On the lazy-loading bit (#19539), that one is structural, not a config issue. _filter() in table.ts short-circuits:

// table.ts:2215
if (this.lazy) {
    this.onLazyLoad.emit(this.createLazyLoadMetadata());
} else {
    // local filtering, the only branch that hits
    // filterService.filters[matchMode] (executeLocalFilter, line 2323)
}

So with [lazy]="true":

• this.value is never mutated; executeLocalFilter and the filterService.filters[...] lookup are skipped entirely.
• onLazyLoad fires with createLazyLoadMetadata() (table.ts:2340), which passes filters: this.filters straight through, so your custom matchMode string is preserved in the payload.
• Only the string "normalisedContains" reaches the backend. The predicate you registered on FilterService is a client-side function and isn't serialised.

Three options, depending on where your data lives:

• Mirror the mode server-side. Treat the custom match mode as a contract: when your handler sees event.filters[field].matchMode === 'normalisedContains', apply the equivalent normalization on the server. For the H₂O case specifically, plain unaccent on Postgres won't help. Its default rules file doesn't touch subscript or superscript digits (U+2080 to U+2089 and U+00B2, U+00B3, U+2070, U+2074 to U+2079 are all absent), because subscripts are Unicode compatibility characters, not diacritics. A reliable path is a pre-computed searchable column normalised with Unicode NFKD ('H₂O'.normalize('NFKD') === 'H2O') and indexed; another is a custom unaccent rules file.
• Normalise on the client before sending. In onLazyLoad, run your normalise function over event.globalFilter and per-field filter values and send them as a plain contains query. No custom match mode crosses the wire, the backend stays generic.
• Post-filter client-side after the lazy fetch. Works for small pages but breaks totalRecords and pagination accuracy, since the server has no idea which rows you're about to discard. Fine as a stopgap, not a long-term answer.

I'd keep the issue open. At minimum a docs note ("registered custom match modes aren't executed in lazy mode; implement the equivalent server-side or pre-normalise on the client"), and ideally the match-mode name being surfaced explicitly in the lazy event payload so the server-integration path is less ad-hoc.