Thanks everybody. It seems like we've converged on a similar approach. Do you guys keep your domain models all in repos at the root of your application?
Also, right now my api call ends with a (Cmd ModelUponSuccess), with that ModelUponSuccess belonging to the child page that uses the model returned (where it is also stored, for now, though I was thinking about refactoring them out into top level repos; hence the question above. But I need to also issue a (Cmd AndBumpThatAuthToken) upon a successful api call. Do I Cmd.map the ModelUponSuccess message from the caller to a message type in the api itself, so that it can issue a Cmd.batch list of commands that are all of the message type of the api module itself? 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. Getting a little late here, so hopefully that's still coherent. Thanks again everybody. I'm pretty new to the language and really appreciate the input. On Wednesday, October 12, 2016 at 10:48:18 PM UTC+9, Peter Damoc wrote: > On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing <[email protected] <javascript:> > > 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 architecture. That >> module abstracts out the common request composition, etc. >> > > This is also what I had in my app: an API module that exposes a Cmd > producing interface to the rest of the app. > > All API callers provide: > 1. `success` and `failure` message constructors > 2. the auth_token (if needed) > 3. the rest of the data required for the request > > The extraction from the header and injection in the header can be > abstracted in some custom `get` and `post` functions. > > > Right now I have an Api.sendJson call that returns a task > > > This sounds like a good approach (similar to the custom `post` that I > mentioned earlier) but I would not expose this to the rest of the app. > I would use something like this internally to do the job. > > In using my API module, I would always use only functions that produce Cmd > (I avoid using the tasks). > To give you an example. I had a User object that had a list of Companies. > The list is saved a set of IDs and to get the final Elm object I had to > first get the user data and then go through each of the IDs in the > Companies field and request the Company data for that company. > All these details are not the concern of the rest of the program. The rest > of the program just gets the final User with a list of Companies, nicely > wrapped in a message. > Internally to API, there are various functions that help with constructing > the final Task that first fetches the user and then fetches the rest of the > data but these tasks are not exposed outside the module. > > If the database storage changes or I decide on another strategy, the rest > of the app is isolated from these changes because it talks in the higher > language of the API not in the lower language of the Http that the API uses > to implement the functionality. > > > -- > 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.
