esha / eventi Goto Github PK

This might be as simple as overloading alias() to watch for DOM contexts that aren't eventi.fy'd, then automatically registering the declare.js' listener. Or maybe there should be an Eventi.declare(dom, '...') function?

This will require parser and support code for jQuery-style namespaces, as a base. Beyond that, we can probably just subsume their event system entirely, by replacing $.fn.trigger, $.fn.on, $.fn.off, and $.fn.one, redirecting all events through Eventi. That approach might take a little research to ensure we don't miss other hooks in their event system that people expect/use.

Alternately, we could bridge the systems by wrapping those functions to ensure events fired in jQuery's manual event system are also fired in the DOM/Eventi and vice versa. The duplication is likely more wasteful and will require informing jQuery's Event builder of all of Eventi's custom properties, but it might cause fewer compatibility issues??

My current preference is to just overthrow their system.

This is unlikely to be worth the considerable effort it would probably take to implement (i.e. a complete rewrite of the parsing code). But in those few instances where you are registering multiple, related handlers, it might be nice to do things like:

Eventi.on('group:{type#tag other$1}#tag2', ...);
instead of
Eventi.on('group:type#tag#tag2 group:other#tag2$1', ...);

Just dropping the idea here to keep it in mind...

https://github.com/msemenistyi/capo

For cross-cutting concerns like logging and debugging, it would be convenient to support registering listeners by category (or tag or whatever) alone, without limiting by type.

Eventi.on('group:', function(e) {
  console.log('Group event: '+e.type, e);
});

This will require a) registering the handler for all known types on the target and b) watching all future listener registrations on the target for new types.

This will have the very obvious limitation that it will be entirely unable to intercept event types not otherwise being listened for by Eventi. Thus, we should never allow/imply support for an entirely empty listener definition (i.e. a "catch-all" listener).

This would provide parity with how ... works. It would be a fairly handy shorthand for Event translation, as well as the potentially nifty feature of late resolution of handler functions (which essentially require off/on-again to change at the moment).

It would look like:

Eventi.on('keyup[ctrl-s]', 'service:save');// event translation
Eventi.on('validate', 'App.validate');// function resolution

Currently, the following results in a combo event listener:

Eventi.on({ 'foo bar': fn });

It should be registering the fn as handler for both foo and bar, not foo+bar.

Those needing to handle repeating events like "resize" typically want/should restrict execution. I'm envisioning a syntax like:

Eventi.on('resize%200', ...);// trailing execution
Eventi.on('resize%-200', ...);// leading execution

Should be fairly straightforward to implement via parser and on:handler hooks.