I understand, and appreciate the suggestion. But I'm looking for a more generic solution here. I can't work around cookie restraints in all of my use cases, unfortunately (maybe using an auth token as an example was bad idea).
Think about that problem of handling http errors at the root level (letting them "bubble up"). It's essentially the same sort of problem. I need to learn more about how commands actually work. Are command return values all fed back through a single message dispatcher (considering the manner in which the messages flow back down our UI hierarchy)? Although I think it's current hard to get a clean abstraction, it's hard to think of a good solution to fix it... RootLevel _ PageLevel \ | \_> ServiceLevel The PageLevel is calling the service level for a command. We want intermediate effects, before the final command. But we don't want to just issue intermediate commands either, because the state that is reacting to the final command (the only one we have currently) could also be affected by the intermediate command. Also, it doesn't help us refactor out the (common) inputs into the service layer, such as a header value we need to write out. It seems like there's a missing abstraction from the Elm architecture. But this is tricky. Effectively, I'm wishing that a service module could maintain some state of it's own that doesn't need to be threaded through the entire UI hierarchy. Or perhaps the state could still be maintained at the root, but the service modules would have a way of fetching state and communicating state change messages to the root, without passing through the UI hierarchy. I recognize that this puts me in dangerous territory though, because that is also the essence of much talk about inter-component communication, which I think usually heads down the wrong path (for understandable reasons, but wrong all the same). On Thursday, October 13, 2016 at 1:08:22 AM UTC+9, Rupert Smith wrote: > On Wednesday, October 12, 2016 at 2:13:16 PM UTC+1, Fa Qing wrote: >> >> Let's say that every response includes a dynamic "token" header value, >> and every request needs to return that token in the headers. >> > > Don't forget that you can use a cookie or secure cookie for this purpose. > Its hard to see that using a bearer token in an Authorization header is > better than a secure cookie, because - the browser enforces some extra > constraints around secure cookie to make them more secure and the cookies > are shared accross a domain meaning if the user pops up a second tap by > ctrl-clicking a link in your application, authentication can flow accross. > However, it seems not to be the done thing for REST APIs. > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
