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|sort:relevance/elm-discuss/sgE5k9y2ihg/AxsmLNbgAQAJ>, components <https://groups.google.com/forum/#!searchin/elm-discuss/component|sort: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.
