Allow two decimal places in revenue split inputs#987
Conversation
Deploying register-app with
|
| Latest commit: |
ca753de
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://cc31d00d.register-app.pages.dev |
| Branch Preview URL: | https://codex-fix-decimal-precision.register-app.pages.dev |
📝 WalkthroughWalkthroughUpdated two revenue-split components: numeric input validation regexes now allow up to two decimal places; ExternalRevenueSplit’s reciprocal calculation was replaced by a helper that computes the complementary percent as Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Review rate limit: 2/3 reviews remaining, refill in 20 minutes. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/rtoken-setup/token/ExternalRevenueSplit.tsx`:
- Around line 58-59: Round the reciprocal values to 2 decimal places before
calling setValue to avoid float artifacts; locate the places where
setValue('holders', ((10000 - +stakers * 100) / 100).toString()) and the
analogous setValue call around lines 73-74 are used, compute the reciprocal into
a variable, normalize it via a 2-decimal rounding (e.g., Math.round(value * 100)
/ 100 or Number(value.toFixed(2))), then convert that rounded value to string
and pass it to setValue so the form only receives 2dp values.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: cb3ec60a-4654-4885-86cb-3b5dfe5ae1e4
📒 Files selected for processing (2)
src/components/rtoken-setup/token/ExternalRevenueSplit.tsxsrc/components/rtoken-setup/token/RevenueSplit.tsx
lcamargof
left a comment
There was a problem hiding this comment.
The sum should be 100, so the values needs to be rounded if required, 99.999999 is not acceptable and a valid case with the current code.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/rtoken-setup/token/RevenueSplit.tsx`:
- Line 37: The current validation regex in the RevenueSplit component (pattern:
/^\d+(\.\d{1,2})?$/) is too strict for in-progress user input and rejects values
like "45." while typing; change the pattern to allow 0–2 fractional digits
during input (for example /^\d+(\.\d{0,2})?$/) so intermediate values with a
trailing dot are accepted, while relying on existing required/range checks for
final validity. Update the pattern literal used in RevenueSplit (where pattern:
/^\d+(\.\d{1,2})?$/ is defined) accordingly.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 51597493-3426-4d8e-a850-6ed88b8dd155
📒 Files selected for processing (2)
src/components/rtoken-setup/token/ExternalRevenueSplit.tsxsrc/components/rtoken-setup/token/RevenueSplit.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- src/components/rtoken-setup/token/ExternalRevenueSplit.tsx
| const inputValidation = { | ||
| required: true, | ||
| pattern: /^[0-9]*[.]?[0-9]$/i, | ||
| pattern: /^\d+(\.\d{1,2})?$/, |
There was a problem hiding this comment.
Regex is too strict for in-progress decimal input
At Line 37, /^\d+(\.\d{1,2})?$/ rejects intermediate values like 45. while typing, which can still trigger avoidable validation noise in onChange mode. Consider allowing 0–2 fractional digits during input and relying on required + range checks for final validity.
Suggested adjustment
- pattern: /^\d+(\.\d{1,2})?$/,
+ pattern: /^\d+(\.\d{0,2})?$/,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/components/rtoken-setup/token/RevenueSplit.tsx` at line 37, The current
validation regex in the RevenueSplit component (pattern: /^\d+(\.\d{1,2})?$/) is
too strict for in-progress user input and rejects values like "45." while
typing; change the pattern to allow 0–2 fractional digits during input (for
example /^\d+(\.\d{0,2})?$/) so intermediate values with a trailing dot are
accepted, while relying on existing required/range checks for final validity.
Update the pattern literal used in RevenueSplit (where pattern:
/^\d+(\.\d{1,2})?$/ is defined) accordingly.
Motivation
45.23) even though proposal simulation accepted them.Description
src/components/rtoken-setup/token/RevenueSplit.tsxto allow up to two decimal places (/^[0-9]*[.]?[0-9]{0,2}$/i).src/components/rtoken-setup/token/ExternalRevenueSplit.tsx.((1000 - x*10)/10)to((10000 - x*100)/100)so complementary fields match 2dp values.Testing
pnpm -s typecheck, which completed successfully.pnpm -s eslint src/components/rtoken-setup/token/RevenueSplit.tsx src/components/rtoken-setup/token/ExternalRevenueSplit.tsx, but ESLint could not run in this environment due to the repository not exposing aneslint.config.(js|mjs|cjs)file (ESLint v9 migration requirement), so linting was not executed here.Codex Task
Summary by CodeRabbit