Skip columns based on an enum

[otopetrik]

Data which represent a relation are often displayed in multiple places, but often without a column representing one side of the relation.

Example:

#[derive(leptos_struct_table::TableRow, Clone)]
#[table(sortable, impl_vec_data_provider)]
struct RoadTripRow {
    pub driver: AppRoute,
    pub car: AppRoute,
    #[table(format(string = "[year]-[month]-[day]T[hour]:[minute]:[second]"))]
    pub trip_begin: Option<OffsetDateTime>,
    #[table(format(string = "[year]-[month]-[day]T[hour]:[minute]:[second]"))]
    pub trip_end: Option<OffsetDateTime>,
    ...
}

(assume that AppRoute type implements leptos_struct_table::CellValue to render a hyperlink)

• on the driver detail page, it is useful to display the table without driver column (all values are same, all link to the driver detail page itself).
• on the car detail page, it is useful to display the table without car column (all values are same, all link to the car detail page itself).
• on the list of road trips page, both driver and car columns are displayed.

Current solution is to duplicate the table as RoadTripRowFromDriver and RoadTripRowFromCar, and delete (or #[table(skip)]) one row in each copy.

It works, but maintenance is not ideal. With more relations in the system, it requires extra effort to keep all three table structures (for every relation) in sync,

It would be nice improvement, if something like the following were possible:

enum RoadTripRowMode {
    All,
    FromDriver,
    FromCar,
}

#[derive(leptos_struct_table::TableRow, Clone)]
#[table(sortable, impl_vec_data_provider)]
struct RoadTripRow {
   #[table(skip_if=RoadTripRowMode::FromDriver)]
    pub driver: AppRoute,
   #[table(skip_if=RoadTripRowMode::FromCar)]
    pub car: AppRoute,
    #[table(format(string = "[year]-[month]-[day]T[hour]:[minute]:[second]"))]
    pub trip_begin: Option<OffsetDateTime>,
    #[table(format(string = "[year]-[month]-[day]T[hour]:[minute]:[second]"))]
    pub trip_end: Option<OffsetDateTime>,
    ...
}

...

// on driver detail page
// <Table mode=RoadTripRowMode::FromDriver ... />
// on car detail page
// <Table mode=RoadTripRowMode::FromCar ... />
// on list of all road trips page
// <Table mode=RoadTripRowMode::All ... />

[kstep]

Something more generic can be used here, e.g. a signal or a callback function to decide which columns to show/hide. What do you think?

[maccesch]

I totally agree. I'd like to have an integrated solution with re-ordering columns.

Maybe have a

RwSignal<[ColumnConfig; <col_count>]>

struct ColumnConfig {
    order: usize,
    visible: bool,
}

What do you think?

[otopetrik]

The really generic solution would be for the library to generate an enum for the row structure (value for each field, except those marked #[table(skip)]).

E.g.

enum RoadTripRowColumn {
  Driver,
  Car,
  TripBegin,
  TripEnd
}

and then take signal (maybe something like <Table column_configuration=...) containing ordered collection describing table columns. Not sure about the type.

1. Vec

Using Vec<RoadTripRowColumn> would be enough to reorder/show/hide columns.
E.g. create_signal(vec![RoadTripRowColumn::TripBegin,RoadTripRowColumn::TripEnd, RoadTripRowColumn::Driver])
would render table in order: trip_begin, trip_end, driver (with car column not displayed at all).

It looks like a similar feature was already suggested in issue #13 using strings.
Using enum instead of string seems safer and should allow the compiler to catch typos.

2. Vec<(Enum, Struct)>

Using something like Vec<(RoadTripRowColumn, ColumnConfigurationOverride)>, where ColumnConfigurationOverride would be leptos-struct-table structure holding the same information as row structure field attributes, would allow additional functionality. ColumnConfigurationOverride would probably require most fields to be Option, with the default None value resulting in fallback to value obtained from structure field attributes.

additional functionality:

• changing format or cell renderers at runtime (e.g. switch between '10 minutes ago' vs '2025-01-01 12:00', switch whole column between thumbnail and full size images, or maybe whole table between ediable 'admin' mode and 'read-only-preview-as-user' mode).
• changing class, head_class,...
• changing title (e.g. display 'car' as 'Car' in the default table, but as e.g. 'Transport' when viewed from driver page), but that might clash with i18n

Using callback does not seem worth it.
Passing a vector in (with values from structure field attributes), and returning filtered/reodrered/modified vector, would
provide the callback with access to values from attributes, and the structure ColumnConfigurationOverride would not need to have Option fields, but it does not seem worth the complexity.

Signal of vector seems more composable (e.g. derive it from multiple signals from bool signals from checkboxes, or by concatenating two smaller vectors for configuring parts of the table,..).

(I have very limited knowledge of Rust macros, therefore no idea about the implementation difficulty or language-imposed limits for doing this)

[maccesch]

I did sth like that in an earlier iteration but for me that is too much magic and doesn't seem necessary. I'd like to keep it as lean as possible while still providing all the functionality.

You already can sort of switch renderers at runtime. In your custom renderer you can do whatever you want.

[ToxicMushroom]

Another benefit of a column enum as otopetrik described is being able to sort on them instead of the ambiguous usize, which changes when you add columns.

However I understand wanting to keep it simple, I agree that is easy to use at the moment :)

[maccesch]

Totally agree. I'm sure there are a bunch of benefits to using an enum. It's as always a tradeoff.

If someone wants to make a PR to make it configurable to choose between a usize and enum I'd be prepared to merge it.

[ToxicMushroom]

I'll give it a shot then tomorrow :)