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 <[email protected] <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: http://damoc.ro/ > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
