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

Release Notes

• Bug Fixes
  • Enhanced error handling to provide clearer, context-specific feedback when token loading fails—including distinct messages for testnet limitations (where token selection is unavailable) and unsupported chains.
  • Fixed UI state consistency when retrieving cached token data to prevent loading and error state display inconsistencies.

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

[coderabbitai]

📝 Walkthrough

Walkthrough

Two frontend token-selection files are modified: TokenPicker.jsx adds contextual error messages by parsing error strings and referencing chain names; useTokenList.js ensures consistent UI state by clearing error and loading flags when returning cached tokens.

Changes

Cohort / File(s)	Summary
Token Selection UI & Error Handling frontend/src/components/TokenPicker.jsx	Added ChainIdToName import; replaced static error block with conditional rendering that displays different messages for testnet errors (with chain name via ChainIdToName), unsupported chains, or generic failures based on tokensError substring matching
Token Cache & Loading State frontend/src/hooks/useTokenList.js	Cache-hit branch now resets UI state by clearing error and marking loading as false alongside setting cached tokens, ensuring consistent UI state

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Update README with stability standard #10 — Directly modifies the same token-selection code paths in TokenPicker.jsx and useTokenList.js, touching error handling, chain-name resolution, and loading state management.

Suggested reviewers

• adityabhattad2021

Poem

🐰 Hop, hop, the tokens now sing clearer songs,
Error messages bloom where each mistake belongs,
Cached states reset, no confusion in sight,
Chain names guide users through testnets' gentle light. ✨

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 (2 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 objective of fixing token loading issues on testnet while adding improved error handling.

✨ 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.