Re: [elm-discuss] Cmd.map

[Eric G]

I agree with Mark. In addition, to avoid circular dependencies it means you 
have to put your top-level Msg type in a separate module with no 
dependencies on the module where your update is defined. I strongly prefer 
to have the Msg type next to the update. Ok, the compiler will still save 
you wherever it is, but there is something to be said for having the 
possible values right there in front of you.

Also thanks Mark for the clearest explanation I have seen of 'what happened 
to classic TEA' and 'is it ever useful'. Here's my stab at it. IMO it's a 
perfectly fine tool for encapsulating pages of an app, or other "places it 
makes sense to break ones app apart". It's not as nice for reusable bits of 
UI, because it forces dealing with nested messages in your view and update 
at every call site. Injecting generic message types and tagger functions 
(e.g. `String -> msg`) into the view gets rid of this boilerplate. At the 
same time, if your child module deals with a lot of different messages, and 
you're only using it one place, it's sometimes less work to nest, rather 
than inject into the view stuff like `Child.view ClickChildMsg 
onInputDoSomething SaveMsg model.child` or `Child.view massiveConfig 
model.child`.

I think it has caused a bit of confusion to remove classic TEA 
documentation, but I don't know which confusion is worse -- thinking it's 
the only way to do things, or not realizing it's even an option :)



On Thursday, March 30, 2017 at 11:51:17 AM UTC-4, Mark Hamburg wrote:
>
> As I said, in your small example it probably doesn't matter. But I've also 
> seen larger examples with more fields in the top level model. My point is 
> that if there are any cross-field validity constraints, then it's probably 
> a bad idea to have lots of code that is not only able to but expected to 
> produce new models. Classic TEA allows one to have the page handler code 
> handle pages — keeping the top level model ignorant of the details and 
> unable to muck with the page model — while the top level code handles and 
> enforces the constraints for the top level model.
>
> Export as little as possible. If you have constraints on how pieces 
> interact and you can't just make the type system enforce them, then make 
> sure there is only one module that can modify those pieces. Reduce the 
> surface area in case you have to go hunting for bugs.
>
> Mark
>
> On Wed, Mar 29, 2017 at 5:57 PM Witold Szczerba  > wrote:
>
>> I'm not really sure what are you suggesting, Mark. Is it's all really 
>> about that CSRF token, then OK, I could have hide it behind opaque type and 
>> expose just the bare minimum, so noone could tinker with it's value. Or I 
>> could turn the simple architecture into more complicated (extra mappings of 
>> models and commands?) just in the name of... what would that be? And what 
>> if all that barriers and safety guards turns against me by being too 
>> restrictive?
>>
>> Just because you can change that token, does it mean you could do it by 
>> mistake? I don't really think that would the case. And if you have to, you 
>> could just do it, without developing circles around all those "safety" 
>> guards, I guess...
>>
>> 30.03.2017 1:36 AM "Mark Hamburg"  
>> napisał(a):
>>
>>> While it cuts down on the boilerplate, it seems like this creates a fair 
>>> amount of exposure for what might otherwise be internal structures. For 
>>> example, if the page update functions all get and produce full models, then 
>>> each of the modules implementing those update functions becomes a place 
>>> where any cross-field invariants have to be maintained. Now, if you can 
>>> build your model in such a way that all representable states are also 
>>> considered legal — the corollary to making illegal states impossible — then 
>>> you don't have a problem. But if you can't arrange this, then you've taken 
>>> a validity concern and spread it through your codebase. Functional 
>>> programming protects you from a particular data instance being modified but 
>>> you still need to figure out how you guarantee that all data instances that 
>>> get produced are valid. In your little example — which probably is small 
>>> enough not to trigger a problem — would you consider it acceptable for a 
>>> page update to change the CSRF token? If not, then the page update should 
>>> not produce a new Model.
>>>
>>> Mark
>>>
>>> On Wed, Mar 29, 2017 at 3:29 PM, Witold Szczerba >> > wrote:
>>>
 The best solution to deal with your problems is to use Swiss knife of 
 functional programming, i.e.* function composition*. You would be 
 surprised how about anything could be handled by this *simple* 
 technique. 

 Few weeks ago there was a question asked on Reddit about nesting data 
 in a model. It was actually more about structuring the application, so I 
 think your questions are related. I have answered providing a 

