Add documentation on how to support multiple actions/events on a single element

[myartsev]

Per #2900

[yawboakye]

As @locks mentioned, we're in favor of <a onclick={{action 'handleClick'}} onmouseenter={{action 'handleMouseEnter'}} ...></a>. Change to this style and it will be 👍 to merge.

[myartsev]

Yes, but as I already mention in #2900, I am a little confused on the style; here you guys say that this is the preferred way but the official guides say otherwise. Which one is it? :)

[locks]

That's not quite what I was saying :P Using actions and using event handlers have different semantics, which developers using them should be aware.

[locks]

I'd rather make this a component and use the component event handlers, seems less messy and binding multiple actions to a single element, but that may be me.

[myartsev]

Sorry - what were you saying? :P
What you said in the linked bug and what @yawboakye said here appear to be in agreement.

I also agree that actions and event handlers are different, but don't understand why in this case event handlers would be preferred.

As for making this a component, I think that's just a different scenario for which documentation already exists, including multiple actions.
Just because you have a need to handle multiple events on an element is not enough justification in itself to make that element into a component IMO. Think of it this way: you have a component in which you have multiple DOM elements. One of these elements needs to do something on mouse enter, and something else on mouse leave, that's it, you are not using it anywhere else; would you rather create yet another component to do just that for that one element, or would you use action/event handlers?

I created this issue was specifically around supporting multiple actions on a single element, as official documentation was lacking and the interwebs had a large amount of outdated information on the topic. Other people were interested too, so I figured maybe the docs could use an update on the subject.

[jenweber]

Would it make sense to describe both options, onclick={{action 'something'}} and on="click"? I find actions can be a little confusing because there are so many different ways to call them. Might be nice to show them together.

[yawboakye]

@jenweber I don't think we should teach both. We're moving towards the DOM's native event handling mechanism i.e. onclick={{action 'something'}}. The technical difference between that and Ember's own event management is huge, and we should probably recommend the DOM's over Ember's.

[jenweber]

Although native event handling seems to be the most popular lately, I'm not aware of plans to deprecate other action handling methods.

I thought about this a little more, and given that the rest of this section of the guides uses the on="click" type syntax, my recommendation is to keep this PR as-is. A follow up Issue could propose updating all examples to be the other format.

I like showing how to handle multiple actions, no matter what, and I think it's worth including in the Guides.

[wycats]

We need to sort out the path forward for declarative event handlers, especially as we move towards Glimmer components with angle bracket invocation style.

The general sentiment of the core team in previous discussions is that the best path forward for event handlers is to create a new element modifier, perhaps something like this:

<a {{on click=(action "select") mouseEnter=(action 'foo') mouseLeave=(action 'bar')>{{post.title}}</a>

The semantics would be to create event listeners on the element, not set the DOM property.

This would work in many contexts:

• <a>, <div>, <video>, etc.
• <some-web-component> (using addEventListener is compatible with custom element styles in the wild)
• <GlimmerComponents> (the event handlers would be installed on the main element of the component if present)

Relatedly, this also eliminates the most common case where people feel as though attribute syntax ought to set a property, and we would like to migrate attribute syntax to reliably refer to setting attributes in the future (for simplicity, consistency, and because it's necessary for good behavior when doing server-side rendering).

In the interim, the cat is out of the bag on stuff like click= and any modifier-based solution will require a transition period and likely a codemod, so there's no reason to strongly discourage the use of that notation at the moment.

Is someone on this thread motivated to write up an RFC for an event-listener modifier?