> > If it then needs to proxy requests through its direct parent - the > AdminComponent - the AdminComponent will contain message like: > > type Msg > = LoadAppleComponentApples > | AppleComponentApplesLoading > | AppleComponentApplesFailure Error > | AppleComponentApplesSuccess Data > ... etc etc for each Component type > > Is this still on par with what you're suggesting? >
Aha, no. See the README for Keyboard.Extra - http://package.elm-lang.org/packages/ohanhi/keyboard-extra/1.0.1 A typical TEA would see something like a single tag for a given component in the parent, and routing messages through to it. So in general I would expect to see something like: case msg of ... Apple msg -> { model | apple = Apple.update(msg) } -- handwavy, you want to catch `Cmd` as well Api msg -> { model | api = Api.update(msg) } -- ditto, deal with Cmd like in Keyboard.extra Then I could see the API supporting `LoadApples` or some such, and getting that message up to the Root by saying `AskForApples`. The root would proxy to the API, and it would use the messages it knows about re: telling AppleComponent about new data - presumably it got its data from somewhere upstream. I might be in vehement agreement with you here - I think you're worried about incidental complexity and I'm worried about coupling. I *really* want someone else to pipe in because I fear I might be sending you on a wild goose chase, but I've spent a lot of time thinking about these things without yet having built something of decent size in Elm (lots and lots and lots of toys though!). In general, though, the idea of a component knowing about the backend API sends chills up my spine. -- 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.
