I encountered a fascinating bug (or feature) in the lightning:input[type=number] component and I was wondering if any of you have had this problem before?

I'll describe what happens: My lightning component does a server side call and assigns the return value to an attribute in the component. The LC has a few components with their values bound to properties in this attribute. Those properties are numbers (ex 7.95)! The lightning component shows these numbers without issues.

This screenshot shows a part of that attribute printed to the console. The value property is bound to the value attribute in the lightning:input on the right.

enter image description here enter image description here

Now comes the strange part. If I edit one of these numbers and output my attribute to the console, the type of the property that contains the number changes from a number to a string. The numbers I did not change, still have the number type.

enter image description here enter image description here

This results in a very strange behaviour. If I change a value from 7.95 to 8.04 and try to send this back to the server, Salesforce sees this property as a string. It then tries to convert it to a number, but since my locale is nl-be (that uses , as decimal separator) Salesforce just ommits the . and assumes that I wrote 804 instead of 8.04

I made a (dirty) fix that parses all my number fields with the parseFloat(value) function before sending it off to the server and that seems to solve the problem but this seems like an obvious Lightning bug. In my opinion, the lightning:input[type=number] may NEVER return a string.

For reference, this is how i use my lightning:input :

<lightning:input variant="label-hidden" label=" " type="number" min="0" value="{!field.value}" step="0.01"/>

With this as a fix:

value = parseFloat(value);

Is this a known Salesforce Issue or am I doing something wrong?

Edit: Added some more context:

The component I'm making looks like this

The title Pt(dach)Cl2 is what i call a QuoteProduct thats just an aggregation of different QuoteLineItems with the same Product2Id The information to construct this is stored in an attribute with name 'products' and type List

Each QuoteProduct is in its own component

createQuoteLineItems : function(component, event, helper) {
        var quoteLineItems = [];
        var products = component.get('v.products');
        for (var prodIndex = 0; prodIndex < products.length; prodIndex++) {
            var product = products[prodIndex];

            var header = product.table.header;
            var rows = product.table.rows;
            var fields = product.fields;

            for (var rowIndex = 0; rowIndex < rows.length; rowIndex++) {
                var line = rows[rowIndex];
                var qli = line.quoteLineItem;
                var columns = line.columns;

                for (var colIndex = 0; colIndex < columns.length; colIndex++) {
                    var column = columns[colIndex];
                    //The dirty fix
                    if(column.type === 'DOUBLE' || column.type === 'CURRENCY') column.value = parseFloat(column.value);
                    qli[header[colIndex].fieldName] = column.value;

                for (var fieldIndex = 0; fieldIndex < fields.length; fieldIndex++) {
                    var field = fields[fieldIndex];
                    if (field.saveField !== null){
                        //The dirty fix
                        if(field.type === 'DOUBLE' || field.type === 'CURRENCY') field.value = parseFloat(field.value);
                        qli[field.saveField] = field.value;

                qli.sobjectType = 'QuoteLineItem';
        return quoteLineItems;

This is the piece of code that reassembles the QuoteLineItems

It does a component.get to get all the QuoteProducts, loops over them, and for every QuoteLineItem in that QuoteProduct collects the values that are in the fields.

The colIndex for loops over the columns in the table

The fieldIndex for loops over the fields above the table

  • Let us continue this discussion in chat. Dec 6 '18 at 15:03
  • I have this exact same issue and I don't believe I'm doing anything weird with the data to cast it to a string. I have a lot of numeric fields though that I'm constantly reprocessing (only in numeric ways...)
    – erewok
    Mar 1 '19 at 23:53
  • 1
    I made a case and they confirmed this issue. It didn't look like they have any plans on fixing it. The support guy suggested I used an ugly workaround so I ended up making my own component using an ui:inputNumber enriching it with functionality I like from lightning:input like min/max. Mar 3 '19 at 0:15
  • That's too bad. I wrote an ugly hack where I go over my data structure on each input and recast all my numbers using parseFloat before I use them in calculations. It's kind of sad to see this kind of bug.
    – erewok
    Mar 4 '19 at 1:15
  • Thank you for letting me know, by the way. I suspected as much but it's good to see it confirmed.
    – erewok
    Mar 4 '19 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.