The kind of message you describe in your example is definitely something that should be owned by the parent. It has more to do with the parent component than the child. It could definitely be moved to the child with a name change though. "Retire" or something like that.
The motivation of having the OutMsg on the child in general is to allow reuse of the child components. Take a "card" component, for example: you might have multiple components with varying content, but all producing the same message. You might also be using the component in multiple places. In that case, you would have to define the OutMsg on the child anyway, since otherwise you'd have a conflict between returning ParentA.InMsg and ParentB.InMsg. There are multiple ways to structure this, but my experience tells me that the child should own all messages it consumes and produces. On Tuesday, June 28, 2016 at 5:12:23 AM UTC-5, Wouter In t Velt wrote: > > 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.
