A simple way to specify a generic tree column

[telamonian]

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.

[telamonian]

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 as row_pivots) and their implementation will be removed
• Long term, the IRowIndex.treeFuncs field will be removed
  • treeFuncs 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)?

[telamonian]

Some simpler (but problematic) alternative proposals:

• expect optional .name, .collapse, etc properties on the existing row_indices array

• if row_indices is present, expect to find its name at column_indices[0] (ie column_indices.length should be data.length + 1 when row_indices is present)

  • this only covers the row_indices name issue, not the general tree API

[timkpaine]

@telamonian should we close this now that tree-finder is more mature?