CODEWITHSUNDEEP
javascriptjqueryjquery-events
Andreas Andreou
Andreas Andreou

Reputation: 848

Removing listeners with JQuery? Should or should not?

I am building a web page and I have started using JQuery and I use it a lot with listeners (keyup, focusin, focusout ...)

I have a question though about the way they are stored.

One of the pages I have has dynamic content in that the user chooses a date and a PHP script returns a bunch of data in tables. On those tables I have a JavaScript function that when pressing a cell an area opens where I load it with the html code of a form. This form is the same for every cell, it just changes times and dates depending on the cell pressed. My solution was that this html was written by using the JavaScript function mentioned.

On that form now when some events are triggered I assign a listener i.e.

function livesearch(el, about, event) {
    if ( event.keyCode < 96 || event.keyCode > 105 ) {
        return;
    }
    
    var keyword = el.value;
    
    $(el).focusout(function() {
        $('#livesearch_results1').html('');
        $('#livesearch_results2').html('');
    });
...
}

It works but I was wondering about the correctness. Do these listeners stack up each time a new form is created... do they overwrite each other (because the form is generated by the same JavaScript for every cell so the id's are the same)?

Upvotes: 0

Views: 91

Answers (1)

Khanh TO
Khanh TO

Reputation: 48972

Use delegate event: $.on

Examples:

$("body").on("focusout","yourelement",function(){
});

$("body").on("focusin","yourelement",function(){
});

Under Direct and delegated events section in the link I posted. You will see:

Event handlers are bound only to the currently selected elements; they must exist on the page at the time your code makes the call to .on(). To ensure the elements are present and can be selected, perform event binding inside a document ready handler for elements that are in the HTML markup on the page. If new HTML is being injected into the page, select the elements and attach event handlers after the new HTML is placed into the page. Or, use delegated events to attach an event handler, as described next.

Delegated events have the advantage that they can process events from descendant elements that are added to the document at a later time. By picking an element that is guaranteed to be present at the time the delegated event handler is attached, you can use delegated events to avoid the need to frequently attach and remove event handlers. This element could be the container element of a view in a Model-View-Controller design, for example, or document if the event handler wants to monitor all bubbling events in the document. The document element is available in the head of the document before loading any other HTML, so it is safe to attach events there without waiting for the document to be ready.

In addition to their ability to handle events on descendant elements not yet created, another advantage of delegated events is their potential for much lower overhead when many elements must be monitored. On a data table with 1,000 rows in its tbody, this example attaches a handler to 1,000 elements:

I think I should not explain the benefits again in this post. The documentation explains very clearly.

Upvotes: 2

Related Questions