re: Elm 0.19 Broke Us πŸ’” VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION

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