Erik, if you look at an updated version of the gist you posted earlier, I think that UpdateCache could readily be replace with LogoutUser (or HandleResponseError)
https://gist.github.com/pdamoc/d492ab58023926cd4d4950f12e5e170d On Wednesday, July 6, 2016 at 10:25:05 AM UTC-10, Erik Lott wrote: > > Yeah, the cookie is acting like a global var, which makes me cringe as > much as you... > > > On Wednesday, July 6, 2016 at 2:50:40 PM UTC-4, Josh Adams wrote: >> >> 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 think this is a good indication of my handwavy concern. I don't think >> this is an event as much as it is data - "I'm logged in as this user". And >> passing data inside your elm application by way of cookies is horribly >> reminiscent of using the dom as a database - i.e. that's not what it's for, >> if you're using it that way then it indicates a design problem. The >> DOM-as-a-database problem haunted us for 15+ years, and still does for the >> unenlightened. >> >> Why is it that you need to reach for cookies here? Cookies are for >> remote state. This is local state. >> > -- 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.
