With this solution we would have to send the file as text. Our use-case actually requires sending the file up as binary data. (We are integrating with a GraphQL back-end and special behavior is triggered when binary data is present in the post body)
@xtian if you need binary data, you can simply read the file as an array buffer in the port code reader.readAsArrayBuffer(file) and send this array buffer directly in an http request (mdn doc of send). This isn’t elm code, since it’s JS over a port but still does the job.
Looks like there’s at least one library that will do it. Or if you don’t want to add a dependency, just use window.atob() in your port function before passing the value back into Elm, and decode it as whatever you need to (be it a Value or a String). Then you can use Http.stringPart to get the same Http.Part value you get back from your Native helper.
Either way, it may require a bit of massaging to get the data in the right format, but there’s no way that ports won’t work. It’s just a longer/type-safe way of calling the exact same JS function.
EDIT: Isn’t the code that you’re using something like this?
The payload of the Http.Part is a File object. There is no type checking of that value at runtime. The only purpose of the native code is to side-step the type system because there is no blob representation in Elm.