Skip to content
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.

Sign up for GitHub

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

Jump to bottom

i18n Numbering Systems Testing: Issue with # of digits using up and down arrows #5920

Closed
annierm18 opened this issue Dec 6, 2022 · 3 comments
Closed

i18n Numbering Systems Testing: Issue with # of digits using up and down arrows #5920

annierm18 opened this issue Dec 6, 2022 · 3 comments
Assignees
@geospatialem
Labels
4 - verified Issues that have been released and confirmed resolved. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. i18n-l10n issues dealing with internationalization/localization
Milestone
2023 February Pri...

Comments

@annierm18
Copy link
Contributor

annierm18 commented Dec 6, 2022 •
edited by geospatialem
Loading

Actual Behavior

In the Calcite input component:

  • With a greater than a certain number of digits, like >15 digits after the decimal and 2 digits before the decimal, using the up and down arrows rounds the number in an unexpected way.
  • Without including a decimal separator: Is it expected that "e" appears? With "e", the decimal separator gets pushed to right after the first digit. When I backspace to make the number smaller, and manually remove the "e", the decimal separator remains in the same place. So my number goes from very large, like "8173847023850385108501835981", to very small, like "13.17384702"

Info from @benelan : "Using the increment buttons is converting it to a number"

Expected Behavior

With decimal - the number should not round.
Without decimal - I am not sure what the expected behavior should be, but I imagine if I remove the symbol that means "number to the power of x", then decimal separator should move back to the original spot...e.g. my number "8173847023850385108501835981" would not become "13.17384702".

Reproduction Sample

https://codepen.io/ainermfc/pen/XWYMqNE

Reproduction Steps

(With group-separator...the repro steps may involve a different # of digits without group-separator

  1. Enter a number with > 17 digits and include a decimal separator somewhere in the number
  2. Click the up or down arrows
  3. Enter a number with > 17 digits and no decimal
  4. Use arrows and add digits until you see "e" appear in the number
  5. Remove digits manually with the back space until e is removed

Reproduction Version

1.0.0-beta.97

Relevant Info

No response

Regression?

v1.0.0-beta.97

Impact

No response

Esri team

N/A
@annierm18 annierm18 added bug Bug reports for broken functionality. Issues should include a reproduction of the bug. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. i18n-l10n issues dealing with internationalization/localization labels Dec 6, 2022
@benelan benelan added 1 - assigned Issues that are assigned to a sprint and a team member. and removed 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Dec 7, 2022
@benelan benelan self-assigned this Dec 7, 2022
@benelan benelan added 2 - in development Issues that are actively being worked on. and removed 1 - assigned Issues that are assigned to a sprint and a team member. labels Mar 7, 2023
@benelan benelan mentioned this issue Mar 9, 2023
Merged
benelan added a commit that referenced this issue Mar 14, 2023
@benelan
fix(input, input-number): increment/decrement unsafe numbers without …
40c0f0f 
…loss of precision (#6580)

**Related Issue:** #5920

## Summary

Numbers that cannot be represented in JavaScript's IEEE-754 double
precision were being rounded when incrementing/decrementing because they
were cast as Number (we store the value as a string). We use BigDecimal
class to support numbers that do not fit into JavaScript's encoding
method. I had overlooked the increment/decrement functionality when
implementing BigDecimal.

BigDecimal uses BigInt internally, and unfortunately BigInt doesn't
support exponential notation. For example, `BigInt("1e2") ` throws the
error:

> Uncaught SyntaxError: invalid BigInt syntax

To work around the constraint, I manually expand any exponential
notation numbers into normal decimal numbers.

For more info:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isSafeInteger#description
@geospatialem geospatialem mentioned this issue Mar 15, 2023
Closed
@geospatialem
Copy link
Member

Created a new issue to track the first portion of the original issue cc @annierm18 @benelan @jcfranco

@geospatialem geospatialem added 3 - installed Issues that have been merged to master branch and are ready for final confirmation. and removed 2 - in development Issues that are actively being worked on. labels Mar 15, 2023
@geospatialem geospatialem changed the title i18n Numbering Systems Testing: Issue with group separator and issue with # of digits using up and down arrows i18n Numbering Systems Testing: Issue with # of digits using up and down arrows Mar 15, 2023
@github-actions github-actions bot assigned geospatialem and unassigned benelan Mar 15, 2023
@github-actions
Copy link
Contributor

Installed and assigned for verification.

@geospatialem geospatialem added 4 - verified Issues that have been released and confirmed resolved. and removed 3 - installed Issues that have been merged to master branch and are ready for final confirmation. labels Mar 15, 2023
@geospatialem
Copy link
Member

Verified on master

verify-input

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@geospatialem geospatialem

Labels
4 - verified Issues that have been released and confirmed resolved. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. i18n-l10n issues dealing with internationalization/localization
Projects
None yet
Milestone
2023 February Priorities - 1.1.0 - No...
Development

No branches or pull requests
4 participants
@alisonailea @geospatialem @benelan @annierm18