I have used jQuery to detect changes in a textbox in a lightning component.I am able to detect the change first time it loads the library.But when I switch to a different tab and comes back in, it doesn't detect the change.Could anyone please advise why it is happening like that

    <ltng:require scripts="/resource/jQuery/jquery-1.11.3.min.js" afterScriptsLoaded="{!c.setListener}"/>           
    <input type="text" style="width:90%"  placeholder="Username" id="searchBox"/>   

    <!--Client Side Controller-->
    setListener: function(component, event, helper) {
        $("#searchBox").keyup(function (e) {
            console.log('Key is pressed');
  • can you please post full code so that we can take a look?what do you mean by switching tabs Jun 4, 2015 at 1:21
  • Mohith, I have created a component with above code and included it in another component that implements force:appHostable. I have created a tab for that component and added it in Salesforce1 navigation menu.By switching tabs I mean,I have opened the lightning component tab I created for this and navigated to another tab in Salesforce1 menu and came back into Lightning component tab again.First time when I open Lightning component tab, keypress event is detected whereas when I come back to the tab after visiting another tab, keypress event is not being detected.Hope I am not confusing you more
    – Suneel
    Jun 4, 2015 at 2:34

1 Answer 1


It's a timing issue where the first call to setListener happens to run late enough (after your component has rendered to the dom) - the first time only - the second (nth really) time ltng:require has already loaded jquery (remember you are running in a single page app architecture) and your afterScriptsLoaded action fires immediately but before #searchbox exists in the dom.

I've run into this myself (I'm also the author of ltng:require) and am looking at changing ltng:require to have it insure the same lifecycle timing so this will not happen.

With that said using jquery for this is overkill. Also the use of dom ID based locators is not only not required it's going to break when you have more than one instance of your component anywhere in the dom. You can easily let lightning wire up the event handler and it will take care of all of the lifecycle stuff automatically and not have the dom ID collision issue either.

<input type="text" style="width:90%" placeholder="Username" onkeyup="{!c.onkeyup}"/> 

and in your controller.js:

    onkeyup: function(component, event, helper) {
        console.log('Key is pressed');

You can even do better than this by using the higher level ui:inputText component and get free placeholder and bidirectional data binding support for free:


<ui:inputText placeholder="Username" updateOn="keyup" keyup="{!c.onkeyup}" aura:id="search"/>   

onkeyup: function(component, event, helper) {
    console.log("Key is pressed: " + component.find("search").get("v.value"));
  • 1
    BTW its not that you can't use jQuery and other libraries/frameworks with Lightning Components but it is important to evaluate the return on investment. LC solves many issues specific to component based architectures that other libraries just do not worry about. Also any time you combine multiple frameworks you increase the bulk, complexity, unintentional interaction potential, and so much more. Add to that the multi author, mutli org, push upgrade in the cloud etc and things get challenging. This is what LC is designed to address. Jun 4, 2015 at 11:26

You must log in to answer this question.

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