src/components/TransactionHistory/* is an entirely orphaned, unused component tree duplicating components/history/TransactionTable #20

Problem

src/components/TransactionHistory/ contains a full, tested mini-feature: index.tsx (the TransactionHistory component), TransactionItem.tsx, Pagination.tsx, and EmptyState.tsx, backed by its own hook src/hooks/useTransactionHistory.ts. None of it is imported anywhere in src/pages/:

$ grep -rln "TransactionHistory" src/pages src/App.tsx
(no matches)

The actual History page (src/pages/History.tsx) instead renders TransactionTable from src/components/history/TransactionTable (note: different directory, history lowercase vs TransactionHistory), backed by useRecentTransactions/useTransactions from src/hooks/useTransactions.ts, which talks to fetchTransactionsFromHorizon in src/lib/api.ts.

Meanwhile, useTransactionHistory.ts independently hits Horizon directly:

const r = await fetch('https://horizon.stellar.org/accounts/' + address + '/payments?order=desc&limit=20')

— always the mainnet Horizon URL, with no network-awareness at all (see the related useStellarAccount hardcoded-network issue in this batch for the same pattern), and TransactionItem.tsx renders it with an untyped prop and hardcoded asset label:

interface Props { tx: Record<string, unknown>; myAddress: string }
export function TransactionItem({ tx, myAddress }: Props) {
  const isSent = tx.from === myAddress
  return (
    ...
    <p>{isSent ? '-' : '+'}{String(tx.amount)} XLM</p>
  )
}

This assumes every Horizon /payments record is a simple native-asset payment op (tx.from, tx.to, tx.amount exist on payment ops, but not on create_account, path_payment_*, or account_merge ops that the same endpoint also returns), and unconditionally labels every amount XLM regardless of asset_code/asset_type.

Why it matters

• This is dead weight: a full parallel implementation (component tree + hook + tests) that a future contributor could easily believe is "the" transaction history feature (it's the most naturally-named one — TransactionHistory vs history/TransactionTable), waste time fixing bugs in, and never see any effect in the running app.
• It has its own real bugs baked in (hardcoded mainnet-only Horizon URL ignoring the user's selected network; the untyped Record<string, unknown> prop that would break on non-payment operation types; hardcoded XLM label) that will never be caught by manual QA of the actual app, only by someone reading the source or running its unit tests in isolation — a false sense of security from tests that exercise code nothing depends on.
• Bundle size: qrcode-style unused-but-bundled concerns aside, this is meaningful dead code (4 components + 1 hook + associated tests) shipping in the bundle for a feature no route reaches.

Reproduction

• grep -rln "TransactionHistory" src/pages src/App.tsx src/components/history — no results outside the TransactionHistory directory itself.
• Attempt to reach this component via the running app's History page/route — it's unreachable; TransactionTable renders instead.

Suggested fix (flagging as spike — needs a decision, not just deletion)

Two legitimate directions, and it's not obvious from the code alone which is intended:

1. Delete the orphaned tree (components/TransactionHistory/*, hooks/useTransactionHistory.ts, and their tests) if components/history/TransactionTable + useTransactions is the intended, actively-maintained implementation.
2. If TransactionHistory was meant to replace history/TransactionTable (e.g. a simpler/older implementation being incrementally rolled out), wire it into pages/History.tsx instead — but note it would need the network-awareness and typed-transaction fixes described above before that would be an improvement rather than a regression.

Given there's no code comment, TODO, or commit message in this repo explaining the intended relationship between the two, this needs a maintainer decision on which implementation is canonical before doing the mechanical cleanup.

Testing strategy

• Once a direction is chosen: if deleting, confirm no remaining imports (grep -rn "TransactionHistory\|useTransactionHistory" src) and that pages/History.tsx's existing tests still pass unaffected.
• If wiring in instead, add the network-awareness fix (mirroring whatever fix is chosen for useStellarAccount) and a typed Transaction-shaped prop for TransactionItem, with tests covering a non-payment operation type (e.g. create_account) rendering gracefully instead of showing undefined.

Related issues in this batch

Same hardcoded-mainnet-Horizon-URL pattern as the useStellarAccount issue in this batch; same "second, unwired, buggier implementation" shape as the ContactBook/AddContact.tsx issue in this batch.