Not being able to set decimals (precision) for float field

[aquadesk]

Bug report

Required System information

I think version does not really matter for the issue. I think v4.x.x all shows the same issue.

• Node.js version:
• NPM version:
• Strapi version: 4.3.1
• Database:
• Operating system: mac chrome browser

Describe the bug

When editing float field in Content manager, you won't be able to set "3.0" and store with precisions. UI drops any tailing 0s leaving the value as 3

I think this could be controversial but IMO, UI should not be interfere with what user want to save as long as it's valid value. 3.0 3.00 3.000 all are valid and should be stored as is instead of 3 which could interpreted as integer when parsing graphql response.

Steps to reproduce the behavior

1. create a model with a float or decimal field
2. try to change value with some 0 precision such as 1.0 2.0 3.0000
3. UI removes .000 and sets the value as integer

Expected behavior

Don't change value if the value is valid

Screenshots

[gu-stav]

Thank you for opening the issue. Could you please update to the latest version and check, if the problem still exists? If yes, please add at least the browser you are version and the exact Strapi version to the PR description.

[aquadesk]

Yes i checked the latest 4.3.1 and it has the issue.

I used mac os chrome browser

Thanks

[kasonde]

Confirmed. Once saved, you can't change the value to add more precision. Ideally, 3.0 is the same as 3 but it's kind of not. If I want to make my 3 to 3.0000 it's not going to work.

[gu-stav]

I thought about the issue a bit more in the last couple of days and I think I agree with what you proposed: the number field should not alter the input in any way. The problem currently is, that we are parsing a string into a number, which creates many problems. I think what we need to do here, is to seperate what we display in the UI from what we use internally and add more tests for the NumberInput component, to check all these different use-cases:

• [ ] https://github.com/strapi/design-system/issues/671
• [ ] https://github.com/strapi/design-system/issues/650

I will try to work on this soon.

[Emmanuel-Melon]

I thought about the issue a bit more in the last couple of days and I think I agree with what you proposed: the number field should not alter the input in any way. The problem currently is, that we are parsing a string into a number, which creates many problems. I think what we need to do here, is to seperate what we display in the UI from what we use internally and add more tests for the NumberInput component, to check all these different use-cases:

• [ ] NumberInput: does not handle scientific numbers #671
• [ ] Decimal numbers formatted with comma as decimal separator fail ... #650

I will try to work on this soon.

I've been looking at this issue and I can confirm this. I have one question, I'd like to know why does the e.target object omit trailing zeros?

[gu-stav]

@Emmanuel-Melon I can't tell on top of my head. What I currently have in mind to solve all these problems at once: if it is impossible to use the native number field, we could use a hidden one and utilize the .valueAsNumber attribute, to get the proper internal representation. The component would then only need to take care of displaying the string it got.

Example: https://codepen.io/gu-stav/pen/RwMBMYv

I need to verify that with the team, though.

[aquadesk]

@gu-stav sounds good to me.

I think it is being supported by majority browsers but you might want to double check https://caniuse.com/input-number

[gu-stav]

Hello again. I've done some research today and I don't think there is a way to solve this problem at the moment. The NumberInput parses the input into a JS Number type. In JS a number representation of 10.000 is 10. What we could do is to treat every number field as text, which would bring a lot of downsides (e.g. the API wouldn't be able to return a Number type anymore).

I want to be honest with you: I understand the frustration this brings in terms of an inconsistent UX. The only thing you can do for now is to use a textfield instead, if you want to keep the floating precision.

I will keep the issue open for the case that somebody has a genius idea, how to solve this problem.

[petersg83]

Hello :) I believe it's a feature request and not a bug. Storing a precision in addition to a number is very different than just storing the exact number. For thought food I recommend the section "Significant figures" in this article https://en.wikipedia.org/wiki/Scientific_notation#Significant_figures

[INNOVATIVEGAMER]

I have looked into the NumberInput component and what I can see is when OnBlur is triggered we are parsing the inputValue and then showing it to the user on screen. Expected should be just show the user inputValue when OnBlur is triggered. https://github.com/strapi/design-system/blob/f05ddc8ccd3c93d44b05357ce667e449071681b1/packages/strapi-design-system/src/NumberInput/NumberInput.js#L151-L157

So, it should be like this I think (this solves the issue)=> const handleBlur = () => { if (!inputValue) { setInputValue(INITIAL_VALUE); } else { setInputValue(inputValue); } }; @gu-stav WDYT ?

[gu-stav]

@INNOVATIVEGAMER What problem are you trying to solve? I believe currently it is impossible to store floats with only zeros as decimals (e.g. 10.000) because a JS Number doesn't store the precision. This leads 10.000 to render as 10 as long as Strapi converts it to a Number type.

[INNOVATIVEGAMER]

Ya, You are absolutely correct

a JS Number doesn't store the precision

We are storing the input as Number only. I am only solving the inconsistent UI/UX for the user. So user sees the number as 3.000 with precision he entered, even though we are storing it as Number in database with value of 3.

Our NumberInput component uses two variables => 1. value (Number) 2. inputValue (string) So I think we should only show to user which presents in inputValue and should not try to reparse value before showing it to the user onBlur.

[INNOVATIVEGAMER]

@gu-stav any comments on the above ?

[derrickmehaffy]

This is possible in v4 by directly modifying the schema: https://docs.strapi.io/dev-docs/backend-customization/models#database-validations-and-settings