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

[Stein Setvik]

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?

[Stein Setvik]

I haven't looked into decoders yet. I'll read up on it and give them ago to 
see if there's a performance advantage to doing it on the Elm side vs the 
js side.

On Wednesday, March 29, 2017 at 9:44:11 AM UTC-7, Kasey Speakman wrote:
>
> Short of language changes, you could:
>
> * Use the infamous encoders/decoders to emit/parse pascal case.
> * Use a header on the HTTP request to instruct the server to assume camel 
> case for the request.
>
> Without pre-existing clients, I have the server emit camelCase (a 
> serializer configuration option). In a happy surprise, deserialization was 
> already case-insensitive (in JSON.NET) so I didn't have any trouble using 
> my pascal case objects there.
>
> 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: Better syntax for nested pattern matching (destructuring)?

[Matthieu Pizenberg]

>
> We have found that this pattern is typically a good case for chaining a 
> bunch of andThen statements with a withDefault statement at the end 
> together.  The one thing is you would have to be able to adjust your values 
> to all be Maybes.
>

Yes Christian, I am wondering if people are aware of some more generic 
continuation pattern matching syntax. The andThen expression is very useful 
for monadic types like Maybe. (sorry for the M term use ^^ but it seemed 
appropiate even if I'm not into category theory). But in my exemples, I'm 
using Union types that are not Maybes. I guess what I could do is create my 
own "andThenX" like this:

f1 : Var1 -> Type2
f2 : Var2 -> Type3
...

Type Type2
= DataType2 Var2
| ...

Type Type3
= DataType3 Var3
| ...

andThen2 : (Var2 -> a) -> Type2 -> Maybe a
andThen2 f2 type2 =
case type2 of
DataType2 var2 ->
Just (f2 var2)
_ ->
Nothing

andThen3 : (Var3 -> a) -> Type3 -> Maybe a
andThen3 f3 type3 =
case type3 of
DataType3 var3 ->
Just (f3 var3)
_ ->
Nothing
...

And then (no pun intended ^^) do something like:

f1 var1
|> andThen2 f2
|> andThen (andThen3 f3)
|> ...
|> andThen (andThenN fN)
|> withDefault otherwise

This has the advantage of having a clear flow, but the inconvenient that I 
need to write the my special andThenX functions.
What do you think of this approach? 

-- 
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] Better syntax for nested pattern matching (destructuring)?

[Christian Charukiewicz]

It's an option in the browser-based rich text editor that appears when 
posting/replying.  The button looks like curly braces "{}".  Highlight the 
code you have written and then press the button. 

On Wednesday, March 29, 2017 at 11:12:31 PM UTC-5, Duane Johnson wrote:
>
> May I ask how you create these nicely formatted Elm blocks in google 
> groups?
>
> On Wed, Mar 29, 2017 at 10:40 AM, Matthieu Pizenberg <
> matthieu@gmail.com > wrote:
>
>> Multiple times in my projects, I happen to need nested pattern matching.
>> Below is a raw extract of code (in an update) showing this need.
>>
>> Study.ScribblesMsg scribblesMsg ->
>> case model.study.status of
>> Study.Progressing steps ->
>> case Pivot.getC steps of
>> Study.ScribblesStep ( imageUrl, scribbles ) ->
>> ( Scribbles.update scribblesMsg model scribbles
>> , Cmd.none
>> )
>>
>> _ ->
>> ( model, Cmd.none )
>>
>> _ ->
>> ( model, Cmd.none )
>>
>> Basically, this is a specific case of a generic following code:
>>
>> case f1 var1 of
>> DataType2 var2 ->
>> ...
>> case fn varn of
>> finalVar ->
>> doSomethingOf finalVar
>> _ ->
>> otherwise
>> ...
>>  _ ->
>> otherwise
>>
>> Do you think there could exist a syntax enabling better handling of such 
>> a case?
>> Have you encountered one in another langage maybe?
>>
>> -- 
>> 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.

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

[Christian Charukiewicz]