Re: [elm-discuss] Re: Compiler option to disable camel-case record property requirement?

[Witold Szczerba]

There is no need to convert JS object to a string. Just declare a Value in
your port and now you can decode it as you will.

Regards,
Witold Szczerba

30.03.2017 7:14 PM "Christian Charukiewicz" 
napisał(a):

> To add onto what Rupert said, my assumption is that you are relying on
> Ports automatically converting your JS objects to Elm records with
> identical field types.  This is very cumbersome.  And, as far as I know,
> you are also limited to using primitive types (Int, Bool, String, List,
> etc), and can't use ports to any custom union types that you will likely
> create as your application grows.
>
> What you can do instead is send your entire object as a JSON string (in
> Elm you would just receive it as a single String value) and then apply a
> Decoder you write yourself to that string to produce whatever Elm values
> you want.  You would be using Decode.decodeString
> ,
> but be sure to look at the rest of the documentation in that module.  Your
> first argument to decodeString will be a Decoder that you create yourself,
> which in the case of a complex object may be the composition of several
> Decoder functions that serve to transform the JSON data into whatever Elm
> values you want.  This way you are not constrained to use matching
> record/field names either.
>
> Decoders are a huge part of Elm, and you will encounter them elsewhere.  I
> strongly suggest taking the time to learn to use them, as this more than
> likely fix your performance issues as well.  We have decoded wildly complex
> JSON objects with Elm Decoders and have never noticed a degradation in
> performance at all.
>
> To give you a bit of help, here's an example:
>
> Say I have an object like
>
> {
> user_id: 5
> user_name: "John"
> }
>
> And my Elm type is:
>
> type alias User =
> { userId: Int
> , userName: String
> }
>
>
> My decoder might look like:
>
> userDecoder : Decoder User
> userDecoder =
> map2 User
> (field "user_id" int)
> (field "user_name" string)
>
> And applying it would look like (assuming jsonString was a JSON string
> sent as a single value by a Ports)
>
> decodeUser : String -> User
> decoderUser jsonString =
> decoderString userDecoder jsonString
>
> Hope that helps!
>
> On Thursday, March 30, 2017 at 12:11:44 AM UTC-5, Stein Setvik wrote:
>>
>> We're using Ports to bring the data from js into elm.
>>
>> On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz
>> wrote:
>>>
>>> Can you elaborate on how you are getting the data from the backend into
>>> Elm values?  Are you not using Elm decoders?  We use snake_case for all of
>>> our database fields, and writing decoders that will receive the JSON and
>>> produce Elm values is a step we have to take with all of our data before it
>>> ends up in an Elm record value anyway.  Are you avoiding this somehow?
>>>
>>> On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:

 Would you consider adding an option for users to disable the camel-case
 requirement for record properties in the compiler?

 Our use case:
 We have a large legacy system we'd like to bring Elm into that uses
 pascal case throughout (all database fields and all places they're
 referenced in the backend and frontend).

 We are planning on updating to camel case; however, it will be a
 complicated change and is ~9 months out.

 We'd like to look at Elm before then, but the camel case requirement is
 creating a performance hit because we have to clone all objects and rename
 all pascal cased properties before shipping them over ports to Elm.

 Example:
 We migrated a results view for realtime search (Algolia) in a product
 catalog. The result view updates in real-time with every keystroke, and the
 JS transformation of the data before sending it to Elm is weighty enough to
 delay and slow the rendering of the results in a noticeable way.

 Thoughts?

>>> --
> 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
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Compiler option to disable camel-case record property requirement?

[Christian Charukiewicz]

Sorry I made a few bad typos in my last example function.  It should be:

decodeUser : String -> User
decodeUser jsonString =
decodeString userDecoder jsonString



