2

I have a simple Lightning attribute of type Object with key value as array. I am attaching value from array to input element and expecting auto-binding to work but it is not.

I may be missing something basic here. Here is a simple reproducible version of the problem I am facing.

HelloWorldApp.app

<aura:application extends="force:slds">
    <aura:handler name="init" value="{!this}" action="{!c.doInit}" />

    <aura:attribute name="dataMap" type="Object"/>

    <div style="max-width : 10%">
        <aura:iteration items="{! v.dataMap.firstLevelArray}" var="iterator">
            <input  class="slds-input" 
                    value="{! iterator.val}" 
                    type="number"
                    onchange="{!c.valChanged}"/> 
        </aura:iteration>
    </div>

</aura:application>

HelloWorldAppController.js:

({
    doInit: function(component,event,helper){
        var dataMap = {};
        dataMap['firstLevelArray'] = [];
        dataMap['firstLevelArray'].push({ 'val' : 10 });
        component.set('v.dataMap',dataMap);     
    },
    valChanged :function(component,event,helper) {
        console.log(component.get("v.dataMap")['firstLevelArray'][0]['val']);
        // The above line is always printing 10
    }   
})

As we can see in the video, it is always printing 10 and looks like it is not properly bound.

enter image description here

NOTE: I have gone through this article and it says avoid using attribute of type Object but use Map. I have done the same but no change in output.

EDIT: The reason for me to use input tag instead of lightning:input is data attributes. lightning namespace elements don't allow data attributes.

2
  • Isn't that expected? You have the key val set to the value of 10. So anytime you get that key, wouldn't it print 10?
    – Jayant Das
    Commented Sep 12, 2018 at 1:34
  • But I am attaching val to input element, shouldn't it change when I change value in input element?
    – javanoob
    Commented Sep 12, 2018 at 1:35

1 Answer 1

2

The problem actually happens to be that binding to input value doesn't appear to work correctly. Using a lightning input component does appear to work correctly. Here's a working version:

<aura:application extends="force:slds">
    <aura:handler name="init" value="{!this}" action="{!c.doInit}" />

    <aura:attribute name="dataMap" type="Object"/>

    <div style="max-width : 10%">
        <aura:iteration items="{! v.dataMap.firstLevelArray}" var="iterator">
            <lightning:input label="Demo" 
                             class="slds-input" 
                    value="{! iterator.val}" 
                    type="number"
                    onchange="{!c.valChanged}"/> 
        </aura:iteration>
    </div>

</aura:application>

I'm going to do a bit more research on this, but for now, it appears that the normal input field has problems binding value correctly.

6
  • 1
    @javanoob And thank you! I love debugging issues like this.
    – sfdcfox
    Commented Sep 12, 2018 at 2:07
  • I may be missing something here but I find this interesting, because I am seeing that if you use the original map and the key in your JS function, you always get the value as in the map for that key. Can you also provide your valChanged. I am curious to see how it works.
    – Jayant Das
    Commented Sep 12, 2018 at 2:08
  • To add, if I use console.log(component.get("v.dataMap")['firstLevelArray'][0]['val']); I expect this to print 10 always, and this is what I observe. And because I am actually printing the value from the map instead of the value from the input element. Am I missing something here?
    – Jayant Das
    Commented Sep 12, 2018 at 2:11
  • @JayantDas Yes, {!...} creates a two-way binding. This means that changing the input's value should change the datamap, and changing the datamap should change the input's value. My valChanged is identical to the original question, only the input was changed to lightning:input and a label added because it is required.
    – sfdcfox
    Commented Sep 12, 2018 at 2:16
  • @sfdcfox - Thanks, I should have known that. I was for some reason stuck at the JS function instead. And the reason I saw the behavior because of caching issue. I updated it to use lightning:input, cleared my cache and it works as expected. But that's right not with input.
    – Jayant Das
    Commented Sep 12, 2018 at 2:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .