Mark: That's lead me to think about but not yet write a command alternative that > could also handle tasks that didn't need to be routed back to the > originator and that could be used to send messages to the top-level (or > elsewhere).
I think you've nailed it. The suggested ELM architecture doesn't easily allow for application specific communication from the lower nested components to the upper components. There are times when in the scope of an overall architecture, you'd like to return some type of application wide recognized event/message back up the update stack, and have any interested ancestor component react to it... This is essentially how Commands function. Commands are a globally recognized type, that are returned up the stack, and although they may carry a local message type with them, the command itself is never returned or reused. The Command reaches the application root, and is processed by the core language. Like you said: I think what we need (or at least what I need) is our own Application specific type to return up the stack instead of Cmd. An "Event" union type possibly? And CmdEvt tag could wrap the native elm Cmd, and be unwrapped at the root. type Event = CmdEvt Cmd | MsgEvt | Unauthorized | LoggedIn User | ConfirmPopup CancelMsg OkMsg .. etc Page changes (aka Routing) might also be another place where this would be useful. I'm entering elm at 0.17, so I haven't had the chance to work with signals, mailboxes, etc. On Tuesday, July 5, 2016 at 4:24:59 PM UTC-4, Mark Hamburg wrote: > > 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] <javascript:>> > 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] <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.
