[elm-discuss] File Uploads - as simple as I could manage

[Kasey Speakman]

After a bit of research on file uploads, I pared it down to the simplest
method I could find. Here is the recipe I came up with.

https://gist.github.com/kspeakman/20708d5ff58b6ea75f9c3a82f6c793c3

The FileUtils module essentially wraps the JS File object in Http.Body as
well as exposing common file info (name, size, contentType). Using
Http.Body makes it quite easy to send files with normal Http calls.
Unfortunately this does use native/kernel code, but this made it far easier
to work with in Elm than if I used ports. I did actually try using decoders
first to pull in the "e.target.files" property as a Value, but Elm just
fails to decode it.

I also thought something like this could be a path forward to introduce
basic file uploads into Elm's core. It is not a general solution for all
binary formats. But it is a straightforward way to handle File objects from
JS.

[Witold Szczerba]

I did actually try using decoders first to pull in the "e.target.files"

property as a Value, but Elm just fails to decode it.

How did you try to decode the "files"? There is a special function:
value -> Decoder Value
it does leave the structure "as is". I was wandering if it could work? The
original "files" could be then assigned to the body, so Elm would not touch
it at all. Would it possibly work?

Regards,
Witold Szczerba

After a bit of research on file uploads, I pared it down to the simplest
method I could find. Here is the recipe I came up with.
https://gist.github.com/kspeakman/20708d5ff58b6ea75f9c3a82f6c793c3
The FileUtils module essentially wraps the JS File object in Http.Body as
well as exposing common file info (name, size, contentType). Using
Http.Body makes it quite easy to send files with normal Http calls.
Unfortunately this does use native/kernel code, but this made it far easier
to work with in Elm than if I used ports. I did actually try using decoders
first to pull in the "e.target.files" property as a Value, but Elm just
fails to decode it.
I also thought something like this could be a path forward to introduce
basic file uploads into Elm's core. It is not a general solution for all
binary formats. But it is a straightforward way to handle File objects from
JS.
--
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

I tried using both:

import Json.Decode as Json

-- the first JS File
Json.at [ "target", "files" ] (Json.index 0 Json.value)

-- the JS FileList
Json.at [ "target", "files" ] Json.value

Both of which came back as undefined after decoding. Maybe I was doing
something else wrong?

Even one of these came through as Value, you can't do anything with it in
Elm. The Http module has no mechanism to send Value, only Strings
(multi-part also takes only Strings). For security reasons, the only way to
access the JS File contents (AFAIK) is through another JS API like XHR (to
send) or FileReader (to read the contents). There has to be some native
code involved to either get the contents or convert the file reference to
something that Elm can use.

Post by Witold Szczerba

I did actually try using decoders first to pull in the "e.target.files"

property as a Value, but Elm just fails to decode it.
value -> Decoder Value
it does leave the structure "as is". I was wandering if it could work? The
original "files" could be then assigned to the body, so Elm would not touch
it at all. Would it possibly work?
Regards,
Witold Szczerba

After a bit of research on file uploads, I pared it down to the simplest
method I could find. Here is the recipe I came up with.
https://gist.github.com/kspeakman/20708d5ff58b6ea75f9c3a82f6c793c3
The FileUtils module essentially wraps the JS File object in Http.Body as
well as exposing common file info (name, size, contentType). Using
Http.Body makes it quite easy to send files with normal Http calls.
Unfortunately this does use native/kernel code, but this made it far easier
to work with in Elm than if I used ports. I did actually try using decoders
first to pull in the "e.target.files" property as a Value, but Elm just
fails to decode it.
I also thought something like this could be a path forward to introduce
basic file uploads into Elm's core. It is not a general solution for all
binary formats. But it is a straightforward way to handle File objects from
JS.
--
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

I believe you can use ports without native code to pass the event reference
as Value to JS and call the FileReader API, returning file as String back
to Elm. But that was more convoluted than I wanted to deal with.

Post by Kasey Speakman
import Json.Decode as Json
-- the first JS File
Json.at [ "target", "files" ] (Json.index 0 Json.value)
-- the JS FileList
Json.at [ "target", "files" ] Json.value
Both of which came back as undefined after decoding. Maybe I was doing
something else wrong?
Even one of these came through as Value, you can't do anything with it in
Elm. The Http module has no mechanism to send Value, only Strings
(multi-part also takes only Strings). For security reasons, the only way to
access the JS File contents (AFAIK) is through another JS API like XHR (to
send) or FileReader (to read the contents). There has to be some native
code involved to either get the contents or convert the file reference to
something that Elm can use.

I did actually try using decoders first to pull in the

"e.target.files" property as a Value, but Elm just fails to decode it.
value -> Decoder Value
it does leave the structure "as is". I was wandering if it could work?
The original "files" could be then assigned to the body, so Elm would not
touch it at all. Would it possibly work?
Regards,
Witold Szczerba

