Somehow at that point it seems like we have effectively given up on a clean 
architecture though.

We extracted out our API layer (or at least our transport layer), yet we're 
still having to take both inputs and return values and pass them through 
(every) unrelated entity that calls the API layer. At which point I'm not 
sure I would even want to abstract out the API layer beyond creating a few 
common helper functions. I can shake the feeling that this is a messy 
architecture that doesn't lend itself a clean abstraction with regard to 
these sorts of service modules.

It's a trivial thing, I suppose, to drop down to JS and do this (or as 
Rupert mentioned, use cookies for use cases where cookie restrictions 
aren't too constraining), but I think it would be strongly preferable to 
have a generic  way of doing this directly in Elm.

On Thursday, October 13, 2016 at 1:07:44 AM UTC+9, Peter Damoc wrote:

> On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing < <javascript:>
> > wrote:
>> Goal
>> [AppRoot] -> [UsersPage] --> ask api for users, and upon success, 
>> 1. send the UsersFetchSuccess message (attaching the users); so far so 
>> good, but then also I need to...
>> 2. replace the token by sending the BumpToken message at the root level 
>> of the app.
> I would approach this by making UserFetchSuccess incorporate the token. 
> type Msg 
>     = UserFetchSuccess Token UserData
> and handle the bumping of the token afterwards by maybe extending the 
> update signature with a Maybe Token
> -- 
> There is NO FATE, we are the creators.
> blog:

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 
For more options, visit

Reply via email to