Fix experiment webview column header nesting

We need to fix up the column header nesting within the experiments webview. The current layout and styling is very basic and doesn’t work correctly when we have multiple levels of data within a group. Here is an example:

Notice that the header for params.yaml is split between the first and second level.

Here is the current design:

Please note that this issue has already been solved by the Studio team. Here is a screenshot of their UI:

Notice that params.yaml is only on the first level.

We need to research whether or not react-table is the correct solution for our needs and if we can add a custom hook to get the header to behave in the way that we want to. We also need to be aware that in the future we will want to be able to drag and drop the columns in order to reorder them.

It needs to be noted that there is another column data “client”. Which can be used to toggle the visibility of columns within the webview table. It can be seen in action here:

https://user-images.githubusercontent.com/37993418/126724948-90f2f8ab-8f31-44e7-abdf-60215c0f7797.mov

The data structure used to feed both the table and the tree view resides inside of extension/src/experiments/model/index.ts. The data is currently held inside a flat array but it is very likely that this will need to changed to be more performant and to enable the future requirement of dragging & dropping / reordering of columns by the user.

The purpose of this ticket is to research the approach that we need to take to move forwards in terms of our column data structure and choice of table library (and whether or not we should roll our own and how). We then need to work through a POC implementation.

[sroy3]

I think I’m on the right track. I’m adding a placeholder column above the deepest columns that haven’t reach the maximum depth. That’s inside their linkColumnStructurefunction that is deep inside how react-table process columns, but if they ignore the PR once it’s ready, I think it’ll be possible to parse the columns to add a similar behaviour before pushing the columns to react-table.

[sroy3]

I may be missing something, but the example you’ve linked seems to have all groups at a depth of 3, which doesn’t quite reflect the edge case of multiple different depths that we’re dealing with here. You’re right! Not only that, but the documentation is even more sparse than the one for react-table and like you said changing the plumbing or how everything works is probably not the best path to take.

I’ve looked into react-table’s code base and I think I might be able to add a fix in there. If this works, we’ll then see if we can reproduce it inside a hook or maybe even just open a PR to fix the library itself.