Our application essentially replaces `Cmd Msg` in `update : Msg -> Model -> ( Model, Cmd Msg )` with the notion of an "out message" in the form `update : Msg -> Model -> ( Model, List OutMsg )`. Like a command, an out message is a request for action beyond the scope of the model being updated. Commands are just a specialization of this notion that flows out the top of the program (and over to the effects managers). In fact, one standard entry in the out message union types is `Command (Cmd Msg)`. The update pattern for submodels consists in running their update functions, storing the update submodel into the containing model, and then processing the out messages to perform further updates at the level of the containing model or to produce out messages that will pass further up the tree. An example of such an out message is `DidLogin AuthToken` which allows the sign in logic to report up to the rest of the app that we've successfully signed in and obtained an auth token. Fancy usage actually allows for running up the hierarchy to obtain some non-local piece of information before continuing an update but I'm not sure I'm really fond of that approach as an alternative to just passing and translating more out messages.
Mark On Mon, Mar 20, 2017 at 1:51 PM, Martin Norbäck Olivers <norb...@gmail.com> wrote: > And it helps to not think about the functions "interacting" with each > other. They don't. A function can call another function. Nothing is > stopping you from calling the content update function or the user update > function from another update function, but I find it helps to just factor > out the common functionality into separate functions that can be called > from multiple places. > > And if you have an update function that needs to update several > "sub-models", just pass all the sub-models and get the updated sub-models > back. Or pass the main model and let it update the parts it needs to update. > > >> 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? >>> >> >> I find it helps to think not about sending messages to somebody but >> returning a command. If the session updater needs to load a user profile, >> it returns a command do to that and you map that onto the user message >> type. If the user profile needs data from the session model, you pass that >> data to the view function. >> >> It only gets hard when you try to think of them as separate components. >> They're not, they are just a collection of functions. >> > -- > 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. > -- 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.