On Thursday, March 30, 2017 at 12:14:23 PM UTC-5, Christian Charukiewicz 
wrote:
>
> To add onto what Rupert said, my assumption is that you are relying on 
> Ports automatically converting your JS objects to Elm records with 
> identical field types.  This is very cumbersome.  And, as far as I know, 
> you are also limited to using primitive types (Int, Bool, String, List, 
> etc), and can't use ports to any custom union types that you will likely 
> create as your application grows.
>
> What you can do instead is send your entire object as a JSON string (in 
> Elm you would just receive it as a single String value) and then apply a 
> Decoder you write yourself to that string to produce whatever Elm values 
> you want.  You would be using Decode.decodeString 
> ,
>  
> but be sure to look at the rest of the documentation in that module.  Your 
> first argument to decodeString will be a Decoder that you create yourself, 
> which in the case of a complex object may be the composition of several 
> Decoder functions that serve to transform the JSON data into whatever Elm 
> values you want.  This way you are not constrained to use matching 
> record/field names either.
>
> Decoders are a huge part of Elm, and you will encounter them elsewhere.  I 
> strongly suggest taking the time to learn to use them, as this more than 
> likely fix your performance issues as well.  We have decoded wildly complex 
> JSON objects with Elm Decoders and have never noticed a degradation in 
> performance at all.
>
> To give you a bit of help, here's an example:
>
> Say I have an object like
>
> {
> user_id: 5
> user_name: "John"
> }
>
> And my Elm type is:
>
> type alias User =
> { userId: Int
> , userName: String
> }
>
>
> My decoder might look like:
>
> userDecoder : Decoder User
> userDecoder =
> map2 User
> (field "user_id" int)
> (field "user_name" string)
>
> And applying it would look like (assuming jsonString was a JSON string 
> sent as a single value by a Ports)
>
> decodeUser : String -> User
> decoderUser jsonString =
> decoderString userDecoder jsonString
>
> Hope that helps!
>
> On Thursday, March 30, 2017 at 12:11:44 AM UTC-5, Stein Setvik wrote:
>>
>> We're using Ports to bring the data from js into elm.
>>
>> On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz 
>> wrote:
>>>
>>> Can you elaborate on how you are getting the data from the backend into 
>>> Elm values?  Are you not using Elm decoders?  We use snake_case for all of 
>>> our database fields, and writing decoders that will receive the JSON and 
>>> produce Elm values is a step we have to take with all of our data before it 
>>> ends up in an Elm record value anyway.  Are you avoiding this somehow?
>>>
>>> On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:

 Would you consider adding an option for users to disable the camel-case 
 requirement for record properties in the compiler?

 Our use case:
 We have a large legacy system we'd like to bring Elm into that uses 
 pascal case throughout (all database fields and all places they're 
 referenced in the backend and frontend).

 We are planning on updating to camel case; however, it will be a 
 complicated change and is ~9 months out.

 We'd like to look at Elm before then, but the camel case requirement is 
 creating a performance hit because we have to clone all objects and rename 
 all pascal cased properties before shipping them over ports to Elm.

 Example:
 We migrated a results view for realtime search (Algolia) in a product 
 catalog. The result view updates in real-time with every keystroke, and 
 the 
 JS transformation of the data before sending it to Elm is weighty enough 
 to 
 delay and slow the rendering of the results in a noticeable way.

 Thoughts?

>>>

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Compiler option to disable camel-case record property requirement?

[Christian Charukiewicz]

To add onto what Rupert said, my assumption is that you are relying on 
Ports automatically converting your JS objects to Elm records with 
identical field types.  This is very cumbersome.  And, as far as I know, 
you are also limited to using primitive types (Int, Bool, String, List, 
etc), and can't use ports to any custom union types that you will likely 
create as your application grows.

What you can do instead is send your entire object as a JSON string (in Elm 
you would just receive it as a single String value) and then apply a 
Decoder you write yourself to that string to produce whatever Elm values 
you want.  You would be using Decode.decodeString 
,
 
