rfc: use a big-number library for the NumberField component

[radium-v]

💬 RFC

In order to address the multiple issues with how the NumberField component handles things like very large numbers, exponential notation, and localization, I'd like to rewrite it to utilize the MikeMcl/big.js library or something similar.

🔦 Context

There are a bunch of cross-browser problems with how native inputs with type=number deal with user input. Some of those issues are conveniently outlined in this Stackoverflow Blog post. Our own number field implementation suffers from most of the bugs addressed in the article, as well as some of its own.

The most straightforward way to handle the limitations would be to treat the values of number fields not as a number type, but as a string whenever possible, and as a Big as provided by big.js when dealing with stepping.

💻 Examples

• fix: allow more than 12 numbers to be entered in fast-number-field #6713
• fix: not able to enter decimal values in fast-number-field #6714
• FIX: steps ignore exponential in fast-number-field #6869

[rajsite]

Some thoughts:

• I don't know if it is captured explicitly, but conceptually my mental model of fast foundation is that the components should align well with the browser native elements. I should be able to swap an input type=number element with a web component extending NumberField and have it be compatible.
  • The proposal discussed here wouldn't be compatible (it's edge cases would behave different from a native input type=number since it is not based on doubles). I think it would be nice if it was opt-in / a superset of the NumberField api. Maybe a mode / format / numeric-type attribute that could be set to bignumber or a separate BigNumberField implementation.
• It would be nice to not need to depend on an external library if not needed. Could native BigInt be used instead? It is widely supported in browsers. If not for some reason could it be optional in some way to have the dependency added to applications? Some ideas:
  • separate base class BigNumberField
  • the compose method can take an implementation as an optional argument
• We are interested in having a much wider range of numeric representations. U8, U16, U32, U64, U128, I8, I16, I32, I64, I128, F32, F64, F128, FixedPoint, ComplexF32 (i.e. F32 + F32i), ComplexF64 (i.e. F64 + F64i), ComplexF128 (i.e. F128 + F128i). Is it possible to design a base class / method such that custom numeric implementations can be implemented?
• "very large numbers, exponential notation, and localization," we are interested in many different formatting options, i.e. hex views, octal views, binary views, localized units (currency, time), leading zeros, absolute / relative time formats. To a certain extent, essentially all printf style format codes.

[radium-v]

Addressing your points @rajsite:

• For new components, we define their specs to match parity with existing built-in components and other prior work or patterns (if any). Since NumberField already has its own spec, any modifications to the class must be fully compatible with that spec. For the most part, using an alternative number library within the internals of the component shouldn't change any functionality with regard to that spec or its public API. Any externally-facing API changes to a component's spec are considered to be major/breaking changes.
• I agree that using built-in JS would be better - BigInt could work but would require extra math, which I'm not particularly great at. Considering the maintainers of the TC39 decimal proposal acknowledge big.js as a source of inspiration (Ecma TC39 decimal proposal feedback? MikeMcl/big.js#207), we may just need to let that proposal bake for a while.
• Custom numeric representations might be beyond the scope of this particular RFC, but can definitely be considered for our NumberField. From the HTML Standard:

  If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number.

[Mike-E-angelo]

I am researching FluentUI for my Blazor application and I cannot use partial numbers for my number control steps, leading to a poor impression of your product. I use four other control kits that perform this same functionality without issue. Thank you for any effort toward addressing this concern.

[janechu]

Unfortunately @microsoft/fast-foundation is being deprecated, refer to #6955. I see this was mentioned in a PR, we will be addressing open PRs and merging what we can before we snap an archive branch to preserve the latest state of Foundation, however to bring us up to date I am closing out issues.