feat: introduce FilterGroup model for recursive table filters#9119
feat: introduce FilterGroup model for recursive table filters#9119kirangadhave merged 12 commits intomainfrom
FilterGroup model for recursive table filters#9119Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
b240e1d to
6702bf9
Compare
Bundle ReportChanges will increase total bundle size by 699 bytes (0.0%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: marimo-esmAssets Changed:
Files in
Files in
|
…d dtype validation
b5dea19 to
923720e
Compare
FilterGroup model for recursive table filters
There was a problem hiding this comment.
Pull request overview
This PR introduces a recursive filter model (FilterGroup / FilterCondition) to represent complex filter trees (AND/OR composition, negation, nesting), adds between and is_empty operators, and updates backend + frontend plumbing and tests to use the new structure.
Changes:
- Replace the flat
list[Condition]filter representation withFilterGroup/FilterConditionacross backend and frontend. - Add new filter operators (
between,is_empty) plus backend dtype↔operator validation for table filtering. - Update/extend backend and frontend test suites to cover the new filter model and operators.
Reviewed changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
marimo/_plugins/ui/_impl/dataframes/transforms/types.py |
Introduces RangeValue, FilterCondition, FilterGroup, dtype↔operator validation, and updates FilterRowsTransform.where to use FilterGroup. |
marimo/_plugins/ui/_impl/dataframes/transforms/handlers.py |
Implements recursive evaluation of FilterGroup (AND/OR + negation) and supports new operators in execution logic. |
marimo/_plugins/ui/_impl/table.py |
Updates table search args to accept FilterGroup and adds recursive validation/filtering of conditions by column existence + dtype/operator compatibility. |
marimo/_plugins/ui/_impl/dataframes/transforms/print_code.py |
Updates codegen inputs to FilterCondition/FilterGroup (but currently lacks full support for nested groups/negation/new operators). |
frontend/src/components/data-table/filters.ts |
Converts TanStack column filters into FilterGroup payloads for RPC. |
frontend/src/plugins/impl/DataTablePlugin.tsx |
Sends FilterGroup filters to the backend search API and updates zod request schema accordingly. |
frontend/src/plugins/impl/data-frames/schema.ts |
Adds FilterGroupSchema / FilterConditionSchema and transforms filter-rows UI inputs into a FilterGroup. |
frontend/src/plugins/impl/data-frames/utils/operators.ts |
Adds frontend operator schemas for between and is_empty. |
frontend/src/plugins/impl/data-frames/DataFramePlugin.tsx |
Updates plugin request schema to accept FilterGroup. |
tests/_plugins/ui/_impl/test_table.py |
Migrates table tests to pass FilterGroup rather than a list of conditions. |
tests/_plugins/ui/_impl/dataframes/test_transforms.py |
Updates transform parsing tests to use the group-based filter structure. |
tests/_plugins/ui/_impl/dataframes/test_print_code.py |
Updates hypothesis strategies/usages to build filter transforms with FilterGroup. |
tests/_plugins/ui/_impl/dataframes/test_handlers.py |
Migrates handler tests and adds extensive coverage for between, is_empty, nesting, OR, and negation. |
tests/_plugins/ui/_impl/dataframes/test_filter_model.py |
New unit tests for filter model normalization/hashability and dtype/operator validation. |
frontend/src/components/data-table/__tests__/filters.test.ts |
New tests for frontend filter→condition/group conversion and schema validation. |
for more information, see https://pre-commit.ci
Introduces a recursive filter model (
FilterGroup,FilterCondition) that can represent arbitrarily complex filter trees with AND/OR composition, negation, and nested groups. This replaces the flatlist[Condition]model.Note
The UI behavior will remain unchanged, we will have a list of filters which we AND together. The richer model is to support future work with AI/LLM generated filters, maybe a query language or an poweruser UI, and programatic filtering.
Changes
ConditiontoFilterConditionwithtypediscriminatorFilterGroupwith recursivechildren,operator (and/or), andnegativebetweenandis_emptyoperator to simplify than model it with comparision operatorsdtype <-> operatorvalidation on the backendmatch...caseinstead of chainingif..elif...elseFilterGroupTests
filterToFilterCondition,filterToFilterGroup, schema validationmake fe-checkpasses