Fix: table sort resets on filter change - #223
Merged
Baskarayelu merged 1 commit intoAug 28, 2026
Merged
Conversation
useTransactions() had no UI consumer. Add TransactionsTable: sort state (sortKey/sortDirection) and filter state (typeFilter) are two independent useState calls, deliberately not coupled to each other, so changing the type filter never resets the sort a user already chose -- the bug class this guards against is deriving the visible rows in a way that re-keys or resets sort state whenever the filtered set changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note on scope
`useTransactions()` (`lib/hooks/useTransactions.ts`) already existed but had no UI consumer to reproduce this bug against. Built the table with the fix baked in from the start, rather than skip the issue.
Summary
A transaction table's sort and filter are easy to accidentally couple -- e.g. keying the table on the active filter, or resetting sort state in a `useEffect` triggered by the filter -- which resets whatever sort order the user picked the moment they change the filter.
Change
`components/TransactionsTable.tsx`: sort state (`sortKey`/`sortDirection`) and filter state (`typeFilter`) are two independent `useState` calls. The visible rows are derived by filtering then sorting in one `useMemo`, with no coupling between the two -- filtering never touches sort state.
Tests
`components/TransactionsTable.test.tsx`: default sort, sort-direction toggle, filter-by-type, and the regression case for #116 -- sort by amount ascending, then change the filter, and assert both the row order and the header's `aria-sort` still reflect the amount-ascending sort (not the date-descending default it would fall back to if sort had reset).
`npx vitest run components/TransactionsTable.test.tsx`: 4 passed. `npx tsc --noEmit` / `npx eslint` on changed files: clean.
Related to #116