Feature Request / Architectural limitation: Differentiating 'filter' data for Global vs Colum search
Feature Request / Architectural limitation: Differentiating 'filter' data for Global vs Colum search
FBDT2026
Posts: 1Questions: 0Answers: 0
Hi Allan and DataTables team,
I am building an advanced and highly granular search UI for a project, and I've hit a structural limitation regarding how orthogonal data is indexed for filtering.
The Use Case
I want to give users the ability to dynamically choose the data source for their searches via a UI toggle (e.g., a gear icon with radio buttons). The available modes for a cell are:
1. Visible Text only (the <td> content)
2. Hidden Data only (stored in a custom attribute like data-search-valeu)
3. Both (OR)
4. (only for global filters): use the settings for the individual column as the source
I need to provide this toggle for each specific column, but also a master toggle for the Global Search.
Crucially, these must be independent. For example: A cell displays "10 Jan 2026" but has a hidden attribute 2026-01-10. I want the Column Search to use the "Hidden Data" (for exact ISO matching), but simultaneously, I want the Global Search to use "Visible Text" (so if a user types "Jan", it finds the row).
The Technical Roadblock
Currently, I am using columnDefs.render to feed orthogonal data when type === 'filter'. However, DataTables creates a single, unified search index per cell.
Inside the render function, the meta object does not provide any context about who is requesting the filter data. I have no way of knowing if the orthogonal data is being built/queried for the Global Search input or for a specific Column Search input.
Because there is only one index, if my Global Search toggle forces the index to be populated with "Visible Text", the Column Search instantly breaks, because the "Hidden Data" it expects to query is no longer in the index. One setting is forced to overwrite the other.
It should be possible to set the date filter to specific values, but the global search to displayed text (and vice versa, of course), so that you can search for all dates between 2025-01-01 and 2026-12-31 while adding a second global filter such as “May” to retrieve the records for May from two consecutive years.
Why the alternative is not an option
I am aware that I could bypass the native orthogonal index entirely and use $.fn.dataTable.ext.search.push(...) to manually read the DOM attributes ($(node).attr(...)) on every keypress for both global and column searches.
However, this is a severe anti-pattern for this use case:
* Performance killer: It forces DOM reading in a loop for every row on every keystroke, which destroys performance on large datasets.
* Loss of Smart Search: Doing manual indexOf matching means losing DataTables' brilliant native "Smart Search" capabilities (multi-term matching, out-of-order words, etc.).
* Memory management: Pushing complex functions dynamically requires careful teardown to avoid memory leaks.
The Proposal
Is there a way, or could we introduce a feature, to separate the orthogonal filter data?
Thank you for your time and for the incredible library.
Replies
Interesting - thank you for posting this. So in summary, you want the global search to use both formats:
10 Jan 2026 2026-01-10, but the column search to use only the ISO format? (just as an example data point)?I think the way I'd approach that, as things stand, is to have the
filterorthogonal data return the combined formatted string, then use a custom function for the column search, and that function would use the underlying original data (which could go through its own formatting if you need at that point).Does that sound like it would do what you need?
I don't really want to decouple the global and column search more than it already is, adding a
filter-columndata type could cause backwards compatibility issues.If it were a toggle to change between one state and the other, an invalidation would do the job and just reread the data in a different format, but that doesn't sound like what you need - if I've understood correctly, you need it in both forms at the same time.
Allan