We’re about to release a new bubble version to improve consistency of number inputs, especially across different languages. Specifically, in the new version, inputs with a number format (eg. ‘Decimal’, ‘Integer’, etc.) will now have the type of the “Initial content” property be a number instead of a text. This makes it the same type as “This Input’s value”, and ensures parity with the date and address formats (which already have this property).
The motivation for this change was mainly multilingual apps. If you had an input with initial content of “2.5”, for instance, what number would actually be in the input depended on the language when the input was loaded. In English, it would be 2.5, but in French, it would instead parse as 25 because the decimal separator is a comma, not a period. Now, in the latest version, the initial content would be the number 2.5 instead of the text “2.5”; thus, while it would render as 2.5 in English and 2,5 in French, it would semantically be the same number.
You can upgrade to the latest version in the Settings/Version tab. After upgrade, you should go through all of your number inputs and make sure they have the correct type of initial content. This will ensure these are consistent across various languages your app may support.
Is there a facility in Bubble to search for all inputs that expect numeric values? Is this a matter of reviewing every page of the app visually to determine what inputs require numeric values? Will any errors be surfaced by the issue checking or will these be runtime errors?
You can use the app search tool in the top right to find them. In this case, use “Element Type”, “Input” to find all inputs. To find specific inputs this affects, you can say contains text: number, percentage, or currency - this should find inputs with those formats within your app.
The issue checker should check for type mismatches, which this would be (as a text is trying to be a number). If it doesn’t (sometimes the issue checker doesn’t update right away), the runmode behavior is the same as what is was before; so, even if you upgrade and don’t change any inputs, the behavior will be the same as today.
@cal
Shouldn’t app throw error automatically if there is a type mismatch?
It is not very clear from your message as to what exactly do we need to do. Do we need to check data types of “Initial content”? What to do if it is blank? What to do if it is of a different data type? Surely we can’t change data type in the database?
It would be great if you could take some examples and give clear instructions for dummies like me.
@cal - Is it possible to generate random number instead of random string, Since this breaking change breaks many random generations, which was shown default in the field
I get hundreds of errors with the latest version, but not very clear what I should do here.
Should I turn all “Content format” of Decimal into “Text(numbers only)”?
ha! yeah I’m a couple of days away from a re-launch after having brought an app up to date with v.11. (from v5).
I updated to v.12 and the issue checker lit up like fireworks. quickly rolled back to v.11.
It wanted me to change the actual data type, on the DB data, not the input type, which is not happening. Maybe i misunderstood the error message, but I don’t have time to dig into it more at this point.
FYI: got errors saying my inputs using dynamic expressions for the initial value were displaying a text instead of a number, even though the initial value was actually fetching a number. Just clicked on the dynamic expression of each of those buggy initial value fields and the errors disappeared.
@cal Is there a workaround for when we had an input of type decimal and wanted to format the way the decimal was displayed?
Previously I had things set up to format the initial content as a type number so I could set the number of decimals to be displayed…now this is not possible and I can’t figure a way to make it so that I can limit the number of decimal places displayed.
Since this breaking change removes an ability when the content type is decimal to be formatted to look the way we would want it to look, is it possible to add to the input element for when the content type is decimal to limit the number of decimal places? Basically add in the same functionality of formatting as a number to set how many decimal places we want displayed?
I face the same issues, but the inputs where I used ‘Format as…’ to set the number of decimal places shows an error and did not goes away until I remove the ‘format as …’ part.
how can I set the decimal places of the number? as I used these inputs on my invoices and I need it to be displayed in 100.00 format.
@seham you are facing the same issue I am. I tagged @cal about it…the reason for it is that formatting as a number turns it into a text value…however, with the decimal content type set on the input there is no way currently, and because of the breaking change should be added, to set the number of decimal places displayed.
@boston85719 I have the same issue as you and @seham.
I’m not going to “upgrade” until we have some clarity on this. I’m surprised this wasn’t better thought through, as I suspect this is going to affect many of us.
I wish I had the issue checker show the issues as soon as I had upgraded. The issue checker didn’t report issues until I was on the specific pages in the editor so I had made a bunch of changes in my app before I was eventually alerted to the issues on the specific page…so for me going back in time to undo the ‘upgrade’ is not an option as I’d be losing half a days work.
Hopefully they could easily add in the feature for setting the number of decimal places.
Agree with this 100%. It’s a real pain to open each page to have issue checker rescan.
Issue 1 - Can’t seem to format a field as number with 2 decimals.
Issue 2 - All :count fields need to be reselected as :count for the error to disappear.
Going back to V11 till this is more stable.