but be sure to look at the rest of the documentation in that module.  Your 
first argument to decodeString will be a Decoder that you create yourself, 
which in the case of a complex object may be the composition of several 
Decoder functions that serve to transform the JSON data into whatever Elm 
values you want.  This way you are not constrained to use matching 
record/field names either.

Decoders are a huge part of Elm, and you will encounter them elsewhere.  I 
strongly suggest taking the time to learn to use them, as this more than 
likely fix your performance issues as well.  We have decoded wildly complex 
JSON objects with Elm Decoders and have never noticed a degradation in 
performance at all.

To give you a bit of help, here's an example:

Say I have an object like

{
user_id: 5
user_name: "John"
}

And my Elm type is:

type alias User =
{ userId: Int
, userName: String
}


My decoder might look like:

userDecoder : Decoder User
userDecoder =
map2 User
(field "user_id" int)
(field "user_name" string)

And applying it would look like (assuming jsonString was a JSON string sent 
as a single value by a Ports)

decodeUser : String -> User
decoderUser jsonString =
decoderString userDecoder jsonString

Hope that helps!

On Thursday, March 30, 2017 at 12:11:44 AM UTC-5, Stein Setvik wrote:
>
> We're using Ports to bring the data from js into elm.
>
> On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz 
> wrote:
>>
>> Can you elaborate on how you are getting the data from the backend into 
>> Elm values?  Are you not using Elm decoders?  We use snake_case for all of 
>> our database fields, and writing decoders that will receive the JSON and 
>> produce Elm values is a step we have to take with all of our data before it 
>> ends up in an Elm record value anyway.  Are you avoiding this somehow?
>>
>> On Wednesday, March 29, 2017 at 10:41:36 AM UTC-5, Stein Setvik wrote:
>>>
>>> Would you consider adding an option for users to disable the camel-case 
>>> requirement for record properties in the compiler?
>>>
>>> Our use case:
>>> We have a large legacy system we'd like to bring Elm into that uses 
>>> pascal case throughout (all database fields and all places they're 
>>> referenced in the backend and frontend).
>>>
>>> We are planning on updating to camel case; however, it will be a 
>>> complicated change and is ~9 months out.
>>>
>>> We'd like to look at Elm before then, but the camel case requirement is 
>>> creating a performance hit because we have to clone all objects and rename 
>>> all pascal cased properties before shipping them over ports to Elm.
>>>
>>> Example:
>>> We migrated a results view for realtime search (Algolia) in a product 
>>> catalog. The result view updates in real-time with every keystroke, and the 
>>> JS transformation of the data before sending it to Elm is weighty enough to 
>>> delay and slow the rendering of the results in a noticeable way.
>>>
>>> Thoughts?
>>>
>>

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Better syntax for nested pattern matching (destructuring)?

[Matthieu Pizenberg]

>
> Instead of calling it 'getVar3', I am using names like 'whenWithVar3'. The 
> 'when' part better reflects that the operation will not always produce a 
> result. 'whenWith' is a bit long, perhaps 'whenVar3' might be better?
>

This sounds well also. I've no idea though about conventions that may 
exist. 
 

> But perhaps the 'get' and 'set' conventions are already better established 
> from lenses or monocles?
>

 You got me curious by mentionning lenses and monocles. I looked around for 
