What do you think about using pattern matching to filter out necessary messages in the parent?
Based on the solution (gist) <https://gist.github.com/pdamoc/1c8cacb49e13727af9d6eb0e40faf63b i> introduced in this thread <https://groups.google.com/forum/?nomobile=true#!topic/elm-dev/VkFTibNpJdo>: https://gist.github.com/scarfacedeb/a6d84f9752eb4219ae451aaf5a4763b7#file-counterlist-elm-L55 I like it, because it keeps `update` function flat and I find it easier to understand and update. Also, with the components nested 2 or more levels, it's relatively simple to add pattern matched entry to the parent update, without the need to manually pass the message to the parent through multiple children. But it makes it more difficult to determine where the action is taking place, but in my app, most of the main messages are handled at the same level, and so if it's not in the immediate child component, then it's probably a good idea to look at the current Page parent component. On Tuesday, June 14, 2016 at 11:09:16 PM UTC+3, Mark Hamburg wrote: > > For the parent/child communication problem, the approach of returning a > triple has felt the best to me as well of the choices I've seen. > > I note, however, that this is different from the old list of counters case > where we needed to signal remove from the view cluster for the counter. In > the general parent/child case, something happens in the child that calls > for notifying the parent. But in the removable counter case, nothing has > happened in the counter model. It's just that the view cluster needs a way > to route messages to both the counter model and the container model. > > Mark > > On Jun 14, 2016, at 10:46 AM, Magnus Rundberget <[email protected] > <javascript:>> wrote: > > here's a short post/example for solving child -> parent communication > using plain old return values from the child component to the parent > component. > http://folkertdev.nl/blog/elm-child-parent-communication > > > On Tuesday, 14 June 2016 15:27:50 UTC+2, Adam Waselnuk wrote: >> >> This is the exact thing I am stuck on right now in my upgrade to 0.17. It >> is great to see three approaches outlined here, but would it be possible >> for anyone to share some code examples? I am struggling to follow the >> conversation a little bit but seeing some code could clear things up. >> >> On Friday, June 10, 2016 at 1:02:32 PM UTC-4, Andrew Volozhanin wrote: >>> >>> Hey everyone, >>> >>> Does anybody know what’s the preferred way to refactor passing context >>> with addresses into child components during migration from Elm 0.16 to 0.17? >>> >>> In particular, I have *Filter* component that takes context with 2 >>> addresses: >>> one for internal actions (Tagged with *UpdateFilter*) and one for >>> “external” action (*Submit*) that is handled outside of the component. >>> >>> With 0.16, it looked something like this: >>> >>> type alias Context = { actions: Address Action, submit: Address () } >>> >>> update action model = >>> case action of >>> UpdateFilter value -> >>> { model | query = value } >>> >>> view : Context -> Model -> Html >>> view = context model >>> form [onSubmit context.submit ()] >>> [ input_ model.query context.actions (\value -> UpdateFilter value) >>> ] >>> >>> >>> But 0.17 doesn’t have addresses anymore, and I’m a bit lost at how >>> should I implement this. >>> >>> I’ve found example app that is in the middle of the refactoring, that >>> imports necessary “external” actions into the child components directly and >>> sends them, >>> but I don’t like that because it breaks the principle that child >>> shouldn’t know anything about its parent. >>> (See: >>> https://github.com/rogeriochaves/elm-peer-tweet/blob/master/src%2FNewTweet%2FView%2FNewTweet.elm >>> ) >>> >>> What’s the best practice in such cases now? >>> >> -- > 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.
