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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to