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

Recursive Unbind #29

Open
ryneeverett opened this issue May 13, 2015 · 8 comments
Open

Recursive Unbind #29

ryneeverett opened this issue May 13, 2015 · 8 comments

Comments

@ryneeverett
Copy link
Contributor

This is a proposal for an unbindArrive option:

$(document).unbindArrive(".test-elem", {recursive: true}, callbackFunc);

which would remove all bindings to document and it's children (meeting the selector/handler criteria).

@uzairfarooq
Copy link
Owner

What's the use case? If we implement this, it's going to be a bit expensive, it'll require to traverse from every registered node upto the parent. Better avoid it if it does not add much value.

@ryneeverett
Copy link
Contributor Author

My use case is a less error-prone way of removing all handlers from the entire document, but I could see where it could be useful for other elements.

I didn't think traversing would be necessary. Wouldn't it be possible to iterate over the EventsBucket and check if each handler is a child of the selector?

My thinking is that in order to remove handlers from all (or a subset) of the DOM you need to keep track of the state of your handlers. Arrive is already keeping track of the state of your handlers so you shouldn't have to keep track of it separately. I guess another idea would be to just expose the state with a separate method like:

$('body').getArriveHandlers()
[<div class='.test-elem'></div>, <div class='.another-test-elem'></div>]

One could then iterate over them to remove them, but that method may have broader applications as well.

@ryneeverett
Copy link
Contributor Author

Oh, I didn't carefully read your comment.

it'll require to traverse from every registered node up to the parent

You're saying that even iterating over the EventsBucket we'd still have to traverse all the way up the tree to find out if it's a child.

@ryneeverett
Copy link
Contributor Author

It seems like it would depend on the application whether the tradeoff is worth it -- the one-time cost of this traversal vs the cost of lingering handlers.

@uzairfarooq
Copy link
Owner

The one time cost is not much big of an issue here. The point that concerns me most is that if the use cases are common enough? Just don't want to add feature that are not used enough (they just increase size of library and don't add much value).

I use the library often but never felt the need for this. Lets see if someone is looking for the same feature.

@uzairfarooq
Copy link
Owner

I think we don't need to traverse, the matches function will serve the purpose. We already have a helper method for it utils.matchesSelector in arrive.js.

@uzairfarooq
Copy link
Owner

Hmm...no. It isn't useful in this case, we don't have a selector to match it against :)

@ryneeverett
Copy link
Contributor Author

Lets see if someone is looking for the same feature.

Agreed.

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

No branches or pull requests

2 participants