>
> 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