We have found that this pattern is typically a good case for chaining a 
bunch of andThen statements with a withDefault statement at the end 
together.  The one thing is you would have to be able to adjust your values 
to all be Maybes.

For example, if you have the following:

case someMaybeVal of
Just someVal ->
case someVal.record of
Just someInnerVal ->
Just finalVal

Nothing ->
someDefaultVal
Nothing ->
someDefaultVal

You can replace it with:

someMaybeVal
|> andThen (\someVal -> Just someVal.record)
|> andThen (\someInnerVal -> Just finalVal)
|> withDefault someDefaultVal

Looking at the documentation for andThen 
 
may help.


On Wednesday, March 29, 2017 at 11:40:40 AM UTC-5, Matthieu Pizenberg wrote:
>
> Multiple times in my projects, I happen to need nested pattern matching.
> Below is a raw extract of code (in an update) showing this need.
>
> Study.ScribblesMsg scribblesMsg ->
> case model.study.status of
> Study.Progressing steps ->
> case Pivot.getC steps of
> Study.ScribblesStep ( imageUrl, scribbles ) ->
> ( Scribbles.update scribblesMsg model scribbles
> , Cmd.none
> )
>
> _ ->
> ( model, Cmd.none )
>
> _ ->
> ( model, Cmd.none )
>
> Basically, this is a specific case of a generic following code:
>
> case f1 var1 of
> DataType2 var2 ->
> ...
> case fn varn of
> finalVar ->
> doSomethingOf finalVar
> _ ->
> otherwise
> ...
>  _ ->
> otherwise
>
> Do you think there could exist a syntax enabling better handling of such a 
> case?
> Have you encountered one in another langage maybe?
>

-- 
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]

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] Cmd.map

[Witold Szczerba]

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 still haven't been able to
>>> find good solutions for some simple problems:
>>>
>>> 1. I don't want to have every single possible message handled in the
>>> same place. It gets too big.
>>>
>>> 2. My global update function deals with everything in the app, including
>>> a message to update the value of the e-mail input field when the user is
>>> typing. This seems like a small concern that should be handled by the login
>>> page (or a component?). I don't want to clutter my model with temporary
>>> data.
>>>
>>> 3. On my User info page, my model is the same as other pages, so it has
>>> Maybe User. Since I have authorization, I *know* that there will always be
>>> a user when I go to the user info page. I want this to be reflected on the
>>> code, so I never have to check if there is a user.
>>>
>>> So far these issues are pointing me towards some sort of page
>>> 

Re: [elm-discuss] Cmd.map

