elm
Multiple event handlers with the same key
Given this code, it seems as though if you supply multiple event handlers with the same key in a list of properties, all but one will be clobbered.
https://github.com/elm-lang/virtual-dom/blob/master/src/Native/VirtualDom.js#L130-L135
if (key === ATTR_KEY || key === ATTR_NS_KEY || key === EVENT_KEY)
{
var subFacts = facts[key] || {};
subFacts[entry.realKey] = entry.value;
facts[key] = subFacts;
}
In theory, it would seem possible to do something sensible with multiple event handlers -- i.e. install each of them.
Now, it is, of course, possible -- and, indeed, often preferable -- for the event handlers to be "combined" at a higher level, and provided to VirtualDom as a single handler. So, if the intention is to force that to happen, then this would not be a bug.
Just adding another use case where we ran into this.
Our application at work is organised in two layers. There is the Base layer which provides a consistent design system as well as SPA style routing. On top of this is a number of individual applications that use this Base layer to build actual functionality. This architecture works very well for us, since most day-to-day app development is at a very high level of abstraction.
On of the features of the Base layer is that it models the view as a custom type type View msg = LayoutContainer | Button | Typography | ..., which is basically what the applications use. The base layer than translates this custom type to Html.
This allows the Base layer to abstract away a significant number of finicky details of HTML (especially nice are some of the non-local properties of HTML like the necessity of globally unique ids,etc. enabling much easier composition).
Recently we wanted to add a feature to the base layer that allows the Base layer to send itself it's own Msg type from buttons, but potentially allow the application to also send itself those buttons. This would be easily solved with simply attaching multiple onClick event handlers. Trying to get our types to align in an alternative solution is either not possible or not worth the large complexity it would entail (honestly, I didn't even want to try).
