[dojo-contributors] live() and delegate() prototype

James Burke jburke at dojotoolkit.org
Thu Mar 4 19:49:34 EST 2010


If you want to proceed further with the prototype, I suggest putting
it in dojox or dojoc and iterate from there, probably with an
associated ticket. Hopefully you and Sam can compare notes on the
implementation. Some hurdles to getting this further along:

- there is a die() method, to remove a live connection.
- IE has problems with select change events and some focus/blur
things. From what I recall, jQuery ended up doing quite a few hacks to
get that all to work right. To the point that I would probably be
uncomfortable with that amount of hacking being injected into Dojo
Base. Maybe this would never live in base (particularly with closest()
dependency), but we have to decide on the tradeoff on full IE support
vs. just doing something similar. My initial feeling is to just do a
tidy implementation and just document the cases that do not work for
IE.

I like dojo(x).live(), and a .delegate method on dojo.NodeList, but
hopefully we would have a .delegate that works outside the NodeList
context. This is tricky on naming given the existence of
dojo.delegate() for object delegation. I like how you did not put a
.live() method on dojo.NodeList, as it is not a dojo.NodeList
operation.

To make this code fast, I support doing some fast pathing to
_filterQueryResult where the selectors are simple ones that it
supports for .closest() and/or its supporting infrastructure.

James

On Thu, Feb 25, 2010 at 11:19 PM, Bill Keese <bill at dojotoolkit.org> wrote:
>
>> We have closest() in NodeList-traverse.
>>
> Ah, cool, I didn't realize that was there.
>
> I checked over our closest() code, and ISTM the biggest issue is that
> even for trivial filters, like closest("div"), it's calling dojo.query()
> repeatedly, and dojo.query() is scanning the entire document.   That
> problem can be lessened by modifying the closest()'s code to call
> dojo._filterQueryResult() instead of self._filterQueryResult() when the
> query is simple (presumably non-hierarchical).
>
> Alternately, Sizzle.matches( String selector, Array<DOMElement> set ),
> which is the same functionality as self._filterQueryResult(), already
> has a fast path for simple selectors.   So that's another option.
>
>>
>> [jQuery] also has a $.live("a", "onclick", fn), much like our own pattern
>> of node/nodelist.  IIRC, this is why delegate() was added, and $.live
>> recommended (for the same lazy-nodelist reasons).
>>
> Ah OK, thanks.   I can't find any doc in http://api.jquery.com/live/ for
> this a $.live("a", "onclick", fn) method signature, but it sounds the
> same as:
>
>    $("body").delegate("a", "onclick", fn)
>
>
>
> Anyway, I've implemented prototypes of both a dojo.live() function and a
> dojo.NodeList.delegate() method.   To monitor clicks on all <a> nodes in
> the document you'd do:
>
>    dojo.live("onclick", "a", function(){ ... })
>
> And to only monitor clicks for <a> nodes inside of .navigation <div> nodes:
>
>    dojo.query(".navigation").delegate("onclick", "a", fn)
>
> See http://bill.dojotoolkit.org/trunk/dojo/tests/live.html and
> http://bill.dojotoolkit.org/trunk/dojo/tests/delegate.html for the
> prototype code I wrote.  I guess it's similar to Sam's code.  It doesn't
> have the fancy caching that Dustin's code has.   Caching would be good
> to add but I think the main thing is getting closest() to run in O(1)
> time for simple selectors (and bonus points for getting it to run in
> O(log N) time for complex selectors).   Note that my prototype doesn't
> properly fix the closest() performance problem either.
>
>
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>


More information about the dojo-contributors mailing list