The first option feels repugnant from an encapsulation standpoint. I've built the second option and it works but it increases the amount of boilerplate in hierarchical systems because we now have three results to deal with in update functions. 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). That said, once one gets into replacing Cmd, the API request model makes a lot of sense.
Mark > On Jul 5, 2016, at 5:46 AM, Erik Lott <[email protected]> wrote: > > My app has several layers of nested components. Various components throughout > the tree will need to interact with our API via http requests. If any API > request returns a 401 - Not Authorized error, or a Timeout Error, the error > needs to bubble up to the root component where is can be handled > appropriately. > > What is the most idiomatic way of dealing with this? > > 1. Parent should pattern match against important child messages: Reference > This could work, but would be unreasonable in this case. The root component > would need to match against every failing api http request made by every > child, grandchild, great-grandchild, etc, component in the tree. If a single > pattern is missed, the app would be in an error state, so this is prone to > mistakes. > > 2. Nested Components return additional info from the "update" function: > Reference > Each component returns an additional value from its update function like this: > update : Msg -> Model -> (Model, Cmd Msg, SomeInfo) > > The parent component could inspect the returned "SomeInfo" value from its > direct children, and act on that information if necessary. In my case, any > nested component that makes http requests to our API would be responsible for > returning a APINotAuthorized and APITimeout value to its parent, and its > parent would do the same, until the error has bubbled up to the root > component. > > > Option 2 is simple and robust, and can be used to pass messages of any type, > for any situation... but I'm wondering if I'm missing an obvious 3rd solution? > -- > 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.
