Apply value sort to Send flow

[piyalbasu]

What problem does your feature solve?

Follow-up feedback on #2227 (sort balances by USD value) from Emir Ayral:

1. XLM is currently sorted by USD amount like any other token. For a Stellar wallet, XLM is the native asset and should always be the first token in the list regardless of value.
2. The Send flow's token picker is still sorted alphabetically — it didn't get the value-sort change applied in #2227.

What would you like to see?

- Token / balance list: sort by USD value, but always pin XLM to the top.

• Send flow token picker: same ordering as the balance list (sort by USD value, XLM pinned to top).

What alternatives are there?

• Keep XLM in value-sorted position (current behavior) — rejected by feedback.
• Sort Send picker independently — inconsistent UX.

Context

Slack thread: https://stellarfoundation.slack.com/archives/C03347FNAHK/p1779982000509779

[JakeUrban]

Updating description to reflect decision not to pin XLM to the top. We will proceed with using value sorting on the send view though.

[JakeUrban]

Blocked by #2764

[JakeUrban]

📝 Proposal Draft (Round 1/5)

Proposal: Apply value sort to Send flow token picker

Problem

The Account view sorts token balances by descending USD value (via sortBalancesByValue in popup/helpers/balance.ts), but the Send flow's token picker (SendDestinationAsset component) still renders tokens in the order returned by the API — effectively unsorted or alphabetical. This inconsistency was flagged in feedback on #2227.

Solution

Sort the balances by USD value in SendDestinationAsset before passing them to TokenList, using the existing sortBalancesByValue helper.

Why not use useStableSortedBalances? The stable-sort hook exists specifically for the Account view, which stays open indefinitely (especially in sidebar mode) and re-fetches prices periodically — re-sorting on every price refresh would shuffle rows mid-view. The Send flow's token picker is a transient subview: it mounts fresh each time the user taps "choose asset", fetches data once (useGetDestAssetData with useCache: true), and unmounts when a selection is made. There's no mid-view refresh to cause jarring re-sorts, so sortBalancesByValue applied directly to the fetched data is the correct, simpler approach.

Changes

File: extension/src/popup/components/send/SendDestinationAsset/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. Before passing balances.balances to <TokenList>, sort them:

   const sortedTokens = sortBalancesByValue(balances.balances, tokenPrices);

3. Pass sortedTokens to <TokenList tokens={sortedTokens} ...> instead of balances.balances.

That's a 3-line change (1 import addition, 1 variable, 1 prop update). The tokenPrices object is already available in scope at line 105.

Testing

• Existing unit tests for sortBalancesByValue cover the sorting logic itself.
• No new component-level test is needed — the change is a simple data transformation applied before render, not new conditional logic.
• Manual verification: open Send → choose asset → confirm tokens appear sorted by descending USD value (matching Account view order).

What this does NOT change

• XLM pinning is not applied (per updated issue description — XLM will be sorted by value like everything else).
• The Swap flow's token picker (different component) is not affected.
• The stable-sort behavior on the Account view is unchanged.

---

*Submitting to adversarial critic for *
review

[JakeUrban]

📝 Proposal Draft (Round 2/5)

Proposal: Apply value sort to Send and Swap flow token pickers

Problem

The Account view sorts token balances by descending USD value (via sortBalancesByValue in popup/helpers/balance.ts). The Send flow's token picker (SendDestinationAsset) and the Swap flow's token picker (SwapAsset) both render tokens in sortBalances order from popup/helpers/account.ts — which places XLM first, LP shares last, and everything else in insertion order from the API response. This is not value-sorted and produces an inconsistent experience versus the Account view.

Solution

Sort the balances by USD value in both SendDestinationAsset and SwapAsset before passing them to TokenList, using the existing sortBalancesByValue helper.

Why not use useStableSortedBalances? The stable-sort hook exists for the Account view, which stays open indefinitely and re-fetches prices periodically — re-sorting on every refresh would shuffle rows mid-view. Both the Send and Swap token pickers are transient subviews: they mount fresh each time the user opens them, fetch data once (with caching), and unmount on selection. There's no mid-view refresh to cause jarring re-sorts, so direct sortBalancesByValue is the correct, simpler approach.

Changes

File: extension/src/popup/components/send/SendDestinationAsset/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. Sort tokens before rendering:

   const sortedTokens = sortBalancesByValue(balances.balances, tokenPrices);

3. Pass sortedTokens to <TokenList tokens={sortedTokens} ...> instead of balances.balances.

File: extension/src/popup/components/swap/SwapAsset/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. Sort filtered balances before rendering:

   const sortedBalances = sortBalancesByValue(balances, tokenPrices);

