Re: [elm-discuss] http "middleware" options

2016-10-12 Thread Fa Qing
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

Re: [elm-discuss] http "middleware" options

2016-10-12 Thread Peter Damoc
On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing 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

Re: [elm-discuss] http "middleware" options

2016-10-12 Thread Wouter In t Velt
Personally, I like the setup for as it is used in the time tracker SPA example (here) . They have a separate file (Util.elm) with the following function: cmdForRoute : Model -> List (Cmd Msg) (This function is called inside

Re: [elm-discuss] http "middleware" options

2016-10-12 Thread Peter Damoc
On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing wrote: > I'm just curious how everybody approaches their API service layer in > complex applications. > > Right now, I have a shared API module that I call from various > elements/pages/components/children... in a pretty flat

[elm-discuss] http "middleware" options

2016-10-12 Thread Fa Qing
I'm just curious how everybody approaches their API service layer in complex applications. Right now, I have a shared API module that I call from various elements/pages/components/children... in a pretty flat architecture. That module abstracts out the common request composition, etc. What I