feat: Enable multi-column sorting in anywidget mode

[shuoweil]

This update brings multi-column sorting capabilities to the interactive DataFrame display (anywidget mode), allowing for more powerful data exploration directly within our notebook.

What's New:

• Multi-Column Sorting: You can now sort your data by multiple columns simultaneously to organize it exactly how you need (e.g., sort by "State" first, then by "Year").
• Simple Controls: Just hold the Shift key while clicking additional column headers to add them to your sort order.
• Clear Visuals: Sorting indicators (▲/▼) are now displayed for all active sort columns, not just the most recent one.

How to use:

1. Click a column header to set the primary sort.
2. Hold Shift and click another column header to add it as a secondary sort.
3. Continue clicking to toggle each column between Ascending, Descending, and Unsorted states.

Verified at here: screen/BxN5ZX3QTG6TEU8

Fixes #<459835971> 🦕

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[sycai]

I suspect that this data structure allows content that make little sense in practice. For example:

sort_columns: ["my_col", "my_col"] # Same column appears twice
sort_ascending: [True, False]

Does it make sense to merge these two fields into a dictionary (ordered map), which maps the column name to whether it's ascending?

[shuoweil]

Thanks for the suggestion! I’ve refactored the two fields into a single sort_context traitlet to ensure atomic updates and maintain a consistent data state.

Regarding the concern about practical validity: the frontend logic is designed to ensure the list remains sane. When a user clicks a column header, we verify if the column is orderable and handle the list logic so that the same column cannot be inserted multiple times (it instead cycles through states or is removed).

While the original design was safe within these UI constraints, I agree that merging them is a cleaner architectural choice. I chose a List of Dictionaries (e.g., {'column': 'col1', 'ascending': True}]) instead of a Map for a few reasons:

• Order Precedence: In multi-column sorting, the order of columns matters. A List explicitly guarantees that sort priority (primary, secondary, etc.) is preserved during synchronization, whereas JSON dictionary keys are technically unordered.
• Extensibility: This structure is much more flexible. It allows us to add additional per-column sort parameters in the future (like nulls_first or na_position) without breaking the schema.
• Validation: It ensures that every column entry is always bundled with its corresponding direction, removing any risk of length mismatch.

The result is verified at here: screen/BxN5ZX3QTG6TEU8 (the description box is updated accordingly)