existing packages explaining those concepts and found a few interesting. 
Maybe the more versatile, that could be helpful with my nested pattern 
matching issue is elm-monocle 
(http://package.elm-lang.org/packages/arturopala/elm-monocle/latest) from 
arturopala. In particular, the Optional type seems very interesting. I will 
keep it in mind for next time. There is no rush.

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Cmd.map

[Mark Hamburg]

As I said, in your small example it probably doesn't matter. But I've also
seen larger examples with more fields in the top level model. My point is
that if there are any cross-field validity constraints, then it's probably
a bad idea to have lots of code that is not only able to but expected to
produce new models. Classic TEA allows one to have the page handler code
handle pages — keeping the top level model ignorant of the details and
unable to muck with the page model — while the top level code handles and
enforces the constraints for the top level model.

Export as little as possible. If you have constraints on how pieces
interact and you can't just make the type system enforce them, then make
sure there is only one module that can modify those pieces. Reduce the
surface area in case you have to go hunting for bugs.

Mark

On Wed, Mar 29, 2017 at 5:57 PM Witold Szczerba 
wrote:

> I'm not really sure what are you suggesting, Mark. Is it's all really
> about that CSRF token, then OK, I could have hide it behind opaque type and
> expose just the bare minimum, so noone could tinker with it's value. Or I
> could turn the simple architecture into more complicated (extra mappings of
> models and commands?) just in the name of... what would that be? And what
> if all that barriers and safety guards turns against me by being too
> restrictive?
>
> Just because you can change that token, does it mean you could do it by
> mistake? I don't really think that would the case. And if you have to, you
> could just do it, without developing circles around all those "safety"
> guards, I guess...
>
> 30.03.2017 1:36 AM "Mark Hamburg"  napisał(a):
>
> While it cuts down on the boilerplate, it seems like this creates a fair
> amount of exposure for what might otherwise be internal structures. For
> example, if the page update functions all get and produce full models, then
> each of the modules implementing those update functions becomes a place
> where any cross-field invariants have to be maintained. Now, if you can
> build your model in such a way that all representable states are also
> considered legal — the corollary to making illegal states impossible — then
> you don't have a problem. But if you can't arrange this, then you've taken
> a validity concern and spread it through your codebase. Functional
> programming protects you from a particular data instance being modified but
> you still need to figure out how you guarantee that all data instances that
> get produced are valid. In your little example — which probably is small
> enough not to trigger a problem — would you consider it acceptable for a
> page update to change the CSRF token? If not, then the page update should
> not produce a new Model.
>
> Mark
>
> On Wed, Mar 29, 2017 at 3:29 PM, Witold Szczerba 
> wrote:
>
> The best solution to deal with your problems is to use Swiss knife of
> functional programming, i.e.* function composition*. You would be
> surprised how about anything could be handled by this *simple* technique.
>
> Few weeks ago there was a question asked on Reddit about nesting data in a
> model. It was actually more about structuring the application, so I think
> your questions are related. I have answered providing a little example of
> the structure of my own application. I think you could be interested, so
> please take a look:
>
>
> https://www.reddit.com/r/elm/comments/5wikog/easy_questions_beginners_thread_week_of_20170227/deeptz3/
>
> In my opinion (yes, I am repeating myself) the most simple layout of all
> the "modules" is to have an update functions like this:
>
> *update: XyzMsg -> Model -> ( Model, Cmd Msg )*
>
> Where XyzMsg is the module's message, Model is top level model and Msg is
> top level message. The main update function just delegates to the update
> functions of each module, so it looks like a table of contents of possible
> actions and the main model looks like a table of contents of the possible
> states. It really makes working with the application a pleasure :) Every
> time I go back to the other app written in AngularJS, I feel like I am lost
> in a thick fog.
>
> I hope it helps!
>
> Regards,
> Witold Szczerba
>
> P.S.
> My application has grown a little bit since then, the main model is now a
> little bit different:
>
> type Page
> = NoPage
> | AnnouncementListPage (WebData (List Announcement))
> | AnnouncementItemPage (WebData AnnouncementForm)
> | PayoutCancelledListPage (WebData PayoutListForm)
>
>
> type alias Model =
> { page : Page
> , csrfToken : String
> }
>
> As you can see, now I am able to keep a `csrfToken` independent of the
> current page. Now I can add even more things not related to the actual
> page, like e.g. logged in user.
>
>
> On Wed, Mar 29, 2017 at 11:29 PM, Juan Ibiapina 
> wrote:
>
> Thanks for the explanation.
>
> I understand the choices made so far, but I 

[elm-discuss] ANN: TypedSvg

[Duane Johnson]

Hi all,

I've been working on a TypedSvg package here:

http://package.elm-lang.org/packages/canadaduane/typed-svg/2.0.1

