[{"name":"Update.Fetch","comment":" Some conveniences for implementing the `update` function with `fetch`.\n\nUsing the various functions in\n[ccapndave/elm-update-extra](http://package.elm-lang.org/packages/ccapndave/elm-update-extra/latest)\nis also highly recommended.\n\n@docs andThenFetch, sequenceExtra\n\n","unions":[],"aliases":[],"values":[{"name":"andThenFetch","comment":" The primary purpose of the `update` function is to take a `msg` and\nreturn an updated `model` (and possibly a `Cmd`). So, what one ordinarily does\nin an `update` function is run a `case` statement on the `msg`, doing whatever\nis appropriate for the provided `msg`.\n\nHowever, there are times when we want to take certain actions based not on the\n`msg` we just received, but instead on the state of our `model` generally ...\nparticularly the state of whatever is controlling our `view`. For instance, we\nmay need to load some data from the backend in order to support the current\nview. That will require a `Cmd`, but it is logically independent of the\ncurrent `msg`. Well, I suppose you could try to \"catch\" every message that\ncreates a requirement to fetch some data, but that is error prone -- it would\nbe nicer to just compute what messages are necessary, given the state of the\nmodel.\n\nSo, imagine that you have a function like this:\n\n    fetch : Model -> List Msg\n\nIts job is to look at the model and decide whether there are any messages that\nought to be processed (e.g. to fetch some needed data, but it isn't really\nlimited to that). It's convenient for this to be a separate function (that is,\nseparate from `update`), because it doesn't depend on the `msg` ... it will be\na function of something in the model which indicates what the `view` needs.\n\nHowever, we also need to apply this `fetch` function. That is where `andThenFetch`\ncomes in. You provide:\n\n  - your `fetch` function\n  - your `update` function\n\nWhat you get back is a function that has the same signature as your `update`\nfunction ... that is, it is also in the form `Msg -> Model -> (Model, Cmd\nMsg)`. However, after it calls your own `update` function, it calls your\n`fetch` function with the resulting `Model`, and then feeds those results back\ninto your `update` function. So, whatever messages your `fetch` function\nreturns will be processed.\n\nNote that this will run recursively ... that is, when your `fetch` function\nreturns some messages to process, it will be called again with the results of\nprocessing those messages. So, you will need something in your model to\nkeep track of actions in progress (e.g. `RemoteData`) so that you don't\nrepeatedly kick off the same action in an infinite loop.\n\nTo use this function, you would normally just supply the first two parameters\n... that is, your `fetch` function and your normal `update` function. What you\nwill then get back is a function of the form `msg -> model -> ( model, Cmd msg)` ...\nthat is, an `update` function that you can then pass to `programWithFlags` (or\nuse in another way).\n\nYour `main` function would look something like:\n\n    main =\n        Browser.element\n            { init = App.Update.init\n\n            -- We wire `andThenFetch` here.\n            , update = Update.Fetch.andThenFetch App.Fetch.fetch App.Update.update\n            , view = App.View.view\n            , subscriptions = App.Update.subscriptions\n            }\n\n`App.Update.update` is your normal update function.\n`App.Fetch.fetch` will likely look something like this, assuming you have a Page called `Items`:\n\n    {-| Call the needed `fetch` function, based on the active page.\n    -}\n    fetch : App.Model.Model -> List App.Model.Msg\n    fetch model =\n        case model.activePage of\n            Items ->\n                Pages.Items.Fetch.fetch model.backend\n                    |> List.map (\\subMsg -> MsgBackend subMsg)\n\n","type":"(model -> List.List msg) -> (msg -> model -> ( model, Platform.Cmd.Cmd msg )) -> msg -> model -> ( model, Platform.Cmd.Cmd msg )"},{"name":"sequenceExtra","comment":" Like `Update.Extra.sequence`, but for `update` signatures that also\nreturn a list of extra messages for the caller to handle.\n\nEssentially, this allows you to recursively apply a whole sequence of messages,\ncollecting their results. So, with `Update.Extra.sequence` you can do something\nlike this:\n\n    update : Msg -> Model -> ( Model, Cmd Msg )\n    update msg model =\n        case msg of\n            SomeMsg ->\n                sequence update\n                    [ AnotherMsg, YetAnotherMsg, AThirdMsg ]\n                    ( model, Cmd.none )\n\nIsn't that nice? Essentially, you get a really expressive way of constructing\na \"composite\" message. Plus, you can do something first ... that is, you could\nmodify the model, and have your own `Cmd`, and then feed that into the `sequence`\nfor further processing.\n\nSo, what is `sequenceExtra`? It deals with an alternative `update` signature,\nin which we're returning a third element to our tuple, with extra messages that\nthe caller is expected to handle. So, you can follow the same idiom as shown above.\n\n    update : Msg -> Model -> ( Model, Cmd Msg, List extraMsg )\n    update msg model =\n        case msg of\n            SomeMsg ->\n                sequenceExtra update\n                    [ AnotherMsg, YetAnotherMsg, AThirdMsg ]\n                    ( model, Cmd.none, [] )\n\n","type":"(msg -> model -> ( model, Platform.Cmd.Cmd msg, List.List extraMsg )) -> List.List msg -> ( model, Platform.Cmd.Cmd msg, List.List extraMsg ) -> ( model, Platform.Cmd.Cmd msg, List.List extraMsg )"}],"binops":[]}]