Josh, I took a moment and read those articles. They're both a great, but they're only discussing communication between direct parent and child components. This type of interaction is fairly easy to model.
I want to understand what you're saying because it seems I'm missing something. Let's say we're 3 nested components deep. The deepest child wants to load a resource. Rather than creating a http Cmd directly, the child should return a message to its parent asking for the resource. That parent would then also repeat this process and ask it's parent for the resource. Eventually the message arrives at the root component, and the root component can generate the Cmd necessary to fetch the resource - whether that is from an http request, or a mock service. Is this what you're suggesting? On Tuesday, July 5, 2016 at 5:01:19 PM UTC-4, Josh Adams wrote: > > Can you give me an example of this in Elm? I'm curious of how you are >> "signifying" to the parent component. >> > > I can't easily, but in general brian hicks' recent articles on > parent<->child communications should give you an idea of how you might do > it. > > >> I agree, and this is what the current Api module does - it encapsulates >> all communicating with the api, structuring and serializing/deserializing >> json requests, etc. For example, to get some data from the api, you might >> make a request using the API module like this: >> >> Api.getHeroByName "bruce wayne" >> >> The issue is not necessarily communicating with the api itself, but >> managing a potential 401 or 408 error (timeout). The Api module is >> available globally to all nested components, but those particular errors >> need to be managed at the root of the app... and this is the crux of the >> problem. >> > > So for me, I think you haven't found the end of your edge cases going down > this path. Among other things, I can imagine you might want to swap out > the API for a mock. If you just have your components tell the parent "I > wish this thing happened!" then that's not a problem - change some code in > the parent, swap out the mock, it suddenly handles those requests. If > instead they all call to the Api module, then you're going to have a bad > time. > > I also think it's reasonable that you might want your app at the top level > to be able to signify to the user "I'm talking to a remote service" and if > that's not at the top then you'll still have to have the children > ultimately tell the parent about that, in which case they might as well > have just asked someone else up top to do the work in the first place. > > So my thoughts would be that your child might return (Model, Cmd Msg, > DoThisThing GetHeroByName "bruce wayne") and then it would just handle the > updated data it got later on. It *probably* shouldn't even care, on its > own, whether or not this succeeded. > > There's clearly a lot more that would need 'fixing' in that (i.e. the > children should probably be able to tell the API what message they want > sent out after a success, a la your typical Http requests), but in general > this feels good to me. YMMV. > > Joshie > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
