Add DOM event to arguments hash of triggers

[Ulexus]

Adds e to the args hash of the triggerEvents function for each element
in the triggers hash. This allows triggers to be used as an upgrade for
events

e may not be the best name, but I figured event may be confusing.

[mxriverlynn]

Hi @Ulexus,

TL;DR: I'm going to say no to this because it would break encapsulation of the DOM. If you need to manipulate the event args, you should be using a DOM event handler in the view directly and not using the triggers feature.

The long version:

This change would break the intent of view triggers by breaking encapsulation of the views. The purpose of the triggers is to be a convenience method to allow an object other than the view to process the workflow that is needed, by triggering an event from the view and having the other object catch that event. Typically, no logic is needed in the event handler, related to the view or the DOM. In this case, the triggers work well to avoid three or four lines of boilerplate code.

In cases where someone would need to use the DOM event args, though, that still needs to be handled in the View because the View is the only object that should know about the DOM manipulation and event data. To pass the "e" event args out of the view, through the triggered event, would break the encapsulation of the view owning the DOM references and manipulation.

Of course we can make the argument that the same thing can happen with the existing parameters that are passed through - and that's true. You could get to the view through the args, and then to the DOM through that. But that extra level of indirection creates a very intentional path that you must willingly choose to go through. There are cases when it makes sense to manipulate the view directly from the object that receives the event. In those cases, it's up to us the developer to not break the DOM encapsulation, by calling view methods that still wrap the DOM manipulation. If we were to add the "e" event args, though, we would be forcefully breaking that encapsulation by handing the DOM information to the external object.

Hope that makes sense. If not, let me know and I can clarify / answer any questions you have.

[Ulexus]

That makes sense; I wasn't looking at it from the manipulation perspective... it was just a simple way to pull the attributes of the calling element so I could collapse a bunch of discrete definitions into classes.

I do appreciate the time-intensive explanation; thanks!