Allow number fields to be configured with floating point numbers

[Skaiir]

Is your feature request related to a problem? Please describe

Currently numbers are implicitly considered to be integer, but we should also allow for floating point numbers as is the case with the html input equivalent.

Describe the solution you'd like

The way I see it, this should be configurable in the number component and nowhere else, one solution here would be to offer an option to the user to set the precision of the number field, defaulted to zero.

One question that is up in the air here would be what we do with the up and down arrows. They serve very little purpose when dealing with really small numbers, so that behavior still needs to be defined.

Additional context

https://github.com/camunda/product-hub/issues/97

[jonathanlukas]

One note here (because we tripped over the behaviour in a recent training):

When implementing this feature, please make sure the data type of a number modified using a number form does not change. A double MUST stay a double, regardless whether the value itself is floating point or not. An integer must stay an integer, so no floating point can be added. Otherwise. this might have an impact on technical implementation (in Camunda 7 at least).

Maybe adding a toggle to enable/disable floating point numbers as form designer would be a good approach.

[jonathanlukas]

One question that is up in the air here would be what we do with the up and down arrows. They serve very little purpose when dealing with really small numbers, so that behavior still needs to be defined.

I would always increase/decrease the last digit (also of a floating point number).

[Skaiir]

@jonathanlukas Hey, I've had a chat with @tasso94, since the domain of data type handling is out of form-js hands and he's making the point that more gracefully handling datatypes would make more sense. That is to say, if form-js takes in an integer and returns a floating point number, they should grow the datatype accordingly.

An issue for tasklist has been raised here, on our end we're not going to take any particular measures for data handling but if you'd like to argue against the growing of data I would direct you his way as we won't handle that behavior as part of form-js, since that is too implementation specific to end up in the open source library.

Thanks for raising the discussion and for the advice on the increments.

[Skaiir]

Update from team chat

So yesterday I brought up some of the issues we had around copy and pasting and we actually established the sort of behavior we want with Christian's help. Basically, whenever we're providing an external source of data, via copy paste or via input into a number field which doesn't quite fit the validation criteria, we allow the data through but throw validation errors afterwards. This is implemented on my local branch.

However, we still want to restrict the user key inputs in a way that they manually can only enter something valid. To ensure that particular behavior, I've had to move away from using an input type=number to an input type=text. I can go into details as to why but let's just say text inputs are more customizable.

What this also means is that I have to re-implement the stepping arrows that comes for free with the number type. That itself is kind of trivial if it weren't for floating point precision , the villain of this story. Turns out accurately incrementing numbers by fractions of numbers and respecting modulus float increments is pretty horrible and I already had some floating point precision issues that I hacked my way around during the prototyping.

So my proposal, and I think we might need this in the future anyways, but let's just incorporate big.js into form-js . It's a (the) arbitrary precision number library, 20 million weekly downloads, 6kb minified.

I assume one day we'll want to support use cases with numbers that have more than 15 digits of precision. If that is the case, then we'll need a library like this. Going the route of 'we tolerate any precision' from the get-go is actually easier to implement, so if we might want this in the future there's no reason to not do it now.

Would love to gather thoughts on this.