Its intent is to replace `elm-lang/svg` with a fully typed and documented
SVG package. There's still a lot of work to do (the SVG spec is huge) but
I'm pretty happy with the progress that's been made. I'm announcing this
now so that if others are interested in a similar package, we can
consolidate effort and help one another rather than duplicate effort.

Thanks,
Duane Johnson

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Collecting use cases for File, ArrayBuffer and TypedArrays/DataViews

[Simon]

My company uses websockets for mobile apps and thus wants to save on 
bandwidth. As a result all websocket traffic is encoded using msgpack, but 
the current library cannot handle that - presumably because of Elm's lack 
of underlying support for binary data.


On Thursday, 28 July 2016 23:17:51 UTC+2, Daniel Bachler wrote:
>
> I'd love to see support for the File and ArrayBuffer Apis, and maybe 
> TypedArrays/DataViews as well. IMHO they are an important piece of the Web 
> Platform that is still missing in Elm.
>
> Evan suggested collecting concrete use cases to guide the design. I would 
> like this thread to be the starting point of this effort. I would like to 
> ask anyone who would also like this feature or who has substantial 
> experience using either Api to add use cases or comment here so that we can 
> try to define the user story for both apis. From there, we could decide 
> what we would like to see supported and what, if anything, we don't need 
> for now and suggest Elm Apis.
>
> I have two stories from a side project of mine. It is a slideshow editor 
> that allows the user to select photos and audio files from the local 
> system, uploads them to a web service, let's the user arrange and 
> manipulate photos and music and then share the result with others. For 
> this, I have two immediate use cases plus some more ideas:
>
> *Upload local files as binary blob to AWS S3*
>
> In my current, (hacky) version, I use the FileReader api (via simonH1000's 
> filereader library) to read the content of a file into an ArrayBuffer, 
> (represented as Json.Value in Elm) then use a modified version of elm-http 
> to upload the content of the ArrayBuffer to an S3 storage bucket.
>
> *Download mp3 files, decode them and play them back via the AudioApi*
>
> Currently I do this with my modified http library to download the mp3 file 
> into an arraybuffer, then pass the resulting arraybuffer through a port to 
> some native javascript that then uses the Audio Api to decode the mp3 file 
> into a playable audiobuffer.
>
> *Parsing or otherwise processing local text files. *
>
> For another project I would be interested in reading and parsing 
> Swagger/OpenAPI definition files and then providing a UI to compare rest 
> apis. Since the processing will be done on simple Strings, this would only 
> require FileReader support (specifically the readAsText method). This would 
> already work with the FileReader library as is (though that one is not 
> available on package.elm-lang.org because it contains native code and is 
> not whitelisted).
>
> *TypedArrays and DataViews*
>
> I haven't worked with these yet, but I can anticipate some cases that 
> would be interesting:
>
> *Parsing/manipulating of binary data via the ArrayBuffer api.*
>
> One case I personally would like to do with this, is to parse the Exif 
> header of the jpeg files the user loaded from the local file system. My 
> slideshow could then display metadata information without roundtripping to 
> the server.
>
> *Create geometry for WebGL in the form of Vertex Buffers*
>
> *Generating sound/music by writing raw audio samples*
>
> These could then be played back via the Web audio apis.
>
>
> Please add your own ideas to this thread. Once we have compiled a list of 
> use cases, we can look at the JS Apis available under the Web Platform for 
> Files, ArrayBuffers, Typed Arrays etc. and think how these could be exposed 
> to Elm. 
>

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Support for binary data

[Simon]

My use case:

My company uses websockets for mobile apps and thus wants to save on 
bandwidth. As a result all websocket traffic is encoded using msgpack, but 
the current library cannot handle that.



On Tuesday, 12 January 2016 01:32:43 UTC+1, Evan wrote:
>
> I have been drafting Blob and ArrayBuffer APIs, but I wasn't sure who 
> needed them.
>
> What is your particular use case?
>
> On Mon, Jan 11, 2016 at 4:55 AM, John Watson  > wrote:
>
>> Can anyone tell me what the plans are for supporting binary data in elm?  
>> I'm thinking of a Byte (and some sort of Byte Array) type and also 
>> implementing Blob in HTTP responses. 
>>
>> -- 
>> 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 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Better syntax for nested pattern matching (destructuring)?

