Well, I thought maybe I could make it work when I found this function which basically decodes the event.target.files[0] into a Value. The MIME type should also be available by decoding the type property off of this.
However, the only way to convert a Value into a Http.Body type currently thru Elm is with jsonBody. And when I traced that all the way down, it is going to fail to work for 2 reasons. First, jsonBody sets the MIME type to "application/json" always. Even if you set the content type in a header, StringBody's content type is evaluated last so it will probably overwrite or concatenate whatever else you set with "application/json". (This is a problem for my use case anyway.) Second, jsonBody calls Encode.encode on the Value which calls JSON.stringify in javascript. In my quick search, this will neither stringify the file contents nor keep the JS File object in tact. So it will not upload the file.
So, nevermind. I still need to do it with native code (edit: or a port to Javascript) currently.
Encode.encode is another story. JSON.stringify could be monkey patched to return File objects unmodified, but encode is actually JSON.stringify(...) + '' (since 0.19), so even if stringify preserves the file, encode will still return an "[object File]" string because of type coercion.
Anyway, using a port with readAsDataURL and uploading base64 encoded files is not so bad, are the overhead and server decoding really an issue for you?
Anyway, using a port with readAsDataURL and uploading base64 encoded files is not so bad, are the overhead and server decoding really an issue for you?
Nah. At the time I couldn't find a succinct example with the FileReader stuff. The one I found still used native code and also had a lot of extra abstractions to wade through. So it was quicker to just do what I did. But I'm not married to it. I did find a pretty clear port solution with FileReader that I would use now.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, I thought maybe I could make it work when I found this function which basically decodes the
event.target.files[0]
into aValue
. The MIME type should also be available by decoding thetype
property off of this.However, the only way to convert a
Value
into a Http.Body type currently thru Elm is withjsonBody
. And when I traced that all the way down, it is going to fail to work for 2 reasons. First,jsonBody
sets the MIME type to "application/json" always. Even if you set the content type in a header, StringBody's content type is evaluated last so it will probably overwrite or concatenate whatever else you set with "application/json". (This is a problem for my use case anyway.) Second,jsonBody
callsEncode.encode
on the Value which callsJSON.stringify
in javascript. In my quick search, this will neither stringify the file contents nor keep the JS File object in tact. So it will not upload the file.So, nevermind. I still need to do it with native code (edit: or a port to Javascript) currently.
For the MIME type, this is not a problem, you can define your own function like:
Encode.encode
is another story.JSON.stringify
could be monkey patched to returnFile
objects unmodified, butencode
is actuallyJSON.stringify(...) + ''
(since 0.19), so even ifstringify
preserves the file,encode
will still return an"[object File]"
string because of type coercion.Anyway, using a port with
readAsDataURL
and uploading base64 encoded files is not so bad, are the overhead and server decoding really an issue for you?Nah. At the time I couldn't find a succinct example with the FileReader stuff. The one I found still used native code and also had a lot of extra abstractions to wade through. So it was quicker to just do what I did. But I'm not married to it. I did find a pretty clear port solution with FileReader that I would use now.