Unbinding should be internalized about jwerty HOT 6 CLOSED

It doesn't sound like it's necessary in your use case, you could just change what your onUpKey and onDownKey callbacks do according to an external variable, no?

Anyway, it should be implemented. If the _context objects you're referring to are as the return values of jwerty.event, it'd be a one line patch.

If, however, you want the _context objects to be the callbacks, or the context the callbacks are to be called in, or a pair of both of them, we would need a way of storing a mapping from (keycode, _context) to the binding object. There are a few ways of accomplishing this.

• We could use es6 maps but this would not work on ie10-, so no we couldn't really use es6 maps.
• Or we could store the binding object in _context as .jwerty_binding or something. Not pretty, especially considering we want to maintain a mapping from (callback, context), but instead we have to pick just one and find a way to work with that.

from jwerty.

Since I'm actually mapping about a dozen keys, I don't feel that flags are elegant. They just don't fit the general case.

The _context in this case is the keyboard context (DOM selector). I simply imagined that we would have a compound dictionary key made up of the key combination and the keyboard context. For example, we wouldn't want to accidentally unbind all up keys, perhaps just the up key in a particular keyboard context.

Thinking out loud, I'm seeing a dictionary that might look like this:

[ { { key: keyCombo: 'up', selector: '#someDiv'}, subscription: h } }, 
  {...}, 
  {...}
];

Does that make sense?

from jwerty.

If and only if you mean

{
  ['up', '#somediv']: subscription
  ['down', '#somediv']: othersubscription
  ...
}

Though we'd probably store the keys as concatenations of the keycode and the selector rather than an array.

'Fraid that may not be be enough of-popular-interest to land a place on @keithamus's 1.5kb arc?

from jwerty.

If jwerty were to keep a mapping of bound keys, that could cause memory leaks which would be trivial to surface, take for example the following:

jwerty.key('↓', function () {...}, '#myList');
// later on on the code;
$('#myList').remove();

By removing the element, but not clearing up the internal jwerty key binding, jwerty now has a reference to a key binding on a dom element that doesnt exist, but doesn't know about it - therefore a memory leak. The only way around this, to my knowledge, is if we added DOM mutation handlers to every element we bind to - but this is not compatible with lots of browsers and is way too heavyweight.

Currently where jwerty returns an unbind function makes good sense, because there are no references stored in jwerty, it just passes the unbind function - which you have to manage yourself via your own classes, where you have much better knowledge of the application logic than jwerty does.

from jwerty.

O.K., then. I withdraw my request. I will simply build management around the subscriptions.

Thank you.

from jwerty.

Thanks @estaylorco. Sorry that jwerty can't help you here. If anyone can come up with an idea that wont cause memory leaks, I'll be all ears 😄.

from jwerty.