After a bit of research on file uploads, I pared it down to the simplest
method I could find. Here is the recipe I came up with.
https://gist.github.com/kspeakman/20708d5ff58b6ea75f9c3a82f6c793c3
The FileUtils module essentially wraps the JS File object in Http.Body
as well as exposing common file info (name, size, contentType). Using
Http.Body makes it quite easy to send files with normal Http calls.
Unfortunately this does use native/kernel code, but this made it far easier
to work with in Elm than if I used ports. I did actually try using decoders
first to pull in the "e.target.files" property as a Value, but Elm just
fails to decode it.
I also thought something like this could be a path forward to introduce
basic file uploads into Elm's core. It is not a general solution for all
binary formats. But it is a straightforward way to handle File objects from
JS.
--
You received this message because you are subscribed to the Google
Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

Err, I should say I made a trade toward ease at the potential cost of
safety by doing native instead of ports. I might make a different choice if
the JS code were more complicated.

Post by Kasey Speakman
I believe you can use ports without native code to pass the event
reference as Value to JS and call the FileReader API, returning file as
String back to Elm. But that was more convoluted than I wanted to deal with.

[Witold Szczerba]

You are right, it wouldn't work as I've thought. Native done right is OK,
but the problem is someone has to "approve" the project or it won't be
available to others by Elm package. I wonder if it's actually doable.

Post by Kasey Speakman
Err, I should say I made a trade toward ease at the potential cost of
safety by doing native instead of ports. I might make a different choice if
the JS code were more complicated.

Post by Kasey Speakman
I believe you can use ports without native code to pass the event
reference as Value to JS and call the FileReader API, returning file as
String back to Elm. But that was more convoluted than I wanted to deal with.

--
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

I don't think there are new native packages being approved. In fact, I
think more are to get cut soon. We will just have to wait on Evan to put a
File type into Elm and a Body type for it in the Http module (or something
like that).

Post by Witold Szczerba
You are right, it wouldn't work as I've thought. Native done right is OK,
but the problem is someone has to "approve" the project or it won't be
available to others by Elm package. I wonder if it's actually doable.

[Alexandre Galays]

"Waiting for Evan". I've heard that before!

Post by Kasey Speakman
I don't think there are new native packages being approved. In fact, I
think more are to get cut soon. We will just have to wait on Evan to put a
File type into Elm and a Body type for it in the Http module (or something
like that).

Post by Witold Szczerba
You are right, it wouldn't work as I've thought. Native done right is OK,
but the problem is someone has to "approve" the project or it won't be
available to others by Elm package. I wonder if it's actually doable.

[Simon]

file-reader was in queue for native approval at 0.16 but that was the point
that all native approvals got rejected. To this day there is no easy way to
find 'libraries' that use native code, although there are now tools to
instal them easily from their github source.

Post by Alexandre Galays
"Waiting for Evan". I've heard that before!
http://youtu.be/Wifcyo64n-w

Post by Kasey Speakman
I don't think there are new native packages being approved. In fact, I
think more are to get cut soon. We will just have to wait on Evan to put a
File type into Elm and a Body type for it in the Http module (or something
like that).

Post by Witold Szczerba
You are right, it wouldn't work as I've thought. Native done right is
OK, but the problem is someone has to "approve" the project or it won't be
available to others by Elm package. I wonder if it's actually doable.

[Erik Lott]

You may want to see "file-reader" if you haven't seen it already:
https://github.com/simonh1000/file-reader

Post by Kasey Speakman
After a bit of research on file uploads, I pared it down to the simplest
method I could find. Here is the recipe I came up with.
https://gist.github.com/kspeakman/20708d5ff58b6ea75f9c3a82f6c793c3
The FileUtils module essentially wraps the JS File object in Http.Body as
well as exposing common file info (name, size, contentType). Using
Http.Body makes it quite easy to send files with normal Http calls.
Unfortunately this does use native/kernel code, but this made it far easier
to work with in Elm than if I used ports. I did actually try using decoders
first to pull in the "e.target.files" property as a Value, but Elm just
fails to decode it.
I also thought something like this could be a path forward to introduce
basic file uploads into Elm's core. It is not a general solution for all
binary formats. But it is a straightforward way to handle File objects from
JS.

[Kasey Speakman]

That was one of the first things I found. I'm uploading to S3 too. But the
API was a bit larger than I wanted to take on for my meager needs. Props to
simonh1000 for leading the way.

Post by Erik Lott
https://github.com/simonh1000/file-reader
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsimonh1000%2Ffile-reader&sa=D&sntz=1&usg=AFQjCNG3XcgaMRHo0LhjprQlhKSI_YskUg>