Skip to content
This repository has been archived by the owner on Oct 4, 2020. It is now read-only.

Parametrise EventListener #24

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zudov
Copy link
Contributor

@zudov zudov commented Sep 10, 2015

Since we provide types for various events (e.g. MessageEvent) it makes sense to have some way of using them in listeners.

Not quite sure, perhaps there is a better solution.

@garyb
Copy link
Member

garyb commented Sep 10, 2015

I had considered this too, but an alternative way: give EventType a phantom type variable.

I've not decided whether it's "too opinionated" to do so yet...

@zudov
Copy link
Contributor Author

zudov commented Sep 10, 2015

It would be nice to have what I've already commited and a phantom type variable to EventType. In that way event listeners would be able to handle arbitrary *Events, and EventTypes would be kept consistent with those *Events, when used with in things like addEventListener. Like so:

addEventListener :: forall eff ev. EventType ev -> EventListener ev (dom :: DOM | eff) -> Boolean -> EventTarget -> Eff (dom :: DOM | eff) Unit

@zudov
Copy link
Contributor Author

zudov commented Sep 10, 2015

Hmm. Looking at the table here
Some "Event Name"s (term used in the table) can have different "Event type"s. For example abort might be used in UIEvent, ProgressEvent or just Event. That means that we can't just say abort :: EventType ProgressEvent. It should be possible to express that table with type classes, but at that point it clearly gets opinionated.

Given that I think we'd have to leave addEventListener as it is without any restriction.

@zudov
Copy link
Contributor Author

zudov commented Sep 10, 2015

As for having EventListener :: * -> # ! -> *, here is an example of how I use it https://github.com/zudov/purescript-websocket-simple/blob/05dd8bdb6e4ca760851e0843040e3567b70feb38/src/WebSocket.purs#L105

@sharkdp
Copy link
Contributor

sharkdp commented Sep 10, 2015

(see also #23 for a workaround)

@zudov
Copy link
Contributor Author

zudov commented Sep 10, 2015

@sharkdp Oh, thanks for that reference. I should have checked existing issues :(

@garyb
Copy link
Member

garyb commented Sep 10, 2015

I don't think you need a class to express it, we'd just put the appropriate EventType smart constructor in a module for that event type.

I'll mock something up this weekend perhaps.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants