feat(decimal): decimal precision on send/swap, and amount input display fix - #894
feat(decimal): decimal precision on send/swap, and amount input display fix#894raul-oliveira wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 8 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (13)
📝 WalkthroughWalkthroughAmount rendering now uses shared font fitting and wrapping. Inputs support controlled sizing, single-line mode, newline removal, and capped decimal parsing. Balance, send, confirmation, and swap screens use shared sizing and server-provided decimal precision. ChangesAmount rendering and input flow
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant SendAmountInput
participant computeAmountFontFit
participant AmountTextInput
participant TokenBox
SendAmountInput->>SendAmountInput: measure amount area width
SendAmountInput->>computeAmountFontFit: calculate font size and wrapping
computeAmountFontFit-->>SendAmountInput: return fontSize and wraps
SendAmountInput->>AmountTextInput: pass fontSize and singleLine
SendAmountInput->>TokenBox: apply row or stacked layout
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
1db45fa to
172ba28
Compare
aa14225 to
3ec25fa
Compare
3ec25fa to
09eca73
Compare
09eca73 to
73fe507
Compare
raul-oliveira
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/AmountTextInput.js`:
- Around line 135-176: Update the props destructuring in AmountTextInput so
component-only fields value, decimalPlaces, allowOnlyInteger, and onAmountUpdate
are removed from restProps before the native TextInput spread. Keep the
sanitized local text state as the effective value by ensuring restProps cannot
override the explicit value={text}, while preserving forwarding of legitimate
native TextInput props.
In `@src/screens/TokenSwap.js`:
- Around line 170-172: Update the effect containing the quote amount assignments
to depend on decimalPlaces as well as quote, so renderValue recomputes both
input and output strings when precision changes after a quote arrives. Preserve
the existing numeric amount state updates and avoid changing quote-fetching
behavior.
- Line 426: The conversion-rate rendering in renderConversionRate must preserve
exact arithmetic for BigInt quote amounts instead of converting them to Number
or multiplying by a numeric oneToken. Update renderConversionRate and both call
sites in src/screens/TokenSwap.js (426-426) and src/screens/TokenSwapReview.js
(293-293) to calculate and format the rate using BigInt-compatible decimal
scaling, preserving correctness for values above Number.MAX_SAFE_INTEGER.
In `@src/screens/TokenSwapReview.js`:
- Line 320: Use connected server metadata for all native-token fee labels:
update TokenSwapReview.js:320 to use serverInfo.native_token.symbol instead of
the library default, and ensure SendConfirmScreen.js:277 and
SendConfirmScreen.js:362 derive nativeSymbol from
serverInfo.native_token.symbol.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f98c9fbc-8d52-4bb4-90b5-1a2f5816899e
📒 Files selected for processing (13)
src/components/AmountDisplay.jssrc/components/AmountTextInput.jssrc/components/TokenBox.jssrc/components/TxDetailsModal.jssrc/constants.jssrc/screens/CreateTokenAmount.jssrc/screens/MainScreen.jssrc/screens/SendAmountInput.jssrc/screens/SendConfirmScreen.jssrc/screens/TokenSwap.jssrc/screens/TokenSwapReview.jssrc/screens/TokenSwapTokenList.jssrc/utils.js
raul-oliveira
moved this from In Progress (WIP)
to In Progress (Done)
in Hathor Network
raul-oliveira
moved this from In Progress (Done)
to In Progress (WIP)
in Hathor Network
73fe507 to
5c2acaa
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/constants.js`:
- Around line 162-164: Update MAX_DECIMAL_PLACES in the constants module from 8
to 18 so getAmountParsed accepts the required fractional precision. Add boundary
tests covering amounts with 8, 9, and 18 fractional digits, verifying each is
accepted.
In `@src/screens/SendConfirmScreen.js`:
- Line 277: Update both fee display lines in SendConfirmScreen to use the
connected server metadata symbol from serverInfo.native_token.symbol instead of
the default hathorLib nativeSymbol, while keeping the existing fee value and
formatting unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f8195970-70e8-4653-a5dc-6b01d5ea9847
📒 Files selected for processing (13)
src/components/AmountDisplay.jssrc/components/AmountTextInput.jssrc/components/TokenBox.jssrc/components/TxDetailsModal.jssrc/constants.jssrc/screens/CreateTokenAmount.jssrc/screens/MainScreen.jssrc/screens/SendAmountInput.jssrc/screens/SendConfirmScreen.jssrc/screens/TokenSwap.jssrc/screens/TokenSwapReview.jssrc/screens/TokenSwapTokenList.jssrc/utils.js
🚧 Files skipped from review as they are similar to previous changes (10)
- src/screens/CreateTokenAmount.js
- src/utils.js
- src/screens/TokenSwapTokenList.js
- src/screens/TokenSwapReview.js
- src/components/AmountDisplay.js
- src/components/TokenBox.js
- src/screens/SendAmountInput.js
- src/screens/MainScreen.js
- src/components/AmountTextInput.js
- src/components/TxDetailsModal.js
5c2acaa to
e1cb665
Compare
…splay - Amount input accepts up to 18 decimal places, independent of the token's precision; the value is still scaled to the token's decimal_places when the transaction is built. - Long amounts shrink to stay on one line and, at the minimum size, wrap across up to 3 lines instead of shrinking indefinitely (AmountDisplay + the computeAmountFontFit ladder). - Read-only balances (transaction details, home available/locked) and the transaction-row amount shrink/wrap the same way. - Thread the network's decimal_places through the send and token-swap amount displays so quotes and confirmations render with the correct precision. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G9asQ9EmwUmCpv34aM7v2v
e1cb665 to
c50dbb0
Compare
raul-oliveira
moved this from In Progress (WIP)
to In Progress (Done)
in Hathor Network
| parsedText = getAmountParsed(parsedText, decimalPlaces); | ||
| // Accept up to MAX_DECIMAL_PLACES typed decimals regardless of the token's | ||
| // precision; the value below is still scaled to the token's decimalPlaces. | ||
| parsedText = getAmountParsed(parsedText, MAX_DECIMAL_PLACES); |
There was a problem hiding this comment.
issue(blocking): typed decimals beyond the token's precision are silently truncated
getAmountParsed(parsedText, MAX_DECIMAL_PLACES) keeps 8 typed decimals, but line 97 scales with the token's decimalPlaces and getIntegerAmount slices the excess away.
On a 2-decimal network, typing 1.12345678 displays that string and sends 112n (1.12); 0.00000001 yields 0n, which isValid accepts, so the field shows a value while Continue stays disabled with no error.
Previously the text was clamped, so what you saw was what you sent. Consider getAmountParsed(parsedText, decimalPlaces ?? MAX_DECIMAL_PLACES), which keeps the undefined-serverInfo fallback without discarding entered precision.
| * @param {number} [minFontSize] Floor font size below which it wraps instead of shrinking | ||
| * @return {{ fontSize: number, wraps: boolean }} | ||
| */ | ||
| export const computeAmountFontFit = ( |
There was a problem hiding this comment.
issue(non-blocking): new pure util computeAmountFontFit ships with no unit tests
Three-branch ladder (base / shrink / floor + wrap) with a boundary at minFontSize, and its wraps flag drives the Send screen's row→column switch. Flipping a >= to > at either boundary silently changes when the token box drops below the amount.
The function is pure and takes plain numbers — a small input/output table next to __tests__/utils/amountFormat.test.js pins the ladder cheaply. Worth noting the suite is a local gate only: .github/workflows/main.yml has no npm test step, so nothing here runs in CI.
| setOutputTokenAmountStr(renderValue(quote.amount_out, false, decimalPlaces)); | ||
| setOutputTokenAmount(quote.amount_out); | ||
| } | ||
| }, [quote]); |
There was a problem hiding this comment.
nitpick: effect reads decimalPlaces but doesn't list it as a dependency
If serverInfo ever resolved after a quote, the two amount strings would keep the precision they were formatted with. In practice serverInfo lands during wallet start, well before this screen mounts, so it's latent rather than live — but adding it costs nothing.
2 participants
Builds on #891 (amount format foundation) and extends the decimal-places fix to the send and token-swap screens. Aligns the amount input and amount displays with the Amounts Update Figma.
Acceptance Criteria
decimal_placeswhen the transaction is built.decimal_placesinstead of the wallet-lib default of 2, extending the feat(decimal): add wallet-wide amount format preference #891 decimal fix to these screens.Security Checklist
Screenshots
Token swap
Send transaction
Decimal.Precision.Fix.PR.894.mov
Summary by CodeRabbit
New Features
Bug Fixes