fixed - supported token not loading

[Arnav-Nehra]

Tokens were already loading on Mainnet but they were not working on Testnet so Added proper error logging for better UX

fixes #31

Summary by CodeRabbit

• New Features
  • Shows a testnet warning banner when viewing a testnet chain and disables token selection where not supported.
• Bug Fixes
  • Improved error messages for token loading: clearer, context-specific text for testnet limitations and unsupported chains.
  • Ensured UI state consistency when serving cached token data so loading/error indicators are accurate.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

TokenPicker.jsx gains testnet detection and conditional error/UI flows that show testnet warnings and tailored error messages; useTokenList.js exports isTestnet and clears error/loading state when returning cached tokens to keep UI consistent. (47 words)

Changes

Cohort / File(s)	Summary
Token Selection UI & Error Handling frontend/src/components/TokenPicker.jsx	Added ChainIdToName and isTestnet usage; show testnet warning banner; button disabled state respects testnet; replace single error block with conditional rendering for "manually input" (testnet-specific message with chain name/id), "not supported" (Chain Not Supported), or generic load failure; preserve loading/no-results flows.
Token Cache & Loading State / Export frontend/src/hooks/useTokenList.js	Exported isTestnet function (replacing local const); on cache-hit, clear tokensError and set loading=false while populating cached tokens to ensure UI state consistency.

Sequence Diagram(s)

(omitted — changes are UI/logic tweaks that do not introduce new multi-component sequential flows)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Update README with stability standard #10 — Modifies the same token-list/token-picker areas (useTokenList.js, TokenPicker.jsx) including isTestnet export and token error/UI handling.

Suggested reviewers

• adityabhattad2021

Poem

🐰 Hop, hop — tokens clearer, banners bright,
Chains wear names that guide each little light,
Cached crumbs reset, buttons pause when nets test,
Errors whisper where selections rest,
I nibble code and celebrate the nest.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fixed - supported token not loading' directly addresses the main issue being resolved and matches the PR's primary objective of fixing token loading problems.
Linked Issues check	✅ Passed	The PR addresses the core requirement of issue #31 by implementing testnet detection, disabling token search on testnets, and adding clear error messaging for unsupported networks.
Out of Scope Changes check	✅ Passed	All changes are directly related to fixing token loading and implementing the agreed-upon solution of disabling token search on testnets with appropriate error messaging.

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Arnav-Nehra]

@kumawatkaran523 please review

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

frontend/src/components/TokenPicker.jsx (1)

318-348: Consider using error types instead of string matching.

The current approach uses .includes() to parse error message strings, which tightly couples the UI to the exact wording of error messages from useTokenList. This makes the code fragile and harder to maintain.

Consider refactoring to use structured error objects or error codes:

// In useTokenList.js, return structured errors:
setError({ type: 'TESTNET_NOT_SUPPORTED', message: '...', chainId });
setError({ type: 'CHAIN_NOT_SUPPORTED', message: '...', chainId });

// In TokenPicker.jsx, check error type:
{tokensError.type === 'TESTNET_NOT_SUPPORTED' ? (
  // testnet UI
) : tokensError.type === 'CHAIN_NOT_SUPPORTED' ? (
  // unsupported chain UI
) : (
  // generic error UI
)}

This approach is more maintainable, supports i18n better, and decouples UI logic from error message text.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 160eef1 and 5aafbb8.

📒 Files selected for processing (2)

• frontend/src/components/TokenPicker.jsx
• frontend/src/hooks/useTokenList.js

🧰 Additional context used

🧬 Code graph analysis (1)

frontend/src/components/TokenPicker.jsx (1)

frontend/src/hooks/useTokenList.js (2)

• ChainIdToName (12-16)
• ChainIdToName (12-16)

🔇 Additional comments (1)

frontend/src/hooks/useTokenList.js (1)

28-29: Good fix for UI state consistency.

Explicitly clearing the error and loading states when returning cached tokens prevents stale UI states from persisting. This ensures the component consuming this hook receives consistent state regardless of whether data comes from cache or a fresh fetch.

