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.
