Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand events tutorials to cover cases where bound elements are removed and re-added. #624

Open
robertmaxrees opened this issue Jan 26, 2015 · 4 comments

Comments

@robertmaxrees
Copy link

Originally filed in jquery/api.jquery.com#632.

There seems to be pretty regular confusion surrounding the notion that event bindings break if the element you bound to was removed from the document (via, say, .remove()) and then re-added (like when you create a new element with $()).

The specific issue is that people think that simply using a delegated listener is enough - e.g.:

$('.someDiv').on('click', '.someChild', function() {
    $('.someDiv').remove();
});

They then later re-add $('.someDiv') and expect this to work because the handler is technically bound to an element that exists at the time of binding - it just happened to be removed and re-added.

The .remove() docs helpfully explain that:

In addition to the elements themselves, all bound events and jQuery data associated with the elements are removed. To remove the elements without removing data and events, use .detach() instead.

This is fine, except that a lot of people aren't going to think to go to docs for .remove() while reading about events. This also doesn't cover cases where somebody ran something like .html('<span>no cookie for you</span>') on a parent of the bound node, wiping it out.

@arthurvr
Copy link
Member

I'm not sure where this explanation would need to be. We don't have a specific section on removing/detaching elements. I don't think this is appropriate in the pages regarding events, many people will be reading those without even knowing what removing/detaching elements actually means.

@devs4v
Copy link

devs4v commented Mar 17, 2015

I think the above comment by @robertmaxrees could still be added as a sidenote of somekind at the end of the page that explains the events. Because it's something to be aware about. According to the documentation flow at the learning center does follow a path where you would encounter the above documentation about remove() and detach() before the portion that explains events, but it is highly unlikely that people would follow that path. Moreover, if both these notes are on the same page then it is highly likely that search engines would pull up this needed piece of information at the top of search results for someone who is confused about why her events aren't triggering anymore.

@arthurvr
Copy link
Member

arthurvr commented Apr 1, 2015

Because it's something to be aware about.

👍 Sure.

I think the above comment by @robertmaxrees could still be added as a sidenote of somekind at the end of the page that explains the events.

Sure. I wasn't saying it shouldn't be added somewhere, just wondering where's the best place.

@devs4v
Copy link

devs4v commented Apr 1, 2015

Yeah! That's what I mean. Perhaps the end of the page as a note would be a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants