My take on it is - the standard "counter" examples are used not just in Elm but in lots of virtual-dom-based frameworks, I used to hate them as well but now I see their usefulness as a "Short, Self Contained, Correct Example" in which the domain has been reduced to the bare minimum. And I have to say I found the progression from counter -> pair of counters -> list of counters was instructive and sticks with me -- even if it wasn't the only way I learned Elm. But beyond the basic mechanics of updating nested state, it doesn't get you very far.
Part of the challenge with tutorials built around "realistic examples" I think is that people look at the final code and are tempted to think that's a model for how to start out, when of course it's a whole organic process with many many decisions behind how the code got to that point, and what makes sense in that case may not in another. I am very glad we have the videos (and code) from those code sessions now to study, but my understanding is they are focused on building reusable components and specifically on the interface between those components and your app (have not looked at them yet myself so I could be wrong). This seems different to me from structuring your app's modules. In your app, any given parent references child Model, init, update, view, and sometimes Msg directly, and there are well-worn paths for doing this, made quite easy with Html.App.map, as well as emerging conventions for passing back messages to the parent from the child (OutMsg, etc.). For components on the other hand, the interface has to be worked out in terms of what the component hides from your app, and there are different approaches. So I don't see the process of app development as aiming at 'decoupling' your whole app into components, that seems to add complexity where it's not needed. (That said, there are times when I have done things like what you suggest with the counter subviews -- parameterized them by passing in msg or msg constructors -- when I have two variants that are otherwise identical. I always feel dirty doing that though and try to keep that to a private view function close to where it's called. ) On Sunday, August 28, 2016 at 7:02:04 AM UTC-4, Wouter In t Velt wrote: > > Something I have been struggling with for quite some time (coming from > React and Flux) is how to scale. There are various posts on this forum > related to the topic, e.g. Design of large elm apps > <https://groups.google.com/forum/#!topic/elm-discuss/_cfOu88oCx4>, parent > child communication > <https://groups.google.com/forum/#!searchin/elm-discuss/parent$20child%7Csort:relevance/elm-discuss/sgE5k9y2ihg/AxsmLNbgAQAJ>, > > components > <https://groups.google.com/forum/#!searchin/elm-discuss/component%7Csort:relevance/elm-discuss/H1AUQelu78c/rokETXXRCQAJ> > . > > On structuring apps, I found the elm-sortable-table and the autocomplete > video - shared by Peter Damoc in this thread > <https://groups.google.com/d/msg/elm-discuss/_cfOu88oCx4/AIq5Z3iTCAAJ> - > to be very helpful, as well as advice here > <https://groups.google.com/d/msg/elm-discuss/VBSYiMnftzQ/I3BU8jQTBQAJ>. > > My summary of the advice is more or less: > > - Forget about about "components": the term is very confusing, means > very different things in different contexts. > - Start to build with 1 Model, 1 Msg, 1 update, 1 view > - As soon as one these becomes too big, seperate that one out to a > view-helper, or update-helper etc > > This very much feels like a "top-down" approach: the module you start > with remains on top. Put everything in there, and split out if needed. > I keep reminding myself to stop trying to keep pieces of each of the 4 > building blocks (Model, Msg, update, view) bundled as I separate out. That > it is fine to e.g. just put a piece of view code in a separate place - > *without > trying to bundle it with corresponding pieces of Model, Msg, and update.* > > Now I am not sure that my take on "how to do stuff" is the right way, but > it does seem that the *multiple-counters example in the guide teach us > exactly the opposite pattern*. > *Do the multiple counter examples in the guide put us on the wrong foot?* > > We start out with one counter being the top module, and then we add a > wrapper *on top* to handle multiple instances of this counter. > To make matters worse: the multiple counter examples introduces the kind > of opaque nesting and messaging structure that is being discouraged here: > The parent does not know anything about each child counter, parent has its > own Msg structure etc. > After scaling, the counter now has in effect become something that looks > and smells very much like a component. > > Just the other day I realized that much of my struggle with scaling came > from stuff I picked up on day 1 of learning Elm, with sinful thoughts such > as: > "Hey, this counter thing in Elm is just like a reusable UI element. Just > like a react component, with state and all. Looks like a great way to > scale: start with building reusable stuff, each with its own Model, Msg, > update and view and then weave them all together in my great big app later." > > For newcomers to Elm, *wouldn't it be better to change the scaling from 1 > to multiple counters in the guide in a different way? * > E.g. > > 1. Build everything in 1 module, e.g. save a copy of counter.elm as > counter-list.elm > 2. Change every building block (Model, Msg, update, view) one at a > time, and upgrade each to handle multiple counters > - Suggested order: Model, view, Msg, update > 3. After that, separate out the view (and only the view) of an > individual counter, with signature like "msg -> msg -> Int -> Html msg" > - with the two msg's being for increment and decrement > > Such an alternative scaling approach seems more in line with what is > advocated in this forum. > > Curious to learn what everyone here thinks: > Do the multiple counters example teach us a wrong scaling approach? Or it > it just my react-flux instinct getting in the way? Or did I interpret the > examples in the guide in the wrong way? > -- 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.
