> > 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.
