Skip to content

[@internationalized/number] 0 decimals treated as zero when parsing with exceptZero #8199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AndrewLeedham opened this issue May 7, 2025 · 1 comment · May be fixed by #8236
Open

[@internationalized/number] 0 decimals treated as zero when parsing with exceptZero #8199

AndrewLeedham opened this issue May 7, 2025 · 1 comment · May be fixed by #8236

Comments

@AndrewLeedham
Copy link

AndrewLeedham commented May 7, 2025

Provide a general summary of the issue here

When parsing numbers I would expect the exceptZero option to match the formatting behavior of Intl.NumberFormat but there seems to be a regression where it is seeing decimals that start with 0 as zero.

🤔 Expected Behavior?

new NumberParser('en-US', {style: 'percent', signDisplay: 'exceptZero', minimumFractionDigits: 2}).parse('+0.50%') should parse to 0.005 as the inverse new Intl.NumberFormat('en-US', {style: 'percent', signDisplay: 'exceptZero', minimumFractionDigits: 2}).format('0.005') gives "+0.50%"

😯 Current Behavior

new NumberParser('en-US', {style: 'percent', signDisplay: 'exceptZero', minimumFractionDigits: 2}).parse('+0.50%') gives NaN seemingly because it is treating 0.* as 0.

💁 Possible Solution

Still trying to figure out exactly how

works

🔦 Context

For now I am working around the issue with signDisplay: auto, but I would like to display + and - to make a number input have a fixed length, unless the value is exactly 0.

🖥️ Steps to Reproduce

Pull: https://github.com/AndrewLeedham/react-spectrum/tree/AL/number-repro then run yarn && yarn jest NumberParser

Version

@internationalized/[email protected]

What browsers are you seeing the problem on?

Firefox

If other, please specify.

No response

What operating system are you using?

Windows 11

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

@shahbazianep
Copy link

I am unsure how aligned some of the test cases you have in your forked repository are to the expected behavior. See my amended test cases below.

  1. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'always'}).parse('+10%')).toBe(0.1);
  2. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'always'}).parse('+0%')).toBe(0);
  3. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'always'}).parse('-10%')).toBe(-0.1);
  4. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'always'}).parse('-0%')).toBe(-0);
  5. expect(new NumberParser('en-US', {style: 'percent', signDisplay: 'exceptZero', minimumFractionDigits:2}).parse('+0.50%')).toBe(0.005)
  6. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'exceptZero'}).parse('+0.532%')).toBe(0.01);
  7. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'exceptZero'}).parse('+0%')).toBe(0);
  8. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'exceptZero'}).parse('0.532%')).toBe(0.01);
  9. expect(new NumberParser('en-GB', {style: 'percent', signDisplay: 'exceptZero'}).parse('-0.532%')).toBe(-0.01);
  • Test case 4 has been changed to expect -0, as this is a different value than 0 in JS. This is a gray area and a manual comparison could be added to convert results of -0 back to 0, if desired.
  • Test cases 6, 9 have been changed to reflect the proper expected value (default 2 figures after decimal point, proper rounding)
  • Test case 7 has been changed, as the number should still evaluate regardless of the sign display option
  • Test case 8 has been changed to be proper expected value

I have submitted a PR to amend test cases 2, 6, 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants