use addEventListener to allow { handleEvent }

[serapath]

to "fix" #103

I can see the unconvenience, that this PR removes the ability to remove the listener later.

If this is unwanted, maybe val can be checked and addEventListener would only be used if val is an object and not a function. Maybe in case of object, it could be assigned to el.on[event.type] too, so later it's possible to call el.removeEventListener('click', el.onclick) which a user would need to do before overwriting el.onclick with a custom handler.

[bcomnes]

How does addEventListener differ from setting the handler as an attribute? Does the eventListener get removed when the dom node is discarded like it is with attribute handlers?

[serapath]

For some reason, it seems, the { handleEvent } thing only works when addEventListener is used, but if an object is assigned like el.onclick = { handleEvent }, it doesn't do anything.

[bcomnes]

Do these get garbage collected the same way attribute assignments work? The only issue I see is if these have a different GC characteristic.

[bcomnes]

Otherwise, I think supporting this would be better.

FWIW, in the meantime, I've been using fast-on-load hooks to add event listeners this way if needed.

[bcomnes]

Oh wait, these questions were addressed, and yes this does seem to work.

[bcomnes]

Going to close this since its stale. Open to a discussion but for now that seems best.

Thoughts: we support attributes in nanohtml. Trying to pretend addEventListener is an attribute listener is adding complexity. You should manage node related listeners in your on-load events, so that they aren't firing when the node is out of the page to begin with, which is the perfect place to add these types of listeners.