I've came up with solution very similar to Oliver's :) Top `Page`(or `Screen`) update functions are getting the `Store` which is a top level app model. Alternative way is to have `mapToContext` function that receives some `Props` and `Store` and maps those to some useful context(it might be useful for both view and update functions, btw).
Each top-level `Page` update fn also returns an instance of `Action` that helps modifying the store. On Monday, March 20, 2017 at 1:58:38 PM UTC+2, 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.
