My current approach has two parts: 1) A Context record which is passed to all update functions 2) A pseudo Cmd called AppCmd which is returned from the updates as (model, cmd, appCmd)
The Context includes shared information like Session and Store (where I keep data records), any modifications that should be made to that shared information are requested as an AppCmd. e.g. AppCmd.storeMsg (Store.addUser user) At the top level those AppCmds are then dispatched appropriately to other updates. I haven't gone as far as returning information back to the original caller (i.e. the equivalent of Msg with Cmds) but so far I haven't found any need to. On Monday, 20 March 2017 12:58:38 UTC+1, Eirik Sletteberg wrote: > > In larger Elm apps, it makes sense to divide Updaters so you can > package-by-feature. > For example, a single page application could have updaters like this: > > - Configuration updater > - Session updater > - User Profile updater > - User Settings updater > - Content updater > - Some other business specific updater > > The challenge is when there are dependencies between Updaters, for example > the User Profile model might need data from the Session model, the Session > updater might need to send messages to the User updater (Load user profile > when session is updated), or the Content updater may need to check for the > Session updater (get session ID to send as parameter to the API when > fetching content), or some business-specific updater may need to interact > with both the Content updater, the User updater, and the Configuration > updater. > > In Redux, one would use combineReducers to mount each reducer under its > own path, and then one can trigger actions across reducers. How would you > solve this in Elm? > > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
