The goal is to make the grid as dumb as possible about the tree actually works. DataProviderBase will keep track internally of what's been expanded and communicate this to the implemented data provider when it's time to update data.
API
This would add new methods to DataProviderBase:
toggleExpanded(item: ItemProperties)
expand(item: ItemProperties)
collapse(item: ItemProperties)
expandAll()
collapseAll()
Internally to data providers, a single object mapping item IDs to boolean values if expanded, will be passed when data is updated:
expanded: { [ itemId: string ]: boolean }
When expandAll is called, expanded will become an object that returns true for every property
When collapseAll is called, expanded will be reset
Data provider implementations will add new properties to ItemProperties:
expandedLevel?: number
isExpanded?: boolean
canExpand?: boolean
Column would get a new property to indicate which cell to draw the arrow in:
renderExpando?: boolean
Grid Implementation
column.renderExpando would add new vdom showing an arrow if item.canExpand is true
item.isExpanded would rotate this arrow to show it as being "expanded"
item.expandedLevel would increase the indentation at the start of this cell
We should make sure we allow for easy indentation configuration without having to pass a specific pixel number into a property.
Duplicate Items
One of the things that has plagued dgrid 1 is when the same item appears in multiple branches of the tree. Right now, the grid has no hierarchy between rows which means that Maquette will complain about duplicate keys.
Indentation level cannot be used as a way of making keys unique as two items with the same key may be at the same indentation level. If we did something like force the parent ID to be passed in ItemProperties, we could wrap each branch in a node with what would be a unique ID but that would really add a level of complexity to on demand scrolling, and possibly other areas of code that we'll be adding. We should try our hardest to avoid wrapping rows.
I don't have a good solution for this at the moment and it's not pressing for alpha but something to keep in mind.
I like the API that was created for web-editor, where the control of expansion is wholly inverted. We should consider porting the TreeView from web-editor for this.
Enhancement
The goal is to make the grid as dumb as possible about the tree actually works.
DataProviderBase
will keep track internally of what's been expanded and communicate this to the implemented data provider when it's time to update data.API
This would add new methods to
DataProviderBase
:toggleExpanded(item: ItemProperties)
expand(item: ItemProperties)
collapse(item: ItemProperties)
expandAll()
collapseAll()
Internally to data providers, a single object mapping item IDs to boolean values if expanded, will be passed when data is updated:
expanded: { [ itemId: string ]: boolean }
expandAll
is called, expanded will become an object that returns true for every propertycollapseAll
is called, expanded will be resetData provider implementations will add new properties to
ItemProperties
:expandedLevel?: number
isExpanded?: boolean
canExpand?: boolean
Column
would get a new property to indicate which cell to draw the arrow in:renderExpando?: boolean
Grid Implementation
column.renderExpando
would add new vdom showing an arrow ifitem.canExpand
is trueitem.isExpanded
would rotate this arrow to show it as being "expanded"item.expandedLevel
would increase the indentation at the start of this cellWe should make sure we allow for easy indentation configuration without having to pass a specific pixel number into a property.
Duplicate Items
One of the things that has plagued dgrid 1 is when the same item appears in multiple branches of the tree. Right now, the grid has no hierarchy between rows which means that Maquette will complain about duplicate keys.
Indentation level cannot be used as a way of making keys unique as two items with the same key may be at the same indentation level. If we did something like force the parent ID to be passed in
ItemProperties
, we could wrap each branch in a node with what would be a unique ID but that would really add a level of complexity to on demand scrolling, and possibly other areas of code that we'll be adding. We should try our hardest to avoid wrapping rows.I don't have a good solution for this at the moment and it's not pressing for alpha but something to keep in mind.