dioxus-tabular
Type-safe and composable table framework for Dioxus. Build reactive tabular UIs with declarative column definitions and multi-column sorting.
Overview
dioxus-tabular is a Dioxus-native framework for building structured, declarative, and strongly-typed table UIs.
Instead of configuring your table with dynamic descriptors or ad-hoc data models, you define columns as typed components.
Each column owns its own render logic, filter behavior, and sort comparator — and can hold local reactive state via Signal.
This approach may feel a little more verbose at first, but it unlocks:
- Composable, type-safe column definitions
- Declarative multi-column sorting
- Column reordering and visibility control
- Extensible abstractions (
Row,GetRowData,TableColumn) - Full Dioxus integration: built with
rsx!andSignalfrom the ground up
Design Philosophy
- Columns are first-class citizens: each is a self-contained logic unit.
- Columns are composable: they can be freely combined into tables.
- Columns are type-safe: If a column type does not fit to the row data type, the compiler will complain.
- Columns are self-contained: they can hold their own state, filtering logic, sorting logic, and rendering logic.
- All columns, data, and tables are reusable and swappable: All of them does not depend on each other, so you can mix and match them as you like.
Core Concepts
| Trait / Struct | Description |
|---|---|
Row |
Defines the unique key and identity of each row. |
GetRowData<T> |
Provides access to the data of the row by a specific type. |
TableColumn |
Describes how a single column renders, filters, and compares rows. |
Columns |
A composed collection of TableColumns, implemented for tuples. |
Features
Multi-Column Sorting
Tables support declarative multi-column sorting with priority control:
- Each column can define its own comparison logic via
TableColumn::compare() - Each column can request:
- sort direction (ascending or descending) or toggle the direction
- sort priority (primary or last)
- sort removal
- All sort requests are applied automatically when rendering rows
Row Filtering
Columns can implement custom filtering logic:
- Each column defines its own
TableColumn::filter()method - All filters from all columns are applied automatically when rendering rows
Column Ordering and Visibility
Control which columns are displayed and in what order:
- Hide/Show:
hide_column(),show_column()- Toggle column visibility - Reorder:
move_to(),swap_columns()- Change column positions - Navigate:
move_forward(),move_backward()- Move columns incrementally - Reset:
reset_column_order()- Restore default order and visibility
Access these methods through TableContextData or ColumnContext.
Example scenario
You could define the following types and implement those traits like the following example:
Rows:
UserimplementsRow,GetRowData<UserId>andGetRowData<UserName>AccessLogimplementsRow,GetRowData<AccessLogId>,GetRowData<Timestamp>andGetRowData<UserId>
Columns:
UserIdColumnimplementsTableColumn<T>for everyT where GetRowData<UserId>UserNameColumnimplementsTableColumn<T>for everyT where GetRowData<UserName>AccessLogIdColumnimplementsTableColumn<T>for everyT where GetRowData<AccessLogId>TimestampColumnimplementsTableColumn<T>for everyT where GetRowData<Timestamp>
And, you define a simple table component like the following:
and another one:
Now you can render many kinds of tables with different column combinations like the following:
let users: = ...;
let access_logs: = ...;
rsx!
Also, if you implement filtering and sorting logic in the columns, any tables have sorting and filtering features without any additional code to each table.
License
MIT or Apache 2.0 at your option.