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


Gah, I wonder if that's what happened in Oliver's case. 😬

Let me try to clarify:

   1. Nesting Model-View-Update is a useful technique under the right 
   circumstances. One example is reusing complex things like signup forms. 
   <https://groups.google.com/d/msg/elm-discuss/Lo6bG96zotI/-GOgsoHsDgAJ> 
Another 
   example is a network of independent mini-apps like what Oliver is building. 
   And yes, absolutely, a third example - most likely the most common example 
   in use today - is going from the top level of a SPA to a logical "page" 
   within that SPA.
   
   In practice, pages almost always want their own model, view, and update, 
   and this technique is absolutely the right choice for having the top-level 
   application delegate to one of these "pages" depending on the current 
   route. (Note that this is true in Elm 0.18, but there may be an easier way 
   in 0.19 once asset management opens some new doors. However, even if that 
   happens, this will still be a useful technique to know about and use under 
   the right circumstances!)
   2. My objection is specifically to what I read in the OP, which suggests 
   that this situationally useful technique ought to be used pervasively:
   
   *In Elm 0.16, TEA was all about being composable. The examples focused 
   on things like going from one counter to multiple counters. [...] But 
   somewhere along the way, portions of the Elm community, including Evan, 
   seem to have swung hard against composing TEA units and now just recommend 
   using functions*
   
   Composing together Model/view/update triplets to build your application 
   has never been what the Elm Architecture was "all about."
   
   The reason *"The examples focused on things like going from one counter 
   to multiple counters"* is no longer true is that Evan took those 
   examples down once he realized they'd been giving people this wrong 
   impression. He'd intended to convey "check it out - here is a useful tool 
   to include in your toolbox" but a lot of readers (quite reasonably) read it 
   as "this is the right technique to use whenever I want to build something 
   reusable, even something as simple as a counter" - which was never a 
   message Evan intended to send.
   
   To be super clear, even though I think this technique is useful in the 
   right circumstances, I disagree with the notion that "composing TEA units" 
   is what the Elm Architecture is "all about," and I again disagree that the 
   right way to think about organizing the content of "pages" within an 
   application is in terms of composing model/view/update triplets. It really 
   is all about the individual functions!
   
I hope this clarifies...I totally appreciate that my attempts to share what 
I've learned over these past few years do not always come across as I 
intended, and I am extremely grateful for the direct and honest feedback. :)

>

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