In this example (RandomGifPair), how is the update corresponding to NewGif actually wired to execute after the parent component fires
RandomGif.update act model.left
RandomGif.update NewGif maybeUrl
Effects.map Left fx
getRandomGif : String -> Effects Action
getRandomGif topic =
Http.get decodeUrl (randomUrl topic)
|> Task.map NewGif
update : Action -> Model -> (Model, Effects Action)
update action model =
case action of
(model, getRandomGif model.topic)
NewGif maybeUrl ->
( Model model.topic (Maybe.withDefault model.gifUrl maybeUrl)
All actions come in to your top-level update function. There's no way to scope actions to a sub-update function - they always come in at the top. So, most programs will manually route actions down to the lower update functions. That's what's happening here. All of the actions must go into
RandomGifPair.update, and it's up to that function to a) call sub functions and b) store the results in the right spot in the state. It can be surprisingly cumbersome.
Line 42 says "oh this is a
Left action? Give me the
act that's inside of there. NOW you have your desired
RequestMore stored in
act, and you know that it was bound for the left one. Line 44 calls the lower update function, which knows how to handle that. Line 46 stores the result of the lower update function in the model (by recreating the whole model with the new left and re-using the old right).
This is all obscured by the boilerplate around Effects. If you can understand how the actions flow first, then go back and apply the same logic to the Effects, I think that'll become clearer.