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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
