I really feel you get the whole idea, brilliant! I don't really know what I should add to that but at first - *Package was taken down on my own request.* At this point I agree that term component even though it might make sense from some point of view isn't really the best choice. Also in elm-dev I have described our use-case briefly which I believe makes it clear why I some people might want to structure app in terms of Parent-Child modules.
I would also question the use of the term "polymorphic" to describe the > more generalized 100% agree. I'm not happy with that name either. I think that using commands to send messages to parents is probably a > dangerous choice In most cases this is useful for async actions anyway (like component requesting data parent knows how to get for instance). Sometimes you don't know who and if anyone is interested that you (bottom update) did something. Good example might be http://package.elm-lang.org/packages/zaboco/elm-draggable/latest <http://package.elm-lang.org/packages/zaboco/elm-draggable/latest> which is also sending Cmd. If you need anything else just expose Msg with constructors (Msg(..)) from children. That way you can pattern match on children's Msg in parent like: update msg model = case msg of let newModel = ChildMsg childMsg = if childMsg == Child.Msg.Magic then { model | itHappened = True } else model in (newModel, Cmd.none) |> Component.update child childMsg (hope that code is clear) Anyway there are some questions how to do some things for sure. I'm really happy someone have look at it and was able to understand it that well. Appreciated. On Tuesday, April 18, 2017 at 5:39:16 PM UTC+2, Mark Hamburg wrote: > > Marek Fajkus's original announcement was on elm-dev but that list tends to > become disapproving of discussions fast, so I'm moving over to here to > discuss it. The post suggested that it was in the Elm package library but > it seems to have been pulled, so I will point to the Github repository: > > https://github.com/turboMaCk/tea-component > > I've read the ReadMe but haven't looked at the code or the examples beyond > the ReadMe. > > Two things immmediately struck me: > > 1. It seems like an interesting idea to wrap the embedding up into a > single structure. It doesn't really reduce the boilerplate that much but it > makes it seem simpler because it isn't spread out and the number of type > annotations needed is smaller. I see it as a more elaborate form of lenses > — a structure I've started pushing through my code to consolidate various > idioms (and to reduce copy-paste-change errors when I've got multiple > record fields of the same type and hence the type system won't help me when > I miss a change). > > 2. This isn't really about defining components — a hot button word with > some people (go read the elm-dev thread) — so much as it is about defining > embeddings of one TEA-shaped unit within another. > > Side note on TEA: In Elm 0.16, TEA was all about being composable. The > examples focused on things like going from one counter to multiple > counters. This carried over into Elm 0.17 where Cmd.map and Sub.map were > clearly targeted at this sort of composition and Html.map both helped with > the composition and with making Html.Lazy work in an environment with > composition.(*) 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. This ignores the fact that in many cases, > the units can't be encapsulated into single functions. On the other hand, > the accompanying piece with these functions is generally Config arguments > and what this package does is provide a useful standard Config and > functions to work with that Config when embedding. > > Turning back to the package in question, I would also question the use of > the term "polymorphic" to describe the more generalized case in that the > thing it describes can't really be used in multiple contexts as presented. > Still, it's good to show that the pattern fits with variations on > TEA-shaped units. > > Finally, while it was also interesting to see the material on action > bubbling, I think that using commands to send messages to parents is > probably a dangerous choice since there are few if any guarantees regarding > delivery order. Our solution has been to replace commands with out messages > that subsume commands as one special case. This has given us a lot of > flexibility to handle notifications — e.g., the login component can report > back to the parent on login success, a modal process can report if > canceled, etc — but it does involve more boilerplate. I may see whether I > can adapt Marek's approach to this more general embedding mechanism. > > In any event, I recommend that those interested in ways to structure large > Elm programs go look at this. It doesn't radically change anything but it > could be a better way to express the composition of TEA-shaped units. > > Mark > > (*) Or it would if it weren't for a bug where some nesting of the two > leads to a type system violation and thence generally a runtime error. > > > -- 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.
