Closed martindemello closed 1 year ago
Thanks for the contribution, and sorry for the long silence.
I'm indeed reluctant to have vdom.ml referring to JS stuff. The idea is to keep vdom.ml as "pure" as possible, so that it could somehow be executed in a non-JS context (server-side, web-assembly, etc). I don't have an alternative to propose right now, unfortunately...
What about wrapping the whole logic "file-input + filereader" in a Custom element that synthesizes an input or change event with the file's content? (This does not cover all use cases of file inputs, of course.)
do you have an example of something along those lines? i'm not too clear on where the custom element would be defined, and at what point the file's content would be read.
inspired by what the lablgtk folk have done for gtk3 support, how would you feel about pushing this to a separate web
branch and publishing that as a separate opam project? it could be merged back if anyone comes up with a nice idea for how to do it cleanly, and in the mean time it would be easy to just add js apis as needed without interfering with master.
It took a bit of time, but we have extended ocaml-vdom to support defining arbitrary decoders on DOM events, which makes it possible to work with files inputs directly. This is currently in our in-house version, and we are planning to bring the public version up-to-date soon enough.
unfortunately, this refers to Js_browser.File.t within vdom.ml, since we need the list of File objects from the event.target to pass to the FileReader. i wasn't familiar enough with gen_js_api to see if i could serialise File.t into a file_event record and then reconstruct the File.t when calling FileReader