Overview - Table

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Canceled
6353
6a8e0461 fix(table-core): guard Array.isArray before index access in range autoRemove fns filterFn_between, filterFn_betweenInclusive, and filterFn_inNumberRange all had: autoRemove: (val: any) => testFalsy(val) || (testFalsy(val[0]) && testFalsy(val[1])) When a scalar (non-array) value like `99` is passed, `val[0]` and `val[1]` are both `undefined`. testFalsy(undefined) === true, so the second branch evaluates to `(true && true)` === true and the filter is immediately removed — even though 99 is a perfectly valid, non-empty filter value. Root-cause: numeric columns default to the `inNumberRange` filter function (auto-selected in column_getAutoFilterFn). Calling `col.setColumnFilter(99)` hits this path and the filter silently vanishes (issue #5949). Fix: add `Array.isArray(val) &&` so the index checks only run when val is actually an array. The testFalsy(val) head still removes undefined/null/''. Closes #5949
by JSap0914
Canceled
6361
d5d357b8 fix(table-core): include sub-rows in flatRows when maxLeafRowFilterDepth truncates recursion When filterRowModelFromRoot skips recursing into sub-rows because the current depth >= maxLeafRowFilterDepth, the parent row's sub-rows are still accessible through row.subRows and remain visible in the table. However, these sub-rows were never added to newFilteredFlatRows, making flatRows an incomplete flat representation of the visible tree. This causes getFacetedUniqueValues() to return different counts before and after filtering when maxLeafRowFilterDepth is set: before filtering flatRows contains all rows at all depths (via preRowModel), but after filtering flatRows only contains passing top-level rows. Fix: add addSubRowsToFlatArrays helper that recursively pushes sub-rows (and their descendants) into flatRows and rowsById when a passing row has sub-rows that were skipped due to depth >= maxDepth. Fixes #5987
by JSap0914
Succeeded
beta
516ab678 fix(table-core): filterFn_between/betweenInclusive autoRemove never removes array filter values (#6332) fix(table-core): fix filterFn_between/betweenInclusive autoRemove never removing array filter values filterFn_between and filterFn_betweenInclusive had `autoRemove: (val: any) => !val`. Since any array is truthy in JavaScript, `!val` is always `false` for the `[min, max]` tuple these filters receive, meaning the filter is NEVER auto-removed — even when both endpoints are empty strings, null, or undefined. A user who clears both range inputs ends up with an active filter that passes all rows but can never be auto-removed from column filter state. Fix: align with the same pattern used by filterFn_inNumberRange: autoRemove: (val) => testFalsy(val) || (testFalsy(val[0]) && testFalsy(val[1])) This correctly removes the filter when both endpoints are falsy (undefined, null, or empty string) while preserving 0 as a valid endpoint value. Fixes: filterFns.between and filterFns.betweenInclusive auto-remove logic Co-authored-by: JSap0914 <JSap0914@users.noreply.github.com>
by JSap0914
Succeeded
6332
b4949eab fix(table-core): fix filterFn_between/betweenInclusive autoRemove never removing array filter values filterFn_between and filterFn_betweenInclusive had `autoRemove: (val: any) => !val`. Since any array is truthy in JavaScript, `!val` is always `false` for the `[min, max]` tuple these filters receive, meaning the filter is NEVER auto-removed — even when both endpoints are empty strings, null, or undefined. A user who clears both range inputs ends up with an active filter that passes all rows but can never be auto-removed from column filter state. Fix: align with the same pattern used by filterFn_inNumberRange: autoRemove: (val) => testFalsy(val) || (testFalsy(val[0]) && testFalsy(val[1])) This correctly removes the filter when both endpoints are falsy (undefined, null, or empty string) while preserving 0 as a valid endpoint value. Fixes: filterFns.between and filterFns.betweenInclusive auto-remove logic
by JSap0914