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
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
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
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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.