3. Pass sortedBalances to <TokenList tokens={sortedBalances} ...> instead of balances.

Note: tokenPrices is already in scope in both components (line 105 in SendDestinationAsset, line 94 in SwapAsset).

Testing

• Add unit tests for SendDestinationAsset verifying that TokenList receives balances in value-sorted order.
• Existing unit tests for sortBalancesByValue cover the sorting logic itself.

What this does NOT change

• XLM pinning is not applied (per updated issue description — XLM sorted by value like everything else).
• The stable-sort behavior on the Account view is unchanged.
• The baseline sortBalances in useGetBalances remains (provides the tie-breaking insertion order for assets with no price data).

---

*Submitting to adversarial critic for *
review

[JakeUrban]

📝 Proposal Draft (Round 3/5)

Proposal: Apply value sort to token pickers via TokenList

Problem

The Account view sorts token balances by descending USD value (via sortBalancesByValue in popup/helpers/balance.ts). The Send flow's token picker (SendDestinationAsset) and the Swap flow's token picker (SwapAsset) both render tokens in sortBalances order — XLM first, LP shares last, everything else in API insertion order. This is not value-sorted and is inconsistent with the Account view.

Solution

Centralize the value-sort inside TokenList itself. Since TokenList is the shared rendering component for both pickers, and it already receives tokenPrices as a prop, it is the natural place to own the ordering policy. This eliminates the class of bug where a new caller of TokenList forgets to sort.

Changes

File: extension/src/popup/components/InternalTransaction/TokenList/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. At the top of the component body, sort the incoming tokens before rendering:

   const sortedTokens = sortBalancesByValue(tokens, tokenPrices);

3. Replace tokens with sortedTokens in the render body (the .filter().filter().map() chain starting at line ~52).

This is a single change point — both SendDestinationAsset and SwapAsset (the only two callers) automatically get value-sorted rendering with no modifications needed.

Testing

• Add a unit test for TokenList verifying that when tokenPrices are provided, tokens render in descending value order.
• Add a unit test verifying that when tokenPrices is empty ({}), the original order is preserved (the sortBalancesByValue no-op behavior).
• Existing unit tests for sortBalancesByValue cover the sorting logic itself.

What this does NOT change

