Hi On Sunday, August 28, 2016 at 2:02:04 PM UTC+3, 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> > . >
I'm struggling with this also, like most of us does. All of the approaches I've stumbled upon so far have their issues unfortunately. > 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.* > I'm not sure why all this `let's not call components "components"` thing started recently. I thinks it's perfectly fine to think in the terms of `components`, `widgets`, parent-, child- and all that stuff. Almost anything on a webpage can be named as a component, having child components and a parent component. It's natural to group and name those things this way, imho. Context matters, of course and it's OK. The issue we have with terminology is `stateful components`(in OOP terms) vs `stateless components`. In React world, this is an issue since React components implemented as classes can contain state. Elm nature tells us that there's not such thing as a `stateful Elm component`. So we always use this term without being misinterpreted - great! So in the Elm world, component is a piece of code that 1) takes some props\params\input 2) generates html as a visible output to the input given 3) pipes the user-generated events up to the appropriate handler In pre-0.17 world we had an easy way to pass the handler(signal address) down by providing some context to the `view` like this <https://github.com/evancz/elm-architecture-tutorial/blob/dev/examples/4/Counter.elm#L56> The simplest thing, like passing a callback in JS. But nowadays(if we're going the fully-featured component path), we need to handle all of the events by generating a Msg, handling that Msg inside the `update` function of the component and then just return some kind of `OutMsg`(or `Dispatch` or `Whatever`) up to the parent. If parent is not interested in this kind of event, but knows that his parent IS, it has to still has to convert it to some `ParentOutMsg` and bubble up the event to it's parent. Now *this* is the real issue that brings ideas like `stay flat for as long as you can` to life, imho. > > 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?* > Still waiting on this page <http://guide.elm-lang.org/architecture/modularity/more.html> of the guide to update. Maybe Evan will come up with a nicer way to handle the wiring and Elm apps could be claimed to scale up easily. I don't think the examples are bad because I'm not sold on the `stay flat` or `start flat` and the best argument against that idea is how clear and self-contained Conter.elm <https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/Counter.elm> is, and how easily it's being reused in two different apps in the `/nesting` folder. > > 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.
