As the OP, I agree. Don't do this. We quickly abandoned this functionality after we wrote it. One of those posts I would I could remove...
On Saturday, October 22, 2016 at 10:50:38 AM UTC-4, Richard Feldman wrote: > > On Friday, July 15, 2016 at 9:49:41 PM UTC-7, Erik Lott wrote: >> >> Max, build a non-trival 15+ page SPA within a single elm component, and >> tell me how that goes :) >> >> On Friday, July 15, 2016 at 8:08:23 PM UTC-4, Max Goldstein wrote: >>> >>> Allow me to suggest that this approach is *totally overkill*. It might >>> not be, but this is something Richard and I were discussing last night at >>> the meetup. If you come from React, everything is a component, so you reach >>> for them. But, for many uses cases, nesting TEA is unnecessary. Go ahead >>> and make Model and Msg huge types. The compiler will keep you from breaking >>> things. >> >> > I agree with Max's original statement. I would give each logical "page" > its own Model, View, and Update, and that's probably it. > > This is effectively what we've done at NoRedInk with our *50,000 lines of > production Elm code*, and it has been extremely rare to find examples > where nesting an entire model, view, and update further than that was a > good idea. > >> When you're building something at a larger scale like a single page app, >> that contains various layouts, menus, & pages - which contain several >> components per page - you'll need components to keep your code organized, >> maintainable, and easy to understand. > > I strongly disagree with this. > > Every time I've followed this approach I've regretted it. It introduced > substantial communication overhead, making my code harder to work with, and > got me vanishingly little in return. When I've chosen not to do this, and > to instead focus on localized refactors like "this record is too big, so > I'll split it into a few smaller records" or "this Msg is too big, so I'll > split into a few smaller union types," the code has ended up much easier to > maintain at scale. > > My strong impression is that the pattern presented in OP is a band-aid > over a self-inflicted wound. I would advise against using it, and instead > *choosing > not to self-inflict that communication overhead in the first place*. > Scaling by thinking in terms of "components" is a natural fit for React, > and an extremely poor fit for Elm. > > Don't do this to yourself! > -- 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.