[kumawatkaran523]

@Arnav-Nehra, What I think that opening the token search only on Mainnet will be a good idea. It reduces confusion for users who are connected to testnets or other chains, where the token list is often empty or not relevant.

What I Recommend :

• Open token search only when the user is connected to Mainnet.
• On non-mainnet networks, show a small inline message or toast with a “Switch to Mainnet” action (or keep the search button disabled with a tooltip).
• This is clearer for users and avoids unexpected behavior.

Pros

• Less confusing for users on testnets or other networks
• Avoids unnecessary network requests and empty results
• Clearly guides users to switch to mainnet when they want to search tokens

What you think ??

[Arnav-Nehra]

Yes, I think this is a better approach.

1. We can disable the button
2. And also add another button next to it to switch to the mainnet, similar to what we have on the Sent Invoices and Received Invoices pages.

[kumawatkaran523]

Yes @Arnav-Nehra ,go ahead

[Arnav-Nehra]

please review @kumawatkaran523 I have disabled the button on testnet and also added an message below it

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

frontend/src/components/TokenPicker.jsx (2)

267-274: Consider condition refinement for testnet warning.

The testnet warning banner provides clear feedback to users. However, it displays whenever isOnTestnet is true, even if the component is already disabled via the disabled prop for unrelated reasons.

Consider refining the condition to isOnTestnet && !disabled to avoid redundant warnings when the component is disabled for other reasons.

🔎 Proposed refinement

-      {isOnTestnet && (
+      {isOnTestnet && !disabled && (
         <div className="mt-2 flex items-start gap-2 p-3 bg-amber-50 border border-amber-200 rounded-lg">

---

329-359: Refactor to use structured error handling instead of string matching.

The error rendering logic relies on string matching (tokensError.includes("manually input") and tokensError.includes("not supported")), which is fragile. The useTokenList hook returns error messages with these strings embedded (line 38 and 45 of useTokenList.js). If the error messages change, this conditional logic will break and users will see generic error messages instead of the intended testnet-specific or chain-specific feedback.

Consider refactoring useTokenList to return structured errors (error codes or error types) instead of relying on string matching:

// Example structured approach:
if (tokensError?.type === 'TESTNET_NOT_SUPPORTED') {
  // render testnet message
} else if (tokensError?.type === 'CHAIN_NOT_SUPPORTED') {
  // render chain not supported message
}

This would make the code more maintainable and resilient to error message wording changes.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5aafbb8 and cf7c849.

📒 Files selected for processing (2)

• frontend/src/components/TokenPicker.jsx
• frontend/src/hooks/useTokenList.js

🚧 Files skipped from review as they are similar to previous changes (1)

• frontend/src/hooks/useTokenList.js

🧰 Additional context used

🧬 Code graph analysis (1)

frontend/src/components/TokenPicker.jsx (3)

frontend/src/hooks/useTokenList.js (4)

• isTestnet (10-10)
• isTestnet (10-10)
• ChainIdToName (12-16)
• ChainIdToName (12-16)

frontend/src/components/ui/button.jsx (1)

• Button (37-45)

frontend/src/lib/utils.js (1)

• cn (4-6)

🔇 Additional comments (3)

frontend/src/components/TokenPicker.jsx (3)

15-15: LGTM! Imports are correctly added.

The newly imported ChainIdToName and isTestnet utilities are properly exported from the hook and used appropriately in the component.

---

219-219: LGTM! Testnet detection is correctly implemented.

The isOnTestnet variable properly uses the imported isTestnet utility with the provided chainId.

---

224-234: Verify if "Switch to Mainnet" button should be implemented.

The button correctly disables on testnets and applies appropriate styling. However, based on the PR discussion, there was an agreement to add a secondary "Switch to Mainnet" button (similar to the existing pattern on Sent/Received Invoices pages) to help users switch networks when on testnets.

This implementation only shows a warning message (lines 267-274) without the interactive button to switch networks. Please confirm whether:

1. The "Switch to Mainnet" button feature should be added in this PR
2. Or if it's deferred to a future PR