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

[abayomicornelius]

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.

[latiblack]

Hey Abayomi, I clearly understand this very well, it is an orphaned implementation that needs a maintainer decision before cleanup. I’ll investigate both transaction-history trees, check git history and existing tests, and recommend whether components/TransactionHistory or components/history/TransactionTable should be canonical. Once direction is set, I’ll either delete the dead code and verify no remaining imports, or wire the chosen component into pages/History.tsx with network-aware Horizon calls and a properly typed TransactionItem. I’ll run the test suite and npm run build.

[grantfox-oss]

🦊 GrantFox — @latiblack has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #20)
2. Your PR will be reviewed by the StellarSend maintainers

Good luck! Track your progress on GrantFox.

[latiblack]

Investigated both trees as stated in my application and these are the findings:

• src/components/TransactionHistory/ (index/TransactionItem/Pagination/EmptyState) + src/hooks/useTransactionHistory.ts are not imported anywhere in src/pages/ or src/App.tsx — confirmed via grep. The live History page (src/pages/History.tsx) renders components/history/TransactionTable backed by useTransactions/useRecentTransactions.
• useTransactionHistory.ts hits https://horizon.stellar.org directly (hardcoded mainnet, no network-awareness), and TransactionItem uses an untyped Record<string,unknown> prop with a hardcoded XLM label — so it would break on non-payment ops (create_account, path_payment, account_merge).
• No test file imports the orphaned tree, so removing it won't affect the existing suite.

My Recommendation: delete the orphaned TransactionHistory tree + useTransactionHistory.ts. history/TransactionTable is clearly canonical (it's what History.tsx actually renders); wiring the orphan in would be a regression given its hardcoded-network and typing bugs. I also noticed stray committed files under src/.commits/ — likely accidental, flagging separately.

so based on this, should I procced to delete, or do you intend TransactionHistory to eventually replace TransactionTable? I'll proceed once you confirm direction.

[latiblack]

Please check this out @abayomicornelius and confirm direction.