I will say that one thing that feels odd about the top-level request manager approach is that it uses containment as the way to hook things up. That works fine with one piece filling that role but would get messier with two. But with signals gone, containment is the primary thing we have left.
Mark > On Jul 5, 2016, at 1:09 PM, Josh Adams <[email protected]> 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. -- 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.
