Reimagine column handling
Nukesor opened this issue · comments
The current column handling is rather convenient, as columns get populated as rows and cells are added to the table.
However, this logic is rather implicit. There's no way to remove or add columns half-way through a table creation process.
To fix this
- column creation should be made explicit
- or it should be possible to make column creation explicit
I'm actually in favor of the second approach, since the goal of comfy-table is to be minimalistic and convenient to use.
Explicit column handling is more of an edge-case and the 90% use case is covered by implicit column creation.
However, it could be very tricky to design the API around an optionally explicit column handling, since such APIs tend to get confusing quite quickly.
This ticket is mostly for discussion on how such an API would look like.
I gave this a lot of thought and here's what I came up with.
Current Problem
The current implementation doesn't allow:
- Explicit addition of columns. Columns are always implicitely generated via rows.
- Removal of rows. This isn't allowed as there's no explicit control over columns and Column removal isn't supported.
- Columns to be swapped in position.
Possible Solution
Since this is about rethinking how the API would work and since this change will be breaking anyway, let's use this opportunity and do it properly.
My proposal for a new API design would look like this.
Column improvements
Accessing columns is currently annoying and error prone.
One needs to know the index of the column, which isn't ergonomic at all.
My proposal would be to move more logic into the column, which is why we need to make it more accessible.
- The
Column
struct will gain aname
in addition to its index. - The header will move from to the Column. This gives us more control over the header.
-> Headers are removed from theTable
.
->Column
will get[set_]header
functions. Table
will get a[set_]show_headers
function to en/disable displaying of column headers.Table
will get aget_column_by_name()
getter, which may return columns by their identifier.
Adding columns
- There'll be a
table.add_column(name: &str) -> Result<&mut Column>
and atable.add_columns(columns: Vec<String>) -> HashMap<String, &mut Column>
function. - There'll still be no way to add actual
Column
instances to the table.
Having a&mut Column
returned should make things easier though.
Removing columns
I found no good way of actually removing columns.
The problem with column removal is, that it needs to implicitely remove the respective cells of all current rows as well.
Without that, we wouldn't know which cells to display or not.
As the whole idea of this request is to remove implicit logic, I decided to forbid removal of columns.
Instead of removing columns, it should be made more convenient to hide
them, which is basically the same as a temporary "soft" removal.
Hiding columns
Currently, the functionality to hide a column is implemented as a Constraint
, which is a bit dirty.
It's not necessarily a constraint and having it as a constraint toggling the column in a program annoying, since the old constraint needs to be restored as soon as the column is made visible again.
- Add a
hidden
field to the Column in addition to respectivehide(bool)
/hidden()
getter/setter functions. - Remove the
ColumnConstraint::Hidden
variant.
Error handling
Previously, comfy-table was able to do things in an "optimistic" manner.
It was just given some strings and from there on it tried to display things to the best of its abilities.
With the trend to giving developers more power, we also have to introduce error handling.
- Add a
ComfyError
class, depending on the needed complexity introducethiserror
. - All setters that might fail due to missing names/duplicate identifiers need to return
Result<T, ComfyError>
. - There should be appropriately named error variants based on the type of error, e.g.
DuplicateColumn
.
All functions need to document which errors might be returned.
Removing rows/swapping columns
Two requested features
- Remove rows
- Swap columns
With the current builder design, these things won't be implemented, as this will only lead to confusion.
It would allow to this:
- Add some rows
- Swap some column positions
- Add some new rows in the original layout
- The columns of the new rows are now in the wrong order.
There're two solutions to this problem:
- Make rows named as well.
- We'll no longer use
Vec
s and onlyHashMap
s instead.
- Actually use an builder pattern.
- Use a
TableBuilder
in which one may specify columns, rows and their content. - call
builder.build()
, which returns aTable
. - That
Table
now only allows styling related actions, content may no longer be added/removed etc.
I'm no fan of either solution.
- No. 1 Makes the whole library harder to use for a very small userbase.
- No. 2 doesn't really solve the problem, as people also want to add content to the table after they've already built it once.
To be honest, I'm inclined to tell people that they shall just rebuild the whole table if they want complex interactions.
Comfy-table is designed to be a minimalistic table builder library and shouldn't be used as an interactive table renderer.
-> Until there's a good design proposal that doesn't make the library less usable/unusable for the vast majority of its users, these features won't be added.
Who builds this?
I am very happy with the current state of comfy-table and I don't need any of said functionality myself.
Even though I designed and specified the new archtiecture, I won't reimplement it.
Also, if you find any design flaws, please point them out and let's try find a better solution.
As usual, I'll give any MRs thorough reviews as long as they're well documented and properly tested (via actual tests).
So, if anyone needs this and has some spare time at their hand, I would be happy to see this merged into comfy-table :).