Allow user to choose how mouse position is computed in mouse events

[themoritz]

Usage would be:

domEvent (Mousemove RelativeToOffset) el

Drawback is that it breaks usage of Mousemove, Mouseup and Mousedown.

An alternative would be to introduce event types like MousemoveOffset etc. But then it's not clear why Mousemove should yield (e.clientX, e.clientY)...

[ryantrinkle]

I completely agree with the problem you've described here, but I worry about needing to make additional breaking changes in the future to support new use cases. For example, what about modifier keys? I'm not sure it's sustainable to try to foresee what the user might need.

Do you have any thoughts on how we can extend this to a more general interface?

[themoritz]

I totally see your point. I guess if we want to solve the problem once and for all then all mouse related events should return an Event t MouseEvent, where MouseEvent gives me access to whatever aspect of the event I need. Let's assume this datatype is a record like in purescript-halogen. Then I could write the code like

e <- domEvent Mousemove el
let xyOffset = (mouseEventOffsetX &&& mouseEventOffsetY) <$> e

(Similarly, Keydown would yield an Event t KeyboardEvent with the corresponding accessors and so on...)

Ideally, we wouldn't need to recreate the MouseEvent datatype, but instead leverage on the functions that are already in ghcjs-dom by making them available to the user. Let's say we have a monadic fmap for events, then I could for example write

e <- domEvent Mousemove el -- e :: ev, IsMouseEvent ev
xOffset <- fmapM (liftIO . getOffsetX) e

But this is probably less user friendly than the first version

[ryantrinkle]

Yep, I think that might be the way to go eventually! We can't do IO directly when mapping over Events, since that would make Reflex non-deterministic, but the user can use performEvent as necessary.

I think an approach like the purescript-halogen one might be best.

[themoritz]

The diff now shows how the halogen approach might look like. Next step would be to populate the records for the different event result types. Interestingly, for example uiEventScrollTop would not be a property of UIEvent, but we could still expose it in the UIEventResult record.

[themoritz]

Okay, I added the properties that I think make sense. Some remarks:

• I did not include properties that are deprecated, don't make sense in the context, or are not supported by ghcjs-dom. We can always add properties later though.
• I removed scrollTop from UIEvent, because I think it is confusing as a property. Users could use wrapDomEvent to get it. An alternative would be to introduce a ScrollEventResult even if such an interface does not exist in JS, and to collect stuff like scrollTop in there.
• FocusEvent has no useful properties, so I put () as EventResultType. maybe a data FocusEventResult = FocusEventResult would be better?