Problem solved! Post deleted (thumbs up) 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
