search

melange-community / melange-webapi

Melange bindings to the DOM and other Web APIs
MIT License
15 stars 6 forks source link

Missing web worker related API #18

Open tonyfettes opened 2 weeks ago

tonyfettes commented 2 weeks ago

Hi, I'm using melange for a academic project. I want to put all computation inside a worker so it doesn't froze the page. However, there is currently no support for web worker (yet?) in melange-webapi.

I have learned how to bind to JS using melange by developing the very same project, so I think I want to try to add these bindings myself. As per the contribution guidelines, I open a issue here to potentially save some work.

There is no discussion section in this repo so I might post some questions below as well to seek help & for record.

davesnx commented 1 week ago

Totally @tonyfettes. Feel free to push a PR or even a draft and ping me.

tonyfettes commented 1 week ago

@davesnx I created a (actually two) draft PRs. Here are some questions I have in my mind after some initial attempts.

  1. Technically worker is not part of the DOM API. Although I put them in the DOM folder, I think I should move them out of the Dom/ folder. However, I see fetch API is in its own standalone package. Why some APIs are kept here while others are separated out (like fetch) as standalone packages. Should I make worker APIs a package?

  2. How can I test for the correctness of my binding? I browsed the tests/ directory, but since no typical OCaml test frameworks are used (like ounit, alcotest, and expect_test), how does the tests work?

  3. Do I really need to modify the compiler? I add some type definitions in the jscomp/others/dom.ml and they're purely abstract type definitions. My hypothesis is they can also work if I move all these type definitions in this repo as a file, but I'm really not sure.

Thank you in advance.

davesnx commented 1 week ago

Nice,

  1. Historical reasons I would say. Since bindings have some subjective design, sometimes authors have diverged implementations. In case of fetch, could be part of this repo IMO.

  2. Testing the browser isn't as easy as running alcotest or ounit. You would need to either run a browser (via puppetter) or a JavaScript test suit (probably jest with a bit of config to support webworkers) or manually with a demo.

  3. Some types are abstract and inside the compiler to allow any library to extend bindings/libraries with those types. Either way, if you think the types are correct, I would push them to melange itself.

anmonteiro commented 6 days ago

In case of fetch, could be part of this repo IMO.

I disagree. fetch is way more useful by itself than this repo (which I've never used, though I use melange-fetch everywhere)

davesnx commented 3 days ago

Maybe you didn't need webapi?

At least I would say re_exporting fetch in webapi make sense

anmonteiro commented 3 days ago

Maybe you didn't need webapi?

Oh I did, but this library is a bit of an overkill if you just need a few externals that are easy to write