I suggested option 1 and use it all the time. In practise I enable commands in the root and first couple of children (basically components that equate to a table in my database), and then turn to pure update functions thereafter, and catch "Submit" events at the lowest parent that does command handling. It works for me, and then I use the update function to pass back returned data into my children's models. I've wondered about the triple return `update` function, but I think it would make refactoring quite a bit more painful.
Simon On Tuesday, 5 July 2016 19:30:51 UTC+2, Mark Hamburg wrote: > > 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] <javascript:>> > 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 > <https://groups.google.com/d/msg/elm-discuss/QPqrJd4C78Y/_TLLg81SAQAJ> > 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 > <http://stackoverflow.com/questions/37328203/elm-0-17-how-to-subscribe-to-sibling-nested-component-changes> > 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] <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.
