EventListener is limiting

[hexops]

EventListener is limiting

[dave]

Seconded... Exposing the raw event object would make things more flexible... Exposing these as methods on the handler is neat, but it always struck me as a bit weird. In fact, the first time I needed to use preventDefault, I spent quite a while scratching my head and referring to examples before I worked it out. It's a lot more familiar to call it within the event handler, and not being able to call it conditionally is an important omission.

p.s. We recently fixed this to expose stopPropagation in the same way as preventDefault.

[neelance]

The initial idea for that preventDefault implementation was to be able to automatically call the event listener in a new goroutine to allow blocking code by adding a go statement here: https://github.com/gopherjs/vecty/blob/master/dom.go#L97. This may not be the best solution.

Keep in mind that React still sees a reason for adding an abstraction on the native event: https://facebook.github.io/react/docs/events.html This might be especially necessary when we add event pooling for performance.

[slimsag]

From @davelondon

In order to do a drag+drop file upload, you need access to dataTransfer from the js event. The js native event object isn't currently presented to the vecty event handler. I've added this in my fork as an anonymous struct member, and it seems to feel good in use:

https://github.com/davelondon/uploader/blob/master/editor.go#L133

I seem to remember this was discussed before?

From @shurcooL

need access to dataTransfer from the js event. The js native event object isn't currently presented to the vecty event handler.

Just asking, but have you considered simply filling that gap and exposing dataTransfer natively?

From @slimsag

I think this is a duplicate or related to #55

I agree it is limiting, and the best choice for now is probably to expose the native event object. Although in #55 neelance does make some good points about event pooling in the future.. I'm not sure yet.

@shurcooL there are so many DOM event properties I think it would be a bit crazy to add them all :P

[slimsag]

From React's event documentation it seems like the main reason they use synthetic events is to standardize how events act across browsers. That actually feels a bit strange to do IMO, but I do not know all the details I suppose.

They too, also expose the native event:

If you find that you need the underlying browser event for some reason, simply use the nativeEvent attribute to get it.

And event pooling appears to just be for purposes of not creating the same JS object over and over again (something that could be achieved by simply using the event object the browser gives us).

I think they might do more behind the scenes to improve event performance, but I think for now it is OK for us to expose native event objects.