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