Richard, just to clarify, when you say "pages", are you referring to server side rendered pages that each contain an Elm app, or a large Elm single page app that handles routing internally?
On Tuesday, August 9, 2016 at 7:54:24 PM UTC-4, Richard Feldman wrote: > > But passing the callback down through the chain of nested components is >> ugly, fragile and may not even work if two components are not in the same >> parent-children chain. >> > > Not quite sure if that's what this is saying, but a good rule of thumb is > that Msg should never have a function in it, and neither should Model. > > Maybe I don't understand the Elm Architecture, but as far as I know every >> Elm module has it's own model, view and the update function. >> > > For our (enormous) Elm code base at work, most pages (as in an individual > URL an end user can visit) have one model, one view, and one update > function. There is no "parent-child communication" on these pages. > > We had Elm in production for months before we encountered the first time > it was a good idea to have a "parent-child" relationship, and it was over 6 > months (and well over 10,000 lines of Elm code) before we found the second > case where it was a good idea. > > Here is what I recommend: > > 1. For a given page, start with one model, one view, and one update. > 2. If one of those (model, view, or update) gets too big and starts > feeling unwieldy, *subdivide only that thing.* For example, if view > feels too big, split it into some helper functions but *don't touch > model or update.* If update feels too big, same thing - split out > helper functions but don't touch the view or model. If your model feels > too > big, *reorganize only the model*. Split it from one record into some > nested records, but don't rearchitect update or view. > 3. Any time you find yourself thinking "I bet this will be nicer if I > split it into its own model/update/view" your next thought should be > "whoops! That's a classic beginner mistake. My code will actually be worse > if I do that. Glad I didn't do that!" (It's an easy trap to fall into - I > fell into it myself, and fell hard, as a beginner.) > > Basically, whenever I meet someone who is new to Elm and asking about > parent-child communication, what I really want to say is "a parent-child > relationship in an application is very rarely the right tool for the job, > and is almost certainly not what you want as a beginner. How can I help you > avoid falling into the same trap I fell into when I was just starting out?" > :) > -- 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.
