re: Elm 0.19 Broke Us 💔 VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I did recently find an Elm only solution to this that might work. You got me curious, what are you thinking about?

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.

For the MIME type, this is not a problem, you can define your own function like:

rawBody : Decode.Value -> Http.Body
rawBody value =
    Http.stringBody "application/octet-stream" (Encode.encode 0 value)

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.

code of conduct - report abuse