I wrote about a generalization of that pattern a week or so ago, in case you're interested: https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98
Another pattern that seems very popular is to have the child's update return the signal to the parent (in your case, a Bool might work -- should I or shouldn't I be removed?) -- Brian Hicks has a great & entertaining blog post about it here: https://www.brianthicks.com/post/2016/06/23/candy-and-allowances-parent-child-communication-in-elm/ best, Alex On Thursday, July 7, 2016 at 7:51:01 PM UTC-4, Mark Hamburg wrote: > > Yes, the view would return Html parentMsg. The signature would be > something like: > > view: (ChildMessage -> parentMsg) -> parentMsg -> ChildModel -> Html > parentMsg > > Note that parentMsg is parameterized. > > Mark > > On Jul 7, 2016, at 3:27 PM, Sandi Dušić <[email protected] <javascript:>> > wrote: > > Thank you Mark! > > One way to do this is to extend the view function with two arguments: one >> is a function to map the counter messages to the parent message space and >> the other is the parent message that the remove button should send. > > Would the child view then return Html ParentMsg? In reality, my components > are more separated in depth, by four levels. Bit ugly, but seems it's all > we have right now. It actually appears elegant in contrast to my approach. > > 2016-07-07 21:18 GMT+02:00 Mark Hamburg <[email protected] <javascript:>> > : > >> We're still awaiting an official answer from Evan. In the meantime, the >> best answer I've seen from the standpoint of not contaminating the counter >> messages and update function with something that they don't care about is >> to put the complexity in the view function which is, I would argue, where >> it belongs since this it's a view layout issue that forces the remove >> button to be included in the counter view. One way to do this is to extend >> the view function with two arguments: one is a function to map the counter >> messages to the parent message space and the other is the parent message >> that the remove button should send. >> >> Mark >> >> On Jul 7, 2016, at 10:50 AM, Sandi Dušić <[email protected] <javascript:>> >> wrote: >> >> In Elm 0.16 the Architecture tutorial had one more button list example >> <https://github.com/evancz/elm-architecture-tutorial/tree/e263cc04298a309251a148805ae8432130bd3821/examples/4> >> (I >> dug that up from an old commit), aside from this one >> <https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/2-counter-list.elm>. >> >> Each counter would have it's own remove button which would remove that >> exact one when clicked, unlike in the simpler example with a sole remove >> button that removes the first counter. This was accomplished by passing two >> addresses to the counter view, one for it's own actions and another which >> it's father component (CounterList) handled, used for signaling removal. >> >> I did the exact same thing in my application. I have a bunch of small >> components in a big component, and the big component needs to know when one >> of the small ones has been clicked. How do you do this in 0.17? Is it >> impossible, since they removed the example which is supposed to implement >> it? >> >> This is the only thing I can think of: Add the message that needs to be >> sent upwards to the big component to the message union of the small >> component (in the CounterList, this would mean Counter.Msg has Remove). >> When the big component gets a small component action, it would first check >> with an if whether it's the one it needs to handle (if msg == >> Counter.Remove then ...). If so, it can handle it (remove the Counter), >> otherwise it would just regularly pass it to Counter.update. >> >> To me that seems like it goes against the principles of Elm Architecture. >> You can no longer treat components (and especially their actions) like >> black boxes, but rather you have to tear them apart in a way. They cannot >> fully define their interface. I don't know, it's just weird. >> >> If there's a way to define custom subscriptions they might be leveraged >> to solve this, but I don't see a way to do that in the API. I apologize if >> this is a silly question, 0.17 is still new to me. >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Elm Discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elm-discuss/H1AUQelu78c/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- 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.
