Richard, 

this is what you said about composing update functions:
 

> I'll reiterate that thinking about application organization as "composing 
> TEA-shaped units" is neither officially recommended nor what Elm is 
> designed for...

 

> > How do you propose to split the functionality one has in a highly 
> complex app with a lot of pages without using those triplets?
> I don't haha...I just defended their use a few posts ago, complete with 
> the specific example of the reusable signup form.


>    1. Later 
>    <https://groups.google.com/d/msg/elm-discuss/Lo6bG96zotI/-GOgsoHsDgAJ> I 
>    pointed out an example of when it would be useful to use Html.map and 
>    Cmd.map to make a reusable signup form, and for that use case it 
>    happened to make sense to have a separate model, view, and update.
>
> *I'll use your own words:*
 

> this level of doublespeak is really uncool


I thought I've understood this but I'm more and more confused by what 
you're saying:  

> Crucially, between 0.16 and today, *we learned that a Model-View-Update 
> triplet is the wrong unit of composition for Elm applications.*

repeating one more time:

>
>    1. Earlier 
>    <https://groups.google.com/d/msg/elm-discuss/Lo6bG96zotI/0ak6T2DaDgAJ> I 
>    said "between 0.16 and today, *we learned that a Model-View-Update 
>    triplet is the wrong unit of composition for Elm applications...composing 
>    individual functions* was both simpler and consistently led to a much 
>    better experience. I've laid out my advice for specifically how to do that 
>    here 
>    
> <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/>
>    ."
>
> Well 0.16 -> 0.17 is switch from Effects to Html.program with pure 
individual functions init, update, subscribe, view. Going back to my first 
quote of you. And changing words "TEA-shaped units" with "individual 
functions" we get:  I'll reiterate that thinking about application 
organization as *individual functions* is neither officially recommended 
nor what Elm is designed for...

My point that there's a simple way to scale Elm applications by abstracting 
> at the function level has gone uncontested for awhile in this thread


It did indeed... init update and subscribe are actually function. Looks 
like I still miss something. Are you trying to say that Cmd.map is not 
function or what? 
 
*I'll use your own words:*
 

> this level of doublespeak is really uncool

 
on different topic:

 many of us have tried this, and found that composing individual functions 
> was both simpler and consistently led to a much better experience.


Not even pointing out all nonsense: I just don't see any of them here 
<https://groups.google.com/forum/#!topic/elm-discuss/WDDrFq-uP58> just yet. 
I hope they will shop up. Please don't start sending links to same Reddit 
thread once again.

I hope you don't think anyone will actually comment this one at all:

I've seen agile teams that could generate lots of small changes but when 
> faced with needing to do something big found themselves profoundly stuck.
> In 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.

Reply via email to