Somehow at that point it seems like we have effectively given up on a clean
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
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:
> > wrote:
>> [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: http://damoc.ro/
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.