Skip to content

Should MessagePort, MessageEvent and Transferrable be in their own module? #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JordanMartinez opened this issue Jan 12, 2023 · 6 comments

Comments

@JordanMartinez
Copy link
Contributor

Transferrable is currently problematic as its a placeholder for a better solution, but I think the other two should be in their own module.

@gbagan
Copy link
Collaborator

gbagan commented Jan 12, 2023

Yes. It seems a good idea.
purescript-web-sockets also uses MessageEvent.

@JordanMartinez
Copy link
Contributor Author

If that's where that type should be defined, then we should depend on that library rather than redefining it here.

@gbagan
Copy link
Collaborator

gbagan commented Jan 13, 2023

Why not, but ports and source are not defined here.

@JordanMartinez
Copy link
Contributor Author

MessageEvent is not defined in the WebSockets spec either. They probably did the same thing we did here: define it locally so one can use it.

@gbagan
Copy link
Collaborator

gbagan commented Jan 14, 2023

If I understood correctly, we can:

create a repository for both MessagePort and MessageEvent since there are mutually dependent.
Put IsSendable in this repo.
Maybe, change web-sockets such that it depends on this repo but reexports the functions of MessageEvent such that we don't introduce a breaking change.
MessageEvent.source returns an opaque type MessageEventSource and there is a function

toMessagePort :: MessageEventSource -> Maybe MessagePort

What do you think?

@JordanMartinez
Copy link
Contributor Author

Per the html spec that includes MessageEvent, I think the code should live in web-html.

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

No branches or pull requests

2 participants