A simple way to specify a generic tree column
telamonian opened this issue · 3 comments
I've been messing around with the tree functionality in regular-table. The existing tree support is based on row_pivots
, which is cumbersome for specifying a generic tree whose complete structure you don't necessarily know in advance. I think(?) there may also be at least some trees that you can't specify in terms of row pivots.
So far my best idea is that if a row can be expanded, the user's data model should add a /
to the end of its final path element, and also supply expand
and collapse
functions (as per _on_toggle
).
I'm working on a branch right now to implement the above, but am absolutely open to more clever suggestions.
After implementing a functional sparse tree as part of #19, it is now much clearer to me what is needed in a generic tree API. Here's my proposal for an API that is both reasonably clean and straightforward to implement:
Currently, row_indices
is an array of row path arrays. Instead, it should be an object that implements IRowIndex
(specified below using typescript interface notation):
interface IRowIndex {
values: string[][];
name?: string;
treeFuncs?: ITreeFuncs;
}
interface ITreeFuncs {
collapse: (rix: number) => void;
expand: (rix: number) => void;
is_leaf: (rix: number) => boolean;
set_depth?: (rix: number) => void;
}
where name
is the optional name for any rendered row_indices
column, and values
is equivalent to the current row_indices
array.
Notes:
- The above is inherently a sparse tree API, but should work well for the needs of dense trees as well
- Once the
IRowIndex
API is in place, all other related variables (such asrow_pivots
) and their implementation will be removed - Long term, the
IRowIndex.treeFuncs
field will be removedtreeFuncs
can be deprecated once formatting has been completely refactored into the data model
@texodus Does this seem reasonable to you? Is there anything missing here that would be critical to the dense tree case (eg a perspective grid with row_pivots
set)?
Some simpler (but problematic) alternative proposals:
-
expect optional
.name
,.collapse
, etc properties on the existingrow_indices
array -
if
row_indices
is present, expect to find its name atcolumn_indices[0]
(iecolumn_indices.length
should bedata.length + 1
whenrow_indices
is present)- this only covers the
row_indices
name issue, not the general tree API
- this only covers the
@telamonian should we close this now that tree-finder
is more mature?