Thanks for getting back Josh. But I'm still wondering a few things: Anywhere I was currently wishing to call the API from the child, I would > instead signify to the root that I would like to take an equivalent action > and be notified of the outcome.
Can you give me an example of this in Elm? I'm curious of how you are "signifying" to the parent component. I don't think a component should really give a crap what the backend > happens to do. It should care about the data it is responsible for. It > should tell someone else to do stuff with it. The item with the single > responsibility of shuffling data to/from the backend can take care of it > and tell this component how that worked out. Seems good to me > architecturally, but then I haven't actually *built* the thing I'm > describing yet either :) 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. On Tuesday, July 5, 2016 at 4:09:08 PM UTC-4, Josh Adams wrote: > > >> - How would you choose to send up messages to the root? >> >> Anywhere I was currently wishing to call the API from the child, I would > instead signify to the root that I would like to take an equivalent action > and be notified of the outcome. > >> >> - What is the benefit of wrapping the API calls in a component? >> >> I don't think a component should really give a crap what the backend > happens to do. It should care about the data it is responsible for. It > should tell someone else to do stuff with it. The item with the single > responsibility of shuffling data to/from the backend can take care of it > and tell this component how that worked out. Seems good to me > architecturally, but then I haven't actually *built* the thing I'm > describing yet either :) > > >> I hope I'm not giving the impression that the API calls are randomly >> spread throughout nested components willy-nilly. All api requests and >> models are tightly encapsulates in an API module. If a component wishes to >> make an api request, it must import the module. >> > > My general assumption (which seems to hold true pretty well!) is that by > the time someone's posting on elm-discuss, they're already pretty good at > making good decisions, so I did not get that impression at all! I just > think it's sad that a component has to think about the API and/or interact > with it. Instead, it should just say "gosh it would be swell if someone > handled fetching or storing this data for me" and "oh look! New data to > care about!" That's my feeling at least. > > I like this idea of creating a "Service TEA component" - the thought >> hadn't crossed my mind. The component could have a model which manages the >> "CurrentUser" state of the application in a central location. Is this what >> you were alluding to? >> > > Yeah. I've seen a lot of people refer to passing things like that all > through their application, and in general my feeling has been that it was > probably not a good thing that they needed to. Still not as bad as some > early Rails 'solutions' to the "current_user" problem (I'm looking at you, > class attributes....geezus) > -- > Josh Adams > -- 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.
