Allow specifying default sort columns for tables

[jchorl]

#1666 upgrades the tablesorter plugin. The new version of tablesorter allows you to specify a default sort order via data- html attribute.

This PR extends that to thread a defaultsort option through per-table configs and actually do the default sorting.

Here is an example config:

custom_plot_config:
  general_stats_table:
    defaultsort:
      - [2,1]
      - [3,0]

This specifies to sort:

• First by column 2, desc
• Then by column 3, asc

I am soliciting feedback on the interface. I see two options here:

1. As-is. User specifies the column indexes, and the sort order. This is nice because it ~exactly conforms to the tablesorter spec - it's a 1:1 passthrough. However, this means re-ordering the columns or adding/removing could change the defaultsort behaviour.
2. User specifies column names, e.g.

   custom_plot_config:
     general_stats_table:
       defaultsort:
         - "foo-col": asc
         - "bar-col": desc

   the interface here is much more user-friendly. But by the time we go to assemble the table in table.py, it seems we only have the header IDs, and not necessarily the names (they're buried in pre-assembled html content). Therefore I think the implementation of this approach would be quite messy and difficult to maintain.

The first seemed much simpler to me.

Once we get consensus, happy to update the docs!

• This comment contains a description of changes (with reason)
• CHANGELOG.md has been updated

[UPD by Vlad on 21 Nov 23]: final implementation below. Col IDs and titles are accepted here.

custom_plot_config:
  general_stats_table:
    defaultsort:
      - column: "Mean Insert Length"
        direction: asc
      - column: "Starting Amount (ng)"
  quast_table:
    defaultsort:
      - column: "Largest contig"

[ewels]

Therefore I think the implementation of this approach would be quite messy and difficult to maintain.

Difficult to maintain, how come? To me this seems much easier to maintain for users. Columns could come and go quite easily with MultiQC versions / new tool support / tweaks in analysis etc. Column IDs should be fairly stable.

I think I use column IDs for some other stuff already. I have a feeling that they're printed in the configuration modal in the report front end (where you show and hide columns).

[jchorl]

Therefore I think the implementation of this approach would be quite messy and difficult to maintain.

Difficult to maintain, how come? To me this seems much easier to maintain for users. Columns could come and go quite easily with MultiQC versions / new tool support / tweaks in analysis etc. Column IDs should be fairly stable.

I think I use column IDs for some other stuff already. I have a feeling that they're printed in the configuration modal in the report front end (where you show and hide columns).

Okay, yeah, good call. I got this working with column names. Here's a screenshot:

I think it's cleaner, and I updated docs. Let me know what you think!

[vladsavelyev]

Awesome stuff. Referencing columns by titles is user-friendly, but I'd allow referencing by IDs as well, like it's done by default in other configuration sections like table_columns_visible.

I'll try to do that, and will merge with master as well :)

[ewels]

Yup, IDs is better than names I think. Just position index that I wasn't keen on.

[vladsavelyev]

Minor changes - I also allowed to omit the "order" as it defaults to "desc" anyway, and added a docs example of sorting general stats. Looks great!