Thanks for sharing. The additional OutMsg from the update function was a real eye-opener for me. I have no experience (yet) in scaling this.
One thing I find somewhat odd in your (second) example is that you define the OutMsg type in the Child: Wouldn't it be more logical to always define/ manage Message types in the component that actually handles these Messages and has an update function for this? In your example, the parent is the Owner of the OutMsg: the parent has separate update function(s) for dealing with each of the OutMsg types. To prevent circular import references (parent importing child, and child importing parent), one would need to separate out parent and child into separate files (as in the - not 0.17 yet - example of the Players in the Elm docs). That way, any child component of parent can import the OutMsg type (maybe ParentPublicMsg would be a more appropriate name). Then the parent exposes this type for any child that wishes to send out such a message. When you then expand OutMsg with, say AskForMoreAllowance, you add it to the parent-owned type + to the parent's update function. Children can be updated to respond to the new OutMsg type, but better still: any child component which is not updated will continue to work. My specific use case: I have a list of children with a number of internal messages (e.g. updates on each child). One of the functions I need to implement is 'RemoveMeFromList', which is a button on each child. This message type can only be handled by the parent, through removing child from list and no longer rendering it in view. -- 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.
