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

Reply via email to