🤔 Architecture Question: Using React Table for non-table filtering?
I'm building an analytics page with multiple charts and graphs, and I need global filters that apply to all visualizations (date ranges, status filters, custom fields, etc.). I'm inclined to use Tanstack Table, but would like your input.
Here's the context:
- Already using @tanstack/react-table extensively for our main data table
- Have a sophisticated filtering system with URL state sync, custom field support, and reusable filter components
- The analytics page won't actually display a table - just charts/graphs
- The dataset is very small (in 99% of cases <1000 rows, none more than 20k rows) and already available on the client (cached using Tanstack Query)
- Each chart would be passed the filtered rows (table.getRowModel().rows) and aggregate the data client side
The question: Is it architecturally sound to use useReactTable purely for its filtering capabilities on a non-table page?
Pros I see:
Reuse existing filter infrastructure
Consistent UX across table and insights pages
Already have all the filter components built
Complex filter state management is already solved
Instant chart updates when filter changes as all the data already exists client side, and the filtering is done client side.
Potential concerns:
Feels conceptually weird to use "table" for non-table
Redundant "state machinery" using client resources?
Passing raw row data to charts for client side aggregation? I can't see why this would be an issue.
Am i missing something? Has anyone done something similar? Would you go with this approach or build a separate filtering system from scratch?
Thank you for your input!
Here's the context:
- Already using @tanstack/react-table extensively for our main data table
- Have a sophisticated filtering system with URL state sync, custom field support, and reusable filter components
- The analytics page won't actually display a table - just charts/graphs
- The dataset is very small (in 99% of cases <1000 rows, none more than 20k rows) and already available on the client (cached using Tanstack Query)
- Each chart would be passed the filtered rows (table.getRowModel().rows) and aggregate the data client side
The question: Is it architecturally sound to use useReactTable purely for its filtering capabilities on a non-table page?
Pros I see:
Reuse existing filter infrastructure Consistent UX across table and insights pages Already have all the filter components built Complex filter state management is already solved Instant chart updates when filter changes as all the data already exists client side, and the filtering is done client side. Potential concerns:
Feels conceptually weird to use "table" for non-tableRedundant "state machinery" using client resources?Passing raw row data to charts for client side aggregation? I can't see why this would be an issue. Am i missing something? Has anyone done something similar? Would you go with this approach or build a separate filtering system from scratch?
Thank you for your input!
