Feedback on Tree Grid in Data Grid

[jess-watson]

Our team is looking to implement a UI where users can select properties in order to enrich an event payload. These properties can be nested a few levels deep, so I started exploring the use of a tree grid. I know we've previously discussed the use of a tree grid for the tracking plan table and that tree grids aren't currently in Paste.

Do you have any feedback or guidance on how the data grid and tree grid is being used here?

We can avoid using a tree grid if we format the properties in dot notation, but it gets repetitive:

I've kept the pattern similar to another pattern we've implemented in Segment, but if you'd like to see more explorations, you can find them here. Thanks!

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Sorry, I don't know how to help with that.

I did do a search though, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Editable Datagrid, Part two (updated: 10/25/2023, similarity score: 91%)
• Horizontal scrolling in tables - Answer (updated: 06/07/2023, similarity score: 86%)
• Tabs and nested Data Grids to represent event versions within the Data Grid component - Answer (updated: 10/25/2023, similarity score: 85%)

[SiTaggart]

Hi @jess-watson

Treegrids have come up a couple of times, most recently we touch on it a little in this Segment related discussion where @nkrantz shares a couple of links and some guidance.

The TL;DR; is that a Treegrid builds upon a grid, or Datagrid as we call it. It's essentially identical. All it does is allow a row in the grid, be expanded to show more rows of the same type. Each row in the grid must share the same columns and column headers. A tree grid is a hierarchical representation of data of the same type.

As an observation, I would say that what you have is neither a grid nor a tree grid, because it doesn't actually contain tabular data. Your option 1 might be closest to a tree grid in that every row shares the same columns, but the second column is probably not that useful.

Your Option 2 is probably closest to what you need, but even that should just a be Tree (or this example). It doesn't need all the boxes and lines.

Rather than a single tree, you might just need two or more trees of different types of data, separating them with a heading or label/legend to describe each tree type. From your example, that would be "Profile traits" and I guess "Order Completed"...

We don't have a tree either yet, unfortunately. The closest we can get is along the lines of what is outlines by @nkrantz in the other thread I linked too, where a developer will need to lay some things over the top of a datagrid to get close to it. It won't be fully accessible as it will be missing the full keyboard interaction.

It's unfortunate too, because even the most popular accessible component libraries, that we very often utilize to speed up our delivery of components, all don't have tree like structures. Probably because they are just so hard to build correctly.

Depending on the number of times in your list and the depth of hierarchy, the only feasible thing might be to nest checkbox groups, inside disclosures. At a certain depth that will just fail though.

That's a fairly rambling explanation of the state of play. Hopefully, sometime in 2024 we'll be able to delivery those tree components, but until then, these less than ideal options are your best bet.