fix(settings): allow negative coordinates in position config - #1381
fix(settings): allow negative coordinates in position config#1381dzienisz wants to merge 3 commits into
Conversation
|
Someone is attempting to deploy a commit to the Meshtastic Team on Vercel. A member of the Team first needs to authorize it. |
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughNumeric input handling now preserves intermediate and invalid values. Position fields support longer coordinate values. Position validation limits optional latitude and longitude values to seven decimal places while retaining range checks. ChangesNumeric position input handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change allows negative latitude and longitude entry while preserving valid range and precision checks. No actionable merge-blocking risk remains beyond normal checks and review. Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Description checkExplanation The description explains the bug, links issue Full details: Linked Issues checkExplanation The changes satisfy issue
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
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 |
![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
🤖 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 `@apps/web/src/components/Form/FormInput.tsx`:
- Around line 73-75: Update the onChange normalization around parsed in
FormInput so numeric validation covers the complete newValue rather than
accepting parseFloat prefixes. Preserve intermediate empty, negative, and
decimal-typing states, accept only finite complete numeric values (including
-34.1147648), and retain invalid text such as "1e", "12abc", "1.2.3", and
"Infinity"; add regression tests for the specified cases.
🪄 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: 3e792b89-18de-453a-9a77-c6a6f620759f
📒 Files selected for processing (2)
apps/web/src/components/Form/FormInput.tsxapps/web/src/components/PageComponents/Settings/Position.tsx
💤 Files with no reviewable changes (1)
- apps/web/src/components/PageComponents/Settings/Position.tsx
2b016f0 to
ce35dc3
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 `@apps/web/src/validation/config/position.ts`:
- Around line 24-35: Update the latitude and longitude schemas in the position
validation definition to normalize blank string inputs to undefined before
numeric coercion, preserving optional behavior for cleared fields. Ensure
clearing either coordinate, or both coordinates, produces undefined rather than
numeric zero in the form output consumed by submit.
- Around line 6-10: Update maxDecimalPlaces to account for exponent digits when
validating decimal precision, rather than relying only on splitting
value.toString() at the decimal point. Ensure exponential values such as 1.2e-7
are rejected when their effective decimal places exceed places, while preserving
the existing undefined and valid-precision behavior.
🪄 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: a9d656bb-d944-4eb8-80b7-8b93708f6c19
📒 Files selected for processing (3)
apps/web/src/components/Form/FormInput.tsxapps/web/src/components/PageComponents/Settings/Position.tsxapps/web/src/validation/config/position.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/src/components/Form/FormInput.tsx
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@apps/web/src/validation/config/position.test.ts`:
- Around line 53-67: Extend the tests around PositionValidationSchema to cover
both sides of each coordinate bound: reject latitude -91 and longitude 181, and
verify the inclusive boundary values -90, 90, -180, and 180 are accepted using
validBase.
🪄 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: dab35dee-e7ee-455d-8eac-b526957fd03f
📒 Files selected for processing (1)
apps/web/src/validation/config/position.test.ts
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Thank you for the contribution. Please resolve the CodeRabbit comments on the PR, many are valid concerned about the submitted code. |
…sion Preserve intermediate input values (-, empty string, trailing decimal point) in number fields instead of converting them to "NaN". Raise the latitude/longitude fieldLength limits so negative values with 7 decimal places fit (-34.1147648 / -180.0000000). Add Zod refine validation that enforces a maximum of 7 decimal places on latitude and longitude, replacing the incorrect string-length-based check. Fixes meshtastic#1308 Generated with [Devin](https://devin.ai)
Covers positive/negative latitude and longitude with 7 decimal places, rejection of values exceeding 7 decimal places, and rejection of values outside the valid range. Generated with [Devin](https://devin.ai)
d1f81fc to
d1f3ccc
Compare
|
|
@danditomaso check it now |
Looks good! Thanks for fixing this! |
| const maxDecimalPlaces = (places: number) => (value: number | undefined) => { | ||
| if (value === undefined) return true; | ||
| // Account for exponential notation, e.g. 1.2e-7 has 8 decimal places. | ||
| const [mantissa = "", exponent = "0"] = value.toString().split(/e/i); |
There was a problem hiding this comment.
Sorry I didn't catch this before, what is a mantissa?
- Validate the complete numeric string in FormInput instead of accepting parseFloat prefixes, preserving invalid text like "12abc" or "1.2.3" for validation to catch; extract normalizeNumberInput with unit tests - Count decimal places across exponential notation (e.g. 1.2e-7) in the position precision refinement - Map empty coordinate strings to undefined before numeric coercion so cleared fields do not submit a 0,0 fixed position - Test both inclusive ends of latitude/longitude ranges
Head branch was pushed to by a user without write access
0f9a45e to
d0d753e
Compare
3 participants
Fixes #1308.
Number.parseFloat("-").toString()produced"NaN"while typing a negative latitude/longitude, preventing users in the southern/western hemisphere from entering coordinates. This change preserves intermediate values (-, empty string, trailing decimal point) and only normalizes complete numbers.Also fixes the latitude/longitude field length limits so negative values with 7 decimal places fit (
-34.1147648/-180.0000000).Adds Zod refine validation on latitude and longitude to enforce a maximum of 7 decimal places, matching the wire format precision (
latitudeI/longitudeIare stored as degrees × 10⁷).Adds unit tests for the position schema covering positive/negative coordinates, 7 decimal precision, and out-of-range values.
Generated with Devin
Summary by CodeRabbit