Paginate card and receipts

[thedev132]

No description provided.

[Copilot]

Pull Request Overview

This PR implements pagination for card transactions and receipts by replacing ScrollView components with FlatList components and integrating the useTransactions hook to handle infinite scrolling.

Key Changes:

• Added pagination support to the useTransactions hook with a configurable prefix parameter
• Converted card and receipts pages from ScrollView to FlatList for better performance with large datasets
• Introduced infinite scroll functionality with loading indicators

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/lib/organization/useTransactions.ts	Enhanced hook to support pagination with configurable prefixes and added dedicated hook for missing receipt transactions
src/pages/cards/card.tsx	Refactored card page to use FlatList with pagination support and restructured rendering logic
src/pages/Receipts.tsx	Converted receipts page to use FlatList for better performance
src/pages/organization/index.tsx	Updated to pass "organizations" prefix to useTransactions hook
src/pages/RenameTransaction.tsx	Updated cache mutation call to include prefix parameter

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The renderItem function destructures an 'index' parameter from its argument but never uses it. Remove the unused 'index' parameter from the type annotation.

Suggested change

index: number;

[seer-by-sentry]

Bug: mutate() is called with a key generator function instead of a serialized key, preventing cache invalidation.
_{Severity: CRITICAL | Confidence: 1.00}

🔍 Detailed Analysis

The mutate() function is called with getKey(orgId, "organizations"), which returns a key generator function. However, mutate() interprets a function argument as a filter function. For useSWRInfinite keys, unstable_serialize must be used to correctly serialize the key generator. This mismatch prevents proper cache invalidation, leading to stale data persisting in the SWR cache after a transaction memo is renamed.

💡 Suggested Fix

Wrap the getKey() call with unstable_serialize before passing it to mutate() to ensure correct key serialization for useSWRInfinite.

🤖 Prompt for AI Agent

Fix this bug. In src/pages/RenameTransaction.tsx at line 60: The `mutate()` function is
called with `getKey(orgId, "organizations")`, which returns a key generator function.
However, `mutate()` interprets a function argument as a filter function. For
`useSWRInfinite` keys, `unstable_serialize` must be used to correctly serialize the key
generator. This mismatch prevents proper cache invalidation, leading to stale data
persisting in the SWR cache after a transaction memo is renamed.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[seer-by-sentry]

Bug: Transaction error message is not displayed because the list filter removes the "transactions" item when transactionError is true.
_{Severity: HIGH | Confidence: 1.00}

🔍 Detailed Analysis

When transactionsError is truthy, the listData filter at src/pages/cards/card.tsx:975 evaluates !transactionError && !transactionsLoading to false, causing the "transactions" item to be excluded. Consequently, the error rendering logic for transactionError within the renderItem function (lines 1523-1547) is never reached, preventing the display of transaction loading errors to the user.

💡 Suggested Fix

Modify the filter condition for "transactions" items to return !transactionsLoading; to ensure the item is not removed when transactionError is present.

🤖 Prompt for AI Agent

Fix this bug. In src/pages/cards/card.tsx at line 975: When `transactionsError` is
truthy, the `listData` filter at `src/pages/cards/card.tsx:975` evaluates
`!transactionError && !transactionsLoading` to `false`, causing the `"transactions"`
item to be excluded. Consequently, the error rendering logic for `transactionError`
within the `renderItem` function (lines 1523-1547) is never reached, preventing the
display of transaction loading errors to the user.

_{Did we get this right? 👍 / 👎 to inform future reviews.}