> > 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. >
I really like this phrasing. Crucially, between 0.16 and today, *we learned that a Model-View-Update triplet is the wrong unit of composition for Elm applications.* It's important that people understand the historical context here: many of us have tried this, and found that composing individual functions was both simpler and consistently led to a much better experience. I've laid out my advice for specifically how to do that here <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/> . 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. > I'll reiterate that thinking about application organization as "composing TEA-shaped units" is neither officially recommended nor what Elm is designed for, and many folks have tried to fit that round peg into the square hole and reported that it led to pain at scale. Specifically I've had many people tell me that refactoring according to this advice <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/> led to a much better experience. Exploring can be fun, but if you're looking for a good way to organize your Elm applications, be aware that this particular path has been explored before - and there's a signpost next to it labeled "WARNING: PIT OF SNAKES AHEAD." ;) -- 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.
