. > > > 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. > > Which could be a sign that the remove button would be better modeled as a decorator and not something belonging to a composable counter in the first place ? :-)
-magnus > > 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.
