[rh-table] Expandable pattern

[brianferry]

https://codepen.io/OhHeyBrian/pen/abrbLXK

Very basic demo that would add functionality to a table row where if you click the row it expands and shows additional content. Needs additional detail and work done to it but wanted to get some feedback on what you all thought of this as a pattern.

We were initially considering using patternfly elements pf-table component but given how different the markup was I went in and wanted to see how difficult it would be to add it through JavaScript.

[zeroedin]

If a parent row is expanded wouldn't we want the child content (expanded info) to represent that expanded relationship? I feel like just hiding and showing an additional row doesn't maintain why you'd want to "expand" the current row selection to begin with.

I definitely understand and respect the technical hurdles with trying to maintain the standard slotted html table though. I'm not sure in the current iteration of rh-table that this will be possible without modifying the slotted table. pf-table is creating that parent child relationship with the nested tables and has the added benefit of the subcomponents pf-tr, pf-td to help do slotting per row.

[zeroedin]

I see this is how material for angular has done it as well.

https://material.angular.io/components/table/examples#table-expandable-rows

I wonder about the general accessibility of this pattern. I don't feel the data in the table makes sense if it was expand out always if the table itself was just plain jane. I would think the rows column headers at that point lose their meaning? This is to me like using tables again for layout and not to represent the actual tabular relationship of the content within.

/cc @adamjohnson @hellogreg

[adamjohnson]

This is to me like using tables again for layout and not to represent the actual tabular relationship of the content within.

I agree with this to a point.

From an accessibility perspective, the treegrid pattern is probably the closest standardized accessible pattern to Brian's Codepen.

I have not used the treegrid pattern before, so some exploration is warranted to see if it would be appropriate for our use cases.

There is this important piece of information:

A treegrid widget presents a hierarchical data grid consisting of tabular information that is editable or interactive.

It's hard to say what they mean by "interactive". Does that mean an expandable table row? Maybe. The APG example uses an email inbox which has multiple nested levels.

I'd be curious to hear Greg's thoughts.

[hellogreg]

Big +1 to Steven on this:

I would think the rows column headers at that point lose their meaning?

The key question for me is what constitutes "additional content" in the OP.

If we're basically hiding rows/entries of tabular data (where the entries have the same structure, but one or more cell values may change), I think Adam had a great idea to investigate the treegrid (especially if multiple columns will be affected, like in the WAI treegrid example). I admit, I haven't built one, either.

But if we're just revealing content for existing entries, seems to me that a new row isn't appropriate. It's not a new data entry. We wouldn't put it as a new row in a spreadsheet.

Judging by the CodePen example at least, the initially-hidden info represents either:

• An extension of the text under the "Event" heading (if that whole cell should contain both the name and description).
• A whole new column of data (if "Event" really means "Event name," then this new column would be something like "Event description").

If it's the former, instead of adding any new rows, you could maybe consider just putting that new content in a disclosure widget in the relevant "Event" cell. (Or adding some other way to reveal the new info: making the "Event" cell value a link to another page, making that same text a button that pops up additional info on click, or something. Just spitballing.)

If the latter, then we're talking about hiding columns by default, and then letting them be expandable somehow.

I always get a little nervous about building tables that could wind up any more complicated than they need to be (and that includes the potential solutions I mentioned). I guess I'd want to see an example of the info we want to hide/show before stating anything conclusive.

[hellogreg]

Quick aside: When using the aria-expanded attribute, place it on the button that controls the section being shown/hidden, and not the section itself.

Aside to the aside: If you wind up using a <details> disclosure widget, you won't need aria-expanded at all, as it's baked into the <summary> element (albeit with some browser and screen reader inconsistencies).

[brianferry]

Sorry for the delay in the responses here

@zeroedin

Why do we want to expand the current row?

For us it's because the data that we have coming back can include many items that can have the same name but be functionally independent. From the frontend perspective, we're consolidating those items into one row so instead of hundreds of rows saying the same name but with different subdata we show them one overarching row with the general data displayed which we would then give more granularly when we expand the table row.

@hellogreg
What type of info do we want to display inside? Is it a new row or additional data?

We want to display an extension of the text in the row that is being extended not necessarily a new column of data. I like the suggestion of perhaps using a disclosure element to solve this. I'll add this suggestion to our jira board.

Thank you all so much!