[Mark Hamburg]

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 still haven't been able to
>> find good solutions for some simple problems:
>>
>> 1. I don't want to have every single possible message handled in the same
>> place. It gets too big.
>>
>> 2. My global update function deals with everything in the app, including
>> a message to update the value of the e-mail input field when the user is
>> typing. This seems like a small concern that should be handled by the login
>> page (or a component?). I don't want to clutter my model with temporary
>> data.
>>
>> 3. On my User info page, my model is the same as other pages, so it has
>> Maybe User. Since I have authorization, I *know* that there will always be
>> a user when I go to the user info page. I want this to be reflected on the
>> code, so I never have to check if there is a user.
>>
>> So far these issues are pointing me towards some sort of page separation,
>> but I haven't been able to come up with something I like yet.
>>
>> On Wed, Mar 29, 2017 at 9:54 PM, Mark Hamburg 
>> wrote:
>>
>>> The config approach pops up various places — e.g., elm-sortable-table —
>>> but isn't as well specified anywhere that I've seen because it doesn't have
>>> as clear a pattern to specify.
>>>
>>> Cmd.map (and Html,map) come out of what could be called Classic TEA. The
>>> classic Elm architecture was built to allow decomposition by using tagged
>>> messages to route through the compound model. For example, if you wanted to
>>> have a number of pages, you could have a top level model that served as a
>>> page switcher and it would use tagged messages to route to the current page
>>> (or to discard messages if they weren't bound for the current page). This
>>> worked well though I know programmers who grouse at 

Re: [elm-discuss] Cmd.map

[Witold Szczerba]

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 still haven't been able to
> find good solutions for some simple problems:
>
> 1. I don't want to have every single possible message handled in the same
> place. It gets too big.
>
> 2. My global update function deals with everything in the app, including a
> message to update the value of the e-mail input field when the user is
> typing. This seems like a small concern that should be handled by the login
> page (or a component?). I don't want to clutter my model with temporary
> data.
>
> 3. On my User info page, my model is the same as other pages, so it has
> Maybe User. Since I have authorization, I *know* that there will always be
> a user when I go to the user info page. I want this to be reflected on the
> code, so I never have to check if there is a user.
>
> So far these issues are pointing me towards some sort of page separation,
> but I haven't been able to come up with something I like yet.
>
> On Wed, Mar 29, 2017 at 9:54 PM, Mark Hamburg 
> wrote:
>
>> The config approach pops up various places — e.g., elm-sortable-table —
>> but isn't as well specified anywhere that I've seen because it doesn't have
>> as clear a pattern to specify.
>>
>> Cmd.map (and Html,map) come out of what could be called Classic TEA. The
>> classic Elm architecture was built to allow decomposition by using tagged
>> messages to route through the compound model. For example, if you wanted to
>> have a number of pages, you could have a top level model that served as a
>> page switcher and it would use tagged messages to route to the current page
>> (or to discard messages if they weren't bound for the current page). This
>> worked well though I know programmers who grouse at the amount of message
>> routing boilerplate one has to write.
>>
>> But then people started trying to build React style component models with
>> this and had trouble. At which point, various people in the Elm community
>> decided that nesting was a bad idea and advocated strongly for flatness
>> with functions being the only decomposition mechanism and those without
>> much in the way of architectural guidance. Basically, this was a case of
>> the pendulum swinging wildly and the architecture for building complex
>> applications seemingly getting cast aside without a replacement.
>>
>> 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.
>>
>> For example, our codebase contains a module providing a model and
>> corresponding messages and update function for managing the sign up/sign in
>> process. It knows how to talk to our server. It knows what validation to
>> do. It understands the errors coming back from the server. It knows nothing
>> about how to display the data and instead provides a function to fill in a
>> ViewData structure that contains the information needed by the view code.
>> We can 

Re: [elm-discuss] Cmd.map

[Juan Ibiapina]

Thanks for the explanation.

I understand the choices made so far, but I still haven't been able to find
good solutions for some simple problems:

1. I don't want to have every single possible message handled in the same
place. It gets too big.

2. My global update function deals with everything in the app, including a
message to update the value of the e-mail input field when the user is
typing. This seems like a small concern that should be handled by the login
page (or a component?). I don't want to clutter my model with temporary
data.

3. On my User info page, my model is the same as other pages, so it has
Maybe User. Since I have authorization, I *know* that there will always be
a user when I go to the user info page. I want this to be reflected on the
code, so I never have to check if there is a user.

So far these issues are pointing me towards some sort of page separation,
but I haven't been able to come up with something I like yet.

On Wed, Mar 29, 2017 at 9:54 PM, Mark Hamburg  wrote:

> The config approach pops up various places — e.g., elm-sortable-table —
> but isn't as well specified anywhere that I've seen because it doesn't have
> as clear a pattern to specify.
>
> Cmd.map (and Html,map) come out of what could be called Classic TEA. The
> classic Elm architecture was built to allow decomposition by using tagged
> messages to route through the compound model. For example, if you wanted to
> have a number of pages, you could have a top level model that served as a
> page switcher and it would use tagged messages to route to the current page
> (or to discard messages if they weren't bound for the current page). This
> worked well though I know programmers who grouse at the amount of message
> routing boilerplate one has to write.
>
> But then people started trying to build React style component models with
> this and had trouble. At which point, various people in the Elm community
> decided that nesting was a bad idea and advocated strongly for flatness
> with functions being the only decomposition mechanism and those without
> much in the way of architectural guidance. Basically, this was a case of
> the pendulum swinging wildly and the architecture for building complex
> applications seemingly getting cast aside without a replacement.
>
> 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.
>
> For example, our codebase contains a module providing a model and
> corresponding messages and update function for managing the sign up/sign in
> process. It knows how to talk to our server. It knows what validation to
> do. It understands the errors coming back from the server. It knows nothing
> about how to display the data and instead provides a function to fill in a
> ViewData structure that contains the information needed by the view code.
> We can now reuse this logic in a variety of places where we need SUSI
> logic. Each of those hosting cases then routes messages to and from the
> logic using a message case of the form `ToLogic Logic.Msg` and using
> `Cmd.map ToLogic` to promote logic layer messages to view layer messages.
>
> Mark
>
> On Wed, Mar 29, 2017 at 11:50 AM, Juan Ibiapina 
> wrote:
>
>> Where can I find more information about that Config approach? I'm not
>> able to find a way to organise multiple page applications that I like.
>>
>> On Wed, Mar 29, 2017 at 6:24 AM, Peter Damoc  wrote:
>>
>>> If you have a series of pages that each has Cmds and you have these
>>> pages unified under one app, you need to lift each page Cmd to become an
>>> app Cmd.
>>>
>>> There used to be a nesting architecture where this was demonstrated but
>>> now that's been dropped in favor of the Config approach.
>>>
>>>
>>>
>>> On Wed, Mar 29, 2017 at 1:09 AM, Brian Marick 
>>> wrote:
>>>
 I’m having trouble thinking of a scenario in which you’d use `Cmd.map`.

 Is it for a case where you create a `Cmd a` where `a` is something
 different than the usual `Msg`, then transform it into a `Msg`? (When would
 you do such a thing?)

 Or for a case where you want to change the `Msg` constructor that `Cmd`
 “wraps”? (Ditto.)

 --
 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.

>>>
>>>
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>>> --
>>> 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 

Re: [elm-discuss] Cmd.map

[Mark Hamburg]

The config approach pops up various places — e.g., elm-sortable-table — but
isn't as well specified anywhere that I've seen because it doesn't have as
clear a pattern to specify.

Cmd.map (and Html,map) come out of what could be called Classic TEA. The
classic Elm architecture was built to allow decomposition by using tagged
messages to route through the compound model. For example, if you wanted to
have a number of pages, you could have a top level model that served as a
page switcher and it would use tagged messages to route to the current page
(or to discard messages if they weren't bound for the current page). This
worked well though I know programmers who grouse at the amount of message
routing boilerplate one has to write.

But then people started trying to build React style component models with
this and had trouble. At which point, various people in the Elm community
decided that nesting was a bad idea and advocated strongly for flatness
with functions being the only decomposition mechanism and those without
much in the way of architectural guidance. Basically, this was a case of
the pendulum swinging wildly and the architecture for building complex
applications seemingly getting cast aside without a replacement.

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.

For example, our codebase contains a module providing a model and
corresponding messages and update function for managing the sign up/sign in
process. It knows how to talk to our server. It knows what validation to
do. It understands the errors coming back from the server. It knows nothing
about how to display the data and instead provides a function to fill in a
ViewData structure that contains the information needed by the view code.
We can now reuse this logic in a variety of places where we need SUSI
logic. Each of those hosting cases then routes messages to and from the
logic using a message case of the form `ToLogic Logic.Msg` and using
`Cmd.map ToLogic` to promote logic layer messages to view layer messages.

Mark

On Wed, Mar 29, 2017 at 11:50 AM, Juan Ibiapina 
wrote:

> Where can I find more information about that Config approach? I'm not able
> to find a way to organise multiple page applications that I like.
>
> On Wed, Mar 29, 2017 at 6:24 AM, Peter Damoc  wrote:
>
>> If you have a series of pages that each has Cmds and you have these pages
>> unified under one app, you need to lift each page Cmd to become an app Cmd.
>>
>> There used to be a nesting architecture where this was demonstrated but
>> now that's been dropped in favor of the Config approach.
>>
>>
>>
>> On Wed, Mar 29, 2017 at 1:09 AM, Brian Marick 
>> wrote:
>>
>>> I’m having trouble thinking of a scenario in which you’d use `Cmd.map`.
>>>
>>> Is it for a case where you create a `Cmd a` where `a` is something
>>> different than the usual `Msg`, then transform it into a `Msg`? (When would
>>> you do such a thing?)
>>>
>>> Or for a case where you want to change the `Msg` constructor that `Cmd`
>>> “wraps”? (Ditto.)
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> 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.
>>
>
>
>
> --
> Juan
>
> --
> 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.

Re: [elm-discuss] Cmd.map

[Juan Ibiapina]

Where can I find more information about that Config approach? I'm not able
to find a way to organise multiple page applications that I like.

On Wed, Mar 29, 2017 at 6:24 AM, Peter Damoc  wrote:

> If you have a series of pages that each has Cmds and you have these pages
> unified under one app, you need to lift each page Cmd to become an app Cmd.
>
> There used to be a nesting architecture where this was demonstrated but
> now that's been dropped in favor of the Config approach.
>
>
>
> On Wed, Mar 29, 2017 at 1:09 AM, Brian Marick  wrote:
>
>> I’m having trouble thinking of a scenario in which you’d use `Cmd.map`.
>>
>> Is it for a case where you create a `Cmd a` where `a` is something
>> different than the usual `Msg`, then transform it into a `Msg`? (When would
>> you do such a thing?)
>>
>> Or for a case where you want to change the `Msg` constructor that `Cmd`
>> “wraps”? (Ditto.)
>>
>> --
>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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.
>



-- 
Juan

-- 
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?

[Kasey Speakman]

Short of language changes, you could:

* Use the infamous encoders/decoders to emit/parse pascal case.
* Use a header on the HTTP request to instruct the server to assume camel 
case for the request.

Without pre-existing clients, I have the server emit camelCase (a 
serializer configuration option). In a happy surprise, deserialization was 
already case-insensitive (in JSON.NET) so I didn't have any trouble using 
my pascal case objects there.

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] Better syntax for nested pattern matching (destructuring)?

[Matthieu Pizenberg]

Multiple times in my projects, I happen to need nested pattern matching.
Below is a raw extract of code (in an update) showing this need.

Study.ScribblesMsg scribblesMsg ->
case model.study.status of
Study.Progressing steps ->
case Pivot.getC steps of
Study.ScribblesStep ( imageUrl, scribbles ) ->
( Scribbles.update scribblesMsg model scribbles
, Cmd.none
)

_ ->
( model, Cmd.none )

_ ->
( model, Cmd.none )

Basically, this is a specific case of a generic following code:

case f1 var1 of
DataType2 var2 ->
...
case fn varn of
finalVar ->
doSomethingOf finalVar
_ ->
otherwise
...
 _ ->
otherwise

Do you think there could exist a syntax enabling better handling of such a 
case?
Have you encountered one in another langage maybe?

-- 
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] Compiler option to disable camel-case record property requirement?

[Stein Setvik]

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] elm-i18n: convert elm code to PO/CSV and back

[John Orford]

+1 - thanks for this

On Wed, 29 Mar 2017 at 14:04 Felix Lamouroux  wrote:

> Hi folks,
>
> I have updated the elm-i18n tool to automatically convert between elm
> source code and PO/CSV-files.
> https://github.com/iosphere/elm-i18n
>
>
> This is currently "only" a node CLI toolset, but it is already backed by
> elm at its core. In the coming days I will improve the elm code base with
> comments and better types and will probably provide it as an elm-package
> too.
>
> I would greatly appreciate your feedback. The readme also includes a list
> of advantages/disadvantages to the outlined approach, feel free to
> criticise these.
>
> Kind regards,
>
> Felix
>
> --
> 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] elm-i18n: convert elm code to PO/CSV and back