['Rupert Smith' via Elm Discuss]

On Thursday, March 30, 2017 at 8:31:29 AM UTC+1, Aaron VonderHaar wrote:
>
> In your abstract example, instead of:
>
> andThen2 : (Var2 -> a) -> Type2 -> Maybe a
>
> you should try to write:
>
> getVar3 : Type2 -> Maybe Var3
>

A most informative discussion, thanks for this. I have kind of figured much 
of this out for myself but not quite so completely or neatly as you have 
shown here.

Instead of calling it 'getVar3', I am using names like 'whenWithVar3'. The 
'when' part better reflects that the operation will not always produce a 
result. 'whenWith' is a bit long, perhaps 'whenVar3' might be better?

model.study.status
|> whenProgressingSteps
|> Maybe.map Pivot.whenCurrent
|> Maybe.andThen whenScribbles
|> Maybe.map (Scribbles.update scribblesMsg model)
|> Maybe.withDefault model

But perhaps the 'get' and 'set' conventions are already better established 
from lenses or monocles?

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Compiler option to disable camel-case record property requirement?

['Rupert Smith' via Elm Discuss]

On Wednesday, March 29, 2017 at 4:41:36 PM UTC+1, Stein Setvik wrote:
>
> Would you consider adding an option for users to disable the camel-case 
> requirement for record properties in the compiler?
>
> Our use case:
> We have a large legacy system we'd like to bring Elm into that uses pascal 
> case throughout (all database fields and all places they're referenced in 
> the backend and frontend).
>
> We are planning on updating to camel case; however, it will be a 
> complicated change and is ~9 months out.
>
> We'd like to look at Elm before then, but the camel case requirement is 
> creating a performance hit because we have to clone all objects and rename 
> all pascal cased properties before shipping them over ports to Elm.
>
> Example:
> We migrated a results view for realtime search (Algolia) in a product 
> catalog. The result view updates in real-time with every keystroke, and the 
> JS transformation of the data before sending it to Elm is weighty enough to 
> delay and slow the rendering of the results in a noticeable way.
>
> Thoughts?
>

Do you have some meta-data describing the data structure that you want to 
map into Elm? For example json-schema or Swagger or possibly even the 
database DDL if the tables map to the HTTP response bodies in a very 1:1 
way? If you have this, you could invest in writing a code generator that 
automatically writes your Elm Encoder/Decoder logic for you.

As others have noted you can specify different field names in the json from 
the Elm records and have the Elm Encoder/Decoder logic handle the 
conversion between pascal and camel case for you.

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Cmd.map

['Rupert Smith' via Elm Discuss]

On Wednesday, March 29, 2017 at 8:54:13 PM UTC+1, Mark Hamburg wrote:
>
> My advice would be to use the message routing patterns from classic TEA in 
> the places it makes sense to break ones app apart — just know that it isn't 
> particularly well suited to building components.
>

I have to say, I am using nested TEA and I am finding that it is very good 
for building components. What I like is that it gives a standard structure 
to each of my components: (Msg, Model, init, subscriptions, update, view).

I am using Cmd.map and Html.map and Sub.map to wrap the messages of a 
component so that it can be embedded within the message type of the thing 
importing the component.

There is a little bit of boiler-plate to 'lift' the component into a parent 
- but you can write helper functions for that.

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Better syntax for nested pattern matching (destructuring)?

[Matthieu Pizenberg]

>
> model.study.status
>   |> getProgressingSteps
>   |> Maybe.map Pivot.getCurrent
>   |> Maybe.andThen getScribbles
>   |> Maybe.map (Scribbles.update scribblesMsg model)
>   |> Maybe.withDefault model
> ...
>

 Thank you Aaron, that makes it definitely more readable! Those getters are 
the key (`Maybe` I should go back to code in Java ^^)

-- 
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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.