fix(frontend): sort indicators reflect the effective sort, not just the explicit one

↗ view on GitHub · Amal · 2026-08-12 · 2c1b6214

WHY THIS MATTERS
DocTable's new defaultSort participated in row ordering
(sort ?? defaultSort) but the header indicators only read `sort`. In the
Library (defaultSort updated/desc) every column claimed "Default Order"
while rows were actually date-sorted, and choosing "Default Order" could
never restore insertion order because null falls straight back to the
default - the menu lied twice.

HOW IT WORKS
A single hoisted effectiveSort feeds ordering, header indicators, and the
folder-name comparator, so they cannot disagree again. Where a defaultSort
exists the reset option is labeled "Default (Updated)" - truthful about
what it restores - and surfaces the effective direction as checked.
Consumers without defaultSort are byte-identical (effectiveSort === sort).

Found by review of PR #309.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4PXCdenNH5Mqhm5Sre9Zs
Repository open-legal-products/mike
Author Amal <mamalanand3@gmail.com>
Authored
Committed
Parents cd6caeed
Stats 1 file changed , +31 , -14
Part of Refactor workflows into defaults, add-ons, and quick actions

Capture this commit into my fork

Download a Markdown prompt that tells Claude how to port this exact commit into your working tree. Run it via claude -p < capture-commit-2c1b6214.md from inside the repo you want the change in.

⬇ Download capture-commit-2c1b6214.md