Support multiple column levels

[shwinnn]

Renders pandas MultiLevel column titles in the Table component when generated from a DataFrame.

As asked for in #507

[tcbegley]

It would be nice if the higher levels weren't repeated, see attached screenshot. You can achieve this using colSpan in the html.Th elements.

I had a quick look just now but I didn't see any obvious ways of extracting the span, so you might have to figure it out yourself from df.columns.to_list() or similar. I guess it would look something like at each level you count the number of repeated indexes, taking into account when there's a change either in the current level or the level above.

[shwinnn]

Sorted. This will also work for column titles even in a DataFrame without multiple title 'levels' if they are repeated and adjacent. I think that's a good thing but could add logic to untangle that case if you disagree.

[shwinnn]

Oh hang on - I didn't consider the case where the level above changes but the below level is the same. I'll think about that.

[tcbegley]

Yeah, that seems to be the one outstanding thing. I've checked that if a key appears multiple times non-contiguously then it's alright.

import dash
import dash_bootstrap_components as dbc
import numpy as np
import pandas as pd

header = [
    [
        "location",
        "location",
        "location",
        "location",
        "location2",
        "location2",
        "location2",
        "location3",
        "location3",
        "location",
        "location",
    ],
    ["S1", "S2", "S3", "S3", "S1", "S2", "S3", "S3", "S3", "S1", "S2"],
]
df = pd.DataFrame(np.random.randint(0, 10, size=(10, 11)), columns=header)


app = dash.Dash(external_stylesheets=[dbc.themes.BOOTSTRAP])

app.layout = dbc.Container(dbc.Table.from_dataframe(df), className="p-5",)

if __name__ == "__main__":
    app.run_server(debug=True)

One thing I did notice running this example is a lot of indexing past lexsort depth may impact performance warnings in the terminal. This can be resolved by sorting the column multiindex, but perhaps users want a particular ordering of columns which would be broken by doing this automatically

[shwinnn]

I definitely don't want to reorder the rows automatically. What do you think about just suppressing the warning (or allowing just the first instance through?)

[shwinnn]

Oh never mind! It can be avoided by just using .iloc[i,j] rather than .loc[i][col]

[shwinnn]

So that turned out to be far from trivial to do without having abominable for loops everywhere. I tested using the same file above, but changing the second "S1" to "S3". This should force a break even though both columns in that level have the title "S3" because the level above changes from "location" to "location2" at that point.

[shwinnn]

So it appears itertools.accumulate doesn't exist in Python 2.7. I will switch to using numpy.cumsum.

[shwinnn]

Okay, I've just written my own accumulator instead.

[tcbegley]

Sorry it took me a while to look at this, looks good to me, thanks for the contribution!

Looks like there's a few conflicts with master. Could you merge in the changes or rebase onto master? Once you've done that I'll squash and merge.

[shwinnn]

I didn't get any conflicts, but I've merged the changes (which seem to consist only of the colours PR I made last week).

[tcbegley]

Ah yeah, there might not have been conflicts in the sense of merge conflicts, but GitHub is very conservative about letting you merge changes if there are any newer commits on the target branch. Something like it will only do a fast-forward merge, not a three-way merge? Anyway, thanks for updating!