[Felix Lamouroux]

Hi folks,

I have updated the elm-i18n tool to automatically convert between elm 
source code and PO/CSV-files. 
https://github.com/iosphere/elm-i18n


This is currently "only" a node CLI toolset, but it is already backed by 
elm at its core. In the coming days I will improve the elm code base with 
comments and better types and will probably provide it as an elm-package 
too.

I would greatly appreciate your feedback. The readme also includes a list 
of advantages/disadvantages to the outlined approach, feel free to 
criticise these.

Kind regards,

Felix

-- 
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] Bug report (Undefined is not a function!)

[Peter Damoc]

If you want a SSCCE, here it is:
https://ellie-app.com/M5sydznVwXa1/0

This is what you might be doing (the equivalent, of course).

On Wed, Mar 29, 2017 at 9:32 AM, Mark Hamburg  wrote:

> I've now seen something like this a few times. The last time I tried to
> build an SSCCE, the bug went away when I looked more closely so I expect to
> get nasty messages from the bug submission system if I try to report it as
> is, but I figured I would see whether anyone else has seen anything like
> this in an effort to narrow in.
>
> This Elm code
>
> operationHandlers : List (Operation.Op Msg -> Maybe Updater)
> operationHandlers =
> [ handleAccountOperation
> ]
>
> handleAccountOperation : Operation.Op Msg -> Maybe Updater
> handleAccountOperation op =
> case Debug.log "handleAccountOperation" op of
> Operation.Account accountID accountOp ->
> applyAccountOperation accountOp
> |> Maybe.map (updateAccount accountID)
> _ ->
> Nothing
>
>
> produces this JavaScript
>
> var _adobe$adlproj$App_SessionData$operationHandlers = {
> ctor: '::',
> _0: *_adobe$adlproj$App_SessionData$handleAccountOperation*,
> _1: {ctor: '[]'}
> };
> var _adobe$adlproj$App_SessionData$handleAccountOperation = function (op)
> {
> var _p5 = A2(_elm_lang$core$Debug$log, 'handleAccountOperation', op);
> if (_p5.ctor === 'Account') {
> return A2(
> _elm_lang$core$Maybe$map,
> _adobe$adlproj$App_SessionData$updateAccount(_p5._0),
> _adobe$adlproj$App_SessionData$applyAccountOperation(_p5._1));
> } else {
> return _elm_lang$core$Maybe$Nothing;
> }
> };
>
>
> Note the problem in bold: At the point where we construct the list, we
> have not initialized the variable being stored in the list. When we then
> try to call the function at the head of the list, we get informed that it
> isn't a function. Boom.
>
> Reversing order does not fix this (and should not be required to fix this).
>
> Mark
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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] Bug report (Undefined is not a function!)

