>
> To recap:
>    
>    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/>
>    ."
>
>
>    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.
>
>
Richard, I think it's only your broad use of the word "*Elm Applications*" 
that is a little misleading for some folks.  When you say "Elm 
Application", maybe you mean: Elm applications like we write at NoRedInk 
(non-SPA applications). ie. each page of the web app is served from a ruby 
on rails server, and that page may include an Elm app(s). In your context, 
I agree with your advice.

When other folks are talking about "*Elm Applications*", they're talking 
about Single Page Applications. In the context of an SPA, the 
Model-View-Update triplet will indeed be a unit of composition for an app - 
each logical page within the app will likely be a triplet. Of course, your 
advice still applies to the individual "pages" within an SPA, but not 
necessarily the overall architecture itself.

The distinction is important, because it's obviously confusing folks. This 
isn't the first time I've seen a dev misunderstand your statement - 
*Model-View-Update 
triplet is the wrong unit of composition for Elm applications *- and 
attempt to write an entire SPA without using a triplet. Very painful stuff. 

I know that's not what you're advising, but without stating that 
explicitly, devs are left to fill in the blanks themselves.



On Wednesday, April 19, 2017 at 1:27:09 PM UTC-4, Richard Feldman wrote:
>
> so, the Model-View-Update triplet *is NOT* the wrong unit of composition 
>> for Elm applications? :) 
>>
>> > 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.
>>
>>
> To recap:
>
>    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/>
>    ."
>    2. 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.
>
> In (1) I am saying that I expect you'll have a better time if you think 
> about building Elm applications in terms of *composing individual 
> functions*, not in terms of composing Model/View/Update triplets.
>
> In (2) I am giving an example of a very specific set of circumstances in 
> which a separate Model/View/Update makes sense.
>
> In summary: "Here is a useful but complex tool. Always reach for a simpler 
> one first." 
>
>>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to