feat(signer): add some tari signer improvements#31
Conversation
WalkthroughThe changes update balance handling for the Tari network by introducing a new Changes
Sequence Diagram(s)sequenceDiagram
participant UI as UI Component
participant Store as Tari Account Store
participant Signer as TariL1Signer
participant Backend as Tari Backend
UI->>Store: useTariAccount()
Store->>Signer: getTariBalance()
Signer->>Backend: sendRequest('getTariBalance')
Backend-->>Signer: WalletBalance
Signer-->>Store: WalletBalance
Store-->>UI: available_balance
UI->>UI: Display available_balance
Possibly related PRs
Suggested reviewers
Poem
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. ✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
clients/tari-l1-signer.ts (1)
8-8: Update JSDoc to reflect new return type.The return type has been changed from
Promise<string>toPromise<WalletBalance>, which is a good enhancement. However, the JSDoc comment still indicates it returns "XTM amount" which is now inaccurate.Update the JSDoc to match the new return type:
/** * @description get Tari Account balance - * @returns XTM amount + * @returns WalletBalance object containing available_balance, timelocked_balance, pending_incoming_balance, and pending_outgoing_balance */Also applies to: 94-94
store/account.ts (1)
47-49: Well-implemented balance fetching and storage!The integration of balance fetching and storage works well. The balance is fetched after confirming the account and connection status, and properly stored in the state.
Consider adding a more specific error message when balance fetching fails, as the current catch block only mentions "Could not set the Tari account" which doesn't specifically indicate balance retrieval issues:
} catch (error) { - console.error('Could not set the Tari account: ', error) + console.error('Could not set the Tari account or fetch balance: ', error) }Also applies to: 54-54
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
clients/tari-l1-signer.ts(2 hunks)components/bridge-modal.tsx(3 hunks)components/main/main.component.tsx(3 hunks)hooks/use-bridge-to-ethereum.ts(2 hunks)store/account.ts(3 hunks)types/tapplet/account.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
components/bridge-modal.tsx (1)
store/account.ts (1)
useTariAccount(32-79)
components/main/main.component.tsx (1)
store/account.ts (1)
useTariAccount(32-79)
clients/tari-l1-signer.ts (1)
types/tapplet/account.ts (1)
WalletBalance(6-11)
🔇 Additional comments (6)
types/tapplet/account.ts (2)
6-11: Well-defined interface for wallet balance.The
WalletBalanceinterface is well-structured with clear property names that follow a consistent naming convention (snake_case). The interface provides a comprehensive view of different balance components, which will be valuable for accurate balance reporting throughout the application.
13-15: Clean interface for pending bridge transactions.The
PendingBridgeTxinterface is simple and focused, containing just what's needed to track pending bridge transactions.components/bridge-modal.tsx (1)
12-12: Great improvement using dynamic balance.Replacing the hardcoded balance with the actual user balance from the Tari account store is a significant improvement for user experience. This ensures users always see their current available balance.
Also applies to: 22-22, 124-124
clients/tari-l1-signer.ts (1)
94-100:Details
❓ Verification inconclusive
Verify backend compatibility with WalletBalance interface.
This method now returns a complex
WalletBalanceobject instead of a string, which is a potentially breaking change. The TODO comment suggests this might still need implementation on the Tari Universe side.Please verify that the backend implementation of
getTariBalanceactually returns an object that matches theWalletBalanceinterface structure. If the method currently returns a string, additional work may be needed on the backend to support this change.
🏁 Script executed:
#!/bin/bash # Check if there are other places using getTariBalance that might expect a string rg "getTariBalance\(\)" -A 3 -B 3Length of output: 916
Verify backend returns a
WalletBalanceobjectIt looks like there are no callers expecting a string—e.g. in
store/account.tsyou log and consume the result as an object—so please confirm that your backend’sgetTariBalanceRPC now returns an object matching theWalletBalanceinterface (rather than a raw string amount). If it still returns a string, you’ll need to update the backend API to supply the full balance structure.Files to check:
clients/tari-l1-signer.ts(lines 94–100): method signature and return typestore/account.ts: usage ofsigner.getTariBalance()with object fieldscomponents/main/main.component.tsx (1)
14-14: Great improvement with dynamic Tari balance!The integration of the
useTariAccounthook to display the actual Tari balance is well-implemented. This replaces the hardcoded Tari balance value with the dynamically fetchedavailable_balance, providing users with accurate information.Note that balances for other networks are still hardcoded, as referenced in the TODO comment on line 69. Might be worth planning for future enhancements to fetch those balances dynamically as well.
Also applies to: 32-32, 72-72
store/account.ts (1)
7-7: Good addition of balance state management!The state interface and initial state are properly updated to include the
available_balanceproperty, with a sensible default value of 0.Also applies to: 27-27
| @@ -1,4 +1,4 @@ | |||
| import { config } from '@/config' | |||
| // import { config } from '@/config' | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Avoid hardcoding API URLs in the code.
Replacing configuration-based API URL with a hardcoded staging URL creates several issues:
- Reduces flexibility across environments (dev, staging, prod)
- Makes it harder to switch environments without code changes
- May cause issues if the staging environment changes or is unavailable
Consider replacing with:
-// import { config } from '@/config'
+import { config } from '@/config'
-// OpenAPI.BASE = config.BACKEND_API_URL
-OpenAPI.BASE = 'https://api.staging-bridge.tari.com'
+OpenAPI.BASE = config.BACKEND_API_URLAlso applies to: 14-15
🏁 Script executed:
#!/bin/bash
# Check if config.ts file exists and verify BACKEND_API_URL structure
fd "config\.(ts|js)" --exec grep -l "BACKEND_API_URL" {} \;Length of output: 62
🏁 Script executed:
#!/bin/bash
# List all config.ts/js files in the repo
echo "Config files found:"
fd "config\\.(ts|js)" || echo "No config.ts/js files at root level"
# Search for BACKEND_API_URL usage across the codebase
echo "Occurrences of BACKEND_API_URL:"
rg -n "BACKEND_API_URL" || echo "No occurrences of BACKEND_API_URL found"Length of output: 397
🏁 Script executed:
#!/bin/bash
# Display the first 30 lines of config/index.ts to verify export structure
echo "=== config/index.ts ==="
sed -n '1,30p' config/index.ts || echo "Unable to read config/index.ts"Length of output: 374
🏁 Script executed:
#!/bin/bash
# Display the first 30 lines of hooks/use-bridge-to-ethereum.ts to verify imports and URL assignment
echo "=== hooks/use-bridge-to-ethereum.ts (lines 1-30) ==="
sed -n '1,30p' hooks/use-bridge-to-ethereum.ts || echo "File not found"Length of output: 1076
Avoid hardcoding API URLs
Hardcoding the staging endpoint reduces flexibility and forces code changes for environment switches. Since config/index.ts already exports BACKEND_API_URL, you can drive the base URL from environment variables:
• File: hooks/use-bridge-to-ethereum.ts
– Uncomment the import for config
– Replace the hardcoded staging URL with config.BACKEND_API_URL
Suggested diff:
--- a/hooks/use-bridge-to-ethereum.ts
+++ b/hooks/use-bridge-to-ethereum.ts
@@ 1,3c1,3
-// import { config } from '@/config'
+import { config } from '@/config'
@@ 14,16c14
-// OpenAPI.BASE = config.BACKEND_API_URL
-OpenAPI.BASE = 'https://api.staging-bridge.tari.com'
+OpenAPI.BASE = config.BACKEND_API_URLThis ensures the bridge service URL adapts to dev, staging or prod based on process.env.NEXT_PUBLIC_BACKEND_API_URL.
1 participant
Summary by CodeRabbit