• XLM pinning is not applied (per updated issue description).
• The stable-sort behavior on the Account view is unchanged (it doesn't use TokenList).
• The baseline sortBalances in useGetBalances remains (provides insertion order for assets with no price data, which sortBalancesByValue preserves as tie-breaking).
• The Swap flow's search-filter behavior is unaffected — filtering happens before TokenList receives the data, and sorting the filtered result is correct.

---

*Submitting to adversarial critic for *
review

[JakeUrban]

🔍 Critic Response (Round 1/5)

Full critique (click to expand)

The core change is feasible: sortBalancesByValue exists and is correct (popup/helpers/balance.ts:235), tokenPrices is already in scope in SendDestinationAsset (index.tsx:104-106), and TokenList renders in caller-supplied order (TokenList/index.tsx:52-127). Also, not using useStableSortedBalances is justified: Account polls every 30s, Send does not (useGetAccountData.tsx:205-261 vs SendDestinationAsset/index.tsx:54-60).

Required changes:

1. Fix the problem statement: Send is not using raw API order. useGetBalances already applies sortBalances (helpers/hooks/useGetBalances.tsx:33-52), so today's order is "XLM first / LP last / otherwise baseline order," not raw or alphabetical.
2. Revisit scope structurally. SwapAsset uses the same TokenList and also passes unsorted balances (components/swap/SwapAsset/index.tsx:93-130). Either include Swap now, or explicitly justify why this shared-picker inconsistency is acceptable.
3. Add one integration-level test for Send picker ordering. Existing helper tests only prove the sorter, not that SendDestinationAsset actually uses it.

Verdict: REVISE

1. Fix problem statement: current order is sortBalances (XLM first/LP last), not raw API order.
2. Include SwapAsset in scope (same TokenList, same unsorted issue).
3. Add integration-level test for Send picker ordering.

[JakeUrban]

🔍 Critic Response (Round 2/5)

Full critique (click to expand)

Mostly sound. Verified:

• sortBalancesByValue exists and does a stable descending USD-value sort, with no-op behavior when prices are missing (extension/src/popup/helpers/balance.ts:235-263).
• sortBalances is the current baseline order: XLM first, LP last, others in API/insertion order (extension/src/popup/helpers/account.ts:36-58).
• Account view already uses value sort via useStableSortedBalances (extension/src/popup/views/Account/index.tsx:122-128,291-299).
• SendDestinationAsset and SwapAsset currently pass unsorted balances straight to TokenList.
• tokenPrices is in scope in both.
• TokenList is only used in those two components.
• SwapAsset's filteredBalances is just search-filtered local state; sorting after filtering is fine.

Required changes:

1. Don't duplicate the ordering policy in two screens. Centralize it in TokenList or a shared picker-specific helper/hook, since TokenList is only used by these two pickers today. Otherwise the same bug class can recur with the next caller.
2. Add tests for both pickers, not just Send. SwapAsset has its own filteredBalances path and the >2 character search threshold, so cover unfiltered order and filtered order after search. Testing only SendDestinationAsset leaves half the change unverified.

Verdict: REVISE

1. Centralize ordering policy in TokenList itself (not duplicated in callers).
2. Add tests for both pickers, not just Send.

[JakeUrban]

🔍 Critic Response (Round 3/5)

Full critique (click to expand)

Verified: TokenList already takes tokenPrices, filters LP shares/hidden assets in its render chain, and is only called from SendDestinationAsset and SwapAsset. sortBalancesByValue preserves input order when prices are empty and uses stable tie-breaking.

Required changes:

1. Don't centralize in TokenList; use a shared picker-specific helper/hook instead. TokenList is a render/filter component; Account uses different "freeze order" semantics. Hiding value-sort inside the generic renderer makes future consumers implicitly opinionated.
2. Fix testing plan: there are no existing direct unit tests for sortBalancesByValue. Add direct tests for the helper and/or picker-order tests covering unpriced, zero-price, malformed price, and tie preservation.
3. Update the search/filter claim: Swap filtering only happens for search terms > 2 chars, not universally "before TokenList receives the data." Cover visible subset ordering and hidden/LP exclusion in tests.

Verdict: REVISE

1. Centralize in picker helper/hook rather than TokenList renderer.
2. Add direct unit tests for sortBalancesByValue covering edge cases.
3. Clarify Swap search/filter behavior in proposal and test plan.

[JakeUrban]

📝 Proposal Draft (Round 4/5)

Proposal: Apply value sort to token pickers via TokenList

Problem

The Account view sorts token balances by descending USD value (via sortBalancesByValue in popup/helpers/balance.ts). The Send flow's token picker (SendDestinationAsset) and the Swap flow's token picker (SwapAsset) both render tokens in sortBalances order — XLM first, LP shares last, everything else in API insertion order. This is not value-sorted and is inconsistent with the Account view.

Solution

Centralize the value-sort inside TokenList itself. TokenList is exclusively a picker component — it is only used by SendDestinationAsset and SwapAsset, never by the Account view (which has its own rendering path via AccountAssets + useStableSortedBalances). Since TokenList already receives tokenPrices as a prop and is the single shared picker renderer, it is the natural place to own the picker ordering policy.

Why TokenList and not a shared hook? Putting the sort in a hook or helper that callers must remember to invoke is the same pattern that produced this bug — the sort existed (sortBalancesByValue), but nobody called it in the picker paths. Placing it inside TokenList makes correct ordering structural: every picker gets it automatically, and no future caller can accidentally skip it. The Account view is unaffected because it uses a completely separate rendering path (AccountAssets component with useStableSortedBalances).

Changes

File: extension/src/popup/components/InternalTransaction/TokenList/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. At the top of the component body, sort the incoming tokens before rendering:

   const sortedTokens = sortBalancesByValue(tokens, tokenPrices);

3. Replace tokens with sortedTokens in the render body (the .filter().filter().map() chain starting at line ~52).

This is a single change point — both callers automatically get value-sorted rendering with zero modifications.

Testing

New tests for TokenList:

• Tokens render in descending USD value order when tokenPrices has entries.
• Original order is preserved when tokenPrices is empty {} (no-op behavior).
• Hidden assets and LP shares remain excluded regardless of sort order.

New direct tests for sortBalancesByValue (currently only tested indirectly via Account tests):

• Descending USD value sort for priced assets.
• Unpriced assets sort after priced ones, preserving relative input order.
• Zero-price and malformed/empty price strings treated as unpriced.
• Tie-breaking preserves input order (stable sort).

Edge Cases

• Swap search filtering: In SwapAsset, filtering only applies for search terms > 2 characters (useSwapFromData.tsx:107-127). When no search is active, the full balance list reaches TokenList; when search is active, a filtered subset reaches it. In both cases, sortBalancesByValue applied inside TokenList produces the correct descending-value order for whatever subset it receives.
• Empty prices: sortBalancesByValue is a no-op when prices is empty or null — tokens keep their existing sortBalances order (XLM first, LP last).

What this does NOT change

• XLM pinning is not applied (per updated issue description).
• The stable-sort behavior on the Account view is unchanged (different rendering path entirely).
• The baseline sortBalances in useGetBalances remains (provides tie-breaking insertion order for assets without price data).

---

*Submitting to adversarial critic for *
review

[JakeUrban]

🔍 Critic Response (Round 4/5)

Full critique (click to expand)

Mostly sound: TokenList is only used by the send/swap pickers, and Account uses a separate path with useStableSortedBalances. Sorting in TokenList is feasible and appropriately scoped.

Required changes:

1. Fix testing section: sortBalancesByValue is already directly tested in extension/src/popup/helpers/__tests__/balance.test.js:104 — don't describe it as indirect-only or propose redundant tests.
2. Fix zero-price semantics: "0" is treated as priced (value = 0), not unpriced (popup/helpers/balance.ts:231-233).
3. Correct the referenced paths: components live under popup/components/..., not popup/views/....

Verdict: REVISE

1. Fix testing section: sortBalancesByValue already has direct tests.
2. Fix zero-price semantics: "0" is priced (value=0), not unpriced.
3. Minor path corrections.

[JakeUrban]

✅ Converged Proposal (Round 4/5)

Proposal: Apply value sort to token pickers via TokenList

Problem

The Account view sorts token balances by descending USD value (via sortBalancesByValue in popup/helpers/balance.ts). The Send flow's token picker (SendDestinationAsset) and the Swap flow's token picker (SwapAsset) both render tokens in sortBalances order — XLM first, LP shares last, everything else in API insertion order. This is not value-sorted and is inconsistent with the Account view.

Solution

Centralize the value-sort inside TokenList itself. TokenList is exclusively a picker component — it is only used by SendDestinationAsset (popup/components/send/SendDestinationAsset/index.tsx) and SwapAsset (popup/components/swap/SwapAsset/index.tsx), never by the Account view (which has its own rendering path via AccountAssets + useStableSortedBalances). Since TokenList already receives tokenPrices as a prop and is the single shared picker renderer, it is the natural place to own the picker ordering policy.

Why TokenList and not a shared hook? Putting the sort in a hook or helper that callers must remember to invoke is the same pattern that produced this bug — the sort existed (sortBalancesByValue), but nobody called it in the picker paths. Placing it inside TokenList makes correct ordering structural: every picker gets it automatically, and no future caller can accidentally skip it. The Account view is unaffected because it uses a completely separate rendering path (AccountAssets component with useStableSortedBalances).

Changes

File: extension/src/popup/components/InternalTransaction/TokenList/index.tsx

1. Import sortBalancesByValue from popup/helpers/balance.
2. At the top of the component body, sort the incoming tokens before rendering:

   const sortedTokens = sortBalancesByValue(tokens, tokenPrices);

3. Replace tokens with sortedTokens in the render body (the .filter().filter().map() chain).

This is a single change point — both callers automatically get value-sorted rendering with zero modifications.

Testing

New tests for TokenList:

• Tokens render in descending USD value order when tokenPrices has entries.
• Original order is preserved when tokenPrices is empty {} (no-op behavior).
• Hidden assets and LP shares remain excluded regardless of sort order.

Note: sortBalancesByValue already has direct unit tests in popup/helpers/__tests__/balance.test.js covering its sorting logic, edge cases, and tie-breaking. No additional helper-level tests are needed.

Edge Cases

• Swap search filtering: In SwapAsset, filtering only applies for search terms > 2 characters (useSwapFromData.tsx:107-127). When no search is active, the full balance list reaches TokenList; when search is active, a filtered subset reaches it. In both cases, sortBalancesByValue applied inside TokenList produces the correct descending-value order for whatever subset it receives.
• Empty prices: sortBalancesByValue is a no-op when prices is empty or null — tokens keep their existing sortBalances order (XLM first, LP last).
• Zero price: Assets with price "0" are treated as priced with value 0 (sorting them below assets with positive value but above unpriced assets). This matches the existing sortBalancesByValue semantics.

What this does NOT change

• XLM pinning is not applied (per updated issue description).
• The stable-sort behavior on the Account view is unchanged (different rendering path entirely).
• The baseline sortBalances in useGetBalances remains (provides tie-breaking insertion order for assets without price data).

---

This proposal was refined through 4 round(s) of adversarial review using the plan-do-review skill.