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