[Mark Hamburg]

I've now seen something like this a few times. The last time I tried to
build an SSCCE, the bug went away when I looked more closely so I expect to
get nasty messages from the bug submission system if I try to report it as
is, but I figured I would see whether anyone else has seen anything like
this in an effort to narrow in.

This Elm code

operationHandlers : List (Operation.Op Msg -> Maybe Updater)
operationHandlers =
[ handleAccountOperation
]

handleAccountOperation : Operation.Op Msg -> Maybe Updater
handleAccountOperation op =
case Debug.log "handleAccountOperation" op of
Operation.Account accountID accountOp ->
applyAccountOperation accountOp
|> Maybe.map (updateAccount accountID)
_ ->
Nothing


produces this JavaScript

var _adobe$adlproj$App_SessionData$operationHandlers = {
ctor: '::',
_0: *_adobe$adlproj$App_SessionData$handleAccountOperation*,
_1: {ctor: '[]'}
};
var _adobe$adlproj$App_SessionData$handleAccountOperation = function (op) {
var _p5 = A2(_elm_lang$core$Debug$log, 'handleAccountOperation', op);
if (_p5.ctor === 'Account') {
return A2(
_elm_lang$core$Maybe$map,
_adobe$adlproj$App_SessionData$updateAccount(_p5._0),
_adobe$adlproj$App_SessionData$applyAccountOperation(_p5._1));
} else {
return _elm_lang$core$Maybe$Nothing;
}
};


Note the problem in bold: At the point where we construct the list, we have
not initialized the variable being stored in the list. When we then try to
call the function at the head of the list, we get informed that it isn't a
function. Boom.

Reversing order does not fix this (and should not be required to fix this).

Mark

-- 
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.