I had an idea during lunch that might work. To recap, our Json API works like this:
- POST /sessions - post a username/password. If the credentials are authentic, it returns 200 OK along with a secure http-only cookie. - GET /me - returns 200 OK with user record or 401 Unauthorized - .... lots of other secure endpoints that require authentication.... We also have an API module in elm that encapsulates all interaction with our server side api. This module can be imported into any nested component. There are 2 events that occur in this module that we wish we were notified about (globally). 1. 200 OK response from POST "/sessions". This means the server accepted our user/pass credentials and has set a cookie in the browser. We are now logged in. 2. A 401 Unauthorized response from any api endpoint - If we receive this response, the server says we are not logged in What we need is a simple way to communicate these events from the API module to the root of the application. What if we use an external resource like a cookie or local storage to communicate these events? For example, when the module detects a successful login, it could also set a cookie with value isLoggedIn = true. If the Api module detects a 401 response, the cookie is changed isLoggedIn = false Meanwhile, the application root also has access to this isLoggedIn cookie value, and it could precede every "update" with an authentication check - adding or removing any session data that is stored on the model. I'm going to see if this might work. On Wednesday, July 6, 2016 at 12:15:25 PM UTC-4, Maxwell Gurewitz wrote: > > Josh, I'm running into a similar problem. I want to trigger a global > error handler whenever any of my components error, (a 401 from session > expiration for example), but I want to be able to spread out my api > throughout my components. > > On Tuesday, July 5, 2016 at 7:53:29 AM UTC-7, Josh Adams wrote: >> >> I would handle this entirely differently, personally. I'm inclined to >> have an API TEA component as a child at the Root, and send up messages >> requesting API calls to it. I would never spread my API requests out >> through components. >> >> That's just me though - I know other people handle this way differently. >> Would love to hear any suggestions from more experienced folks re: this :) >> >> -Josh >> http://www.dailydrip.com/topics/elm >> >> On Tuesday, July 5, 2016 at 7:46:16 AM UTC-5, Erik Lott 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]. For more options, visit https://groups.google.com/d/optout.
