[
    {
        "name": "RemoteData.Infix",
        "comment": " Convenience infix operators, for those that like them.\n\nAllows you do define a \"merge three values into a tuple\" function as:\n\n``` elm\nmerge3 a b c =\n    (,,) <$> a <*> b <*> c\n```\n\n@docs (<$>)\n@docs (<*>)\n",
        "unions": [],
        "aliases": [],
        "values": [],
        "binops": [
            {
                "name": "<$>",
                "comment": " Infix form of `map`. For those who like their applicative functors Haskell-style.\n",
                "type": "(a -> b) -> RemoteData e a -> RemoteData e b",
                "associativity": "left",
                "precedence": 9
            },
            {
                "name": "<*>",
                "comment": " Infix form of `(flip andMap)`. For those who like their applicative functors Haskell-style.\n\n\n",
                "type": "RemoteData e (a -> b) -> RemoteData e a -> RemoteData e b",
                "associativity": "left",
                "precedence": 9
            }
        ]
    },
    {
        "name": "RemoteData",
        "comment": " A datatype representing fetched data.\n\nIf you find yourself continually using `Maybe (Result Error a)` to\nrepresent loaded data, or you have a habit of shuffling errors away to\nwhere they can be quietly ignored, consider using this. It makes it\neasier to represent the real state of a remote data fetch and handle\nit properly.\n\n\nFor more on the motivation, take a look at the blog post [How Elm Slays A UI Antipattern](http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html).\n\n\nTo use the datatype, let's look at an example that loads `News` from a feed.\n\nFirst you add to your model, wrapping the data you want in `WebData`:\n\n\n``` elm\ntype alias Model =\n    { news : WebData News }\n```\n\nThen add in a message that will deliver the response:\n\n``` elm\ntype Msg\n    = NewsResponse (WebData News)\n```\n\nNow we can create an HTTP get:\n\n``` elm\ngetNews : Cmd Msg\ngetNews =\n    Http.get \"/news\" decodeNews\n        |> RemoteData.sendRequest\n        |> Cmd.map NewsResponse\n```\n\nWe trigger it in our `init` function:\n\n``` elm\ninit : ( Model, Cmd Msg )\ninit =\n    ( { news = Loading }\n    , getNews\n    )\n```\n\nWe handle it in our `update` function:\n\n``` elm\nupdate msg model =\n    case msg of\n        NewsResponse response ->\n            ( { model | news = response }\n            , Cmd.none\n            )\n```\n\n\nMost of this you'd already have in your app, and the changes are just\nwrapping the datatype in `Webdata`, and replacing the `Http.send` call\nwith `RemoteData.sendRequest`.\n\nNow we get to where we really want to be, rendering the data and\nhandling the different states in the UI gracefully:\n\n\n``` elm\nview : Model -> Html msg\nview model =\n  case model.news of\n    NotAsked -> text \"Initialising.\"\n\n    Loading -> text \"Loading.\"\n\n    Failure err -> text (\"Error: \" ++ toString err)\n\n    Success news -> viewNews news\n\n\nviewNews : News -> Html msg\nviewNews news =\n    div []\n        [h1 [] [text \"Here is the news.\"]\n        , ...]\n```\n\nAnd that's it. A more accurate model of what's happening leads to a better UI.\n\n@docs RemoteData\n@docs WebData\n@docs map\n@docs map2\n@docs map3\n@docs andMap\n@docs succeed\n@docs mapError\n@docs mapBoth\n@docs fromTask\n@docs andThen\n@docs withDefault\n@docs sendRequest\n@docs fromResult\n@docs toMaybe\n@docs asCmd\n@docs append\n@docs isSuccess\n@docs isFailure\n@docs isLoading\n@docs isNotAsked\n@docs update\n@docs prism\n\n",
        "unions": [
            {
                "name": "RemoteData",
                "comment": " Frequently when you're fetching data from an API, you want to represent four different states:\n  * `NotAsked` - We haven't asked for the data yet.\n  * `Loading` - We've asked, but haven't got an answer yet.\n  * `Failure` - We asked, but something went wrong. Here's the error.\n  * `Success` - Everything worked, and here's the data.\n",
                "args": [
                    "e",
                    "a"
                ],
                "cases": [
                    [
                        "NotAsked",
                        []
                    ],
                    [
                        "Loading",
                        []
                    ],
                    [
                        "Failure",
                        [
                            "e"
                        ]
                    ],
                    [
                        "Success",
                        [
                            "a"
                        ]
                    ]
                ]
            }
        ],
        "aliases": [
            {
                "name": "WebData",
                "comment": " While `RemoteData` can model any type of error, the most common\none you'll actually encounter is when you fetch data from a REST\ninterface, and get back `RemoteData Http.Error a`. Because that case\nis so common, `WebData` is provided as a useful alias.\n",
                "args": [
                    "a"
                ],
                "type": "RemoteData Error a"
            }
        ],
        "values": [
            {
                "name": "andMap",
                "comment": " Put the results of two RemoteData calls together.\n\nFor example, if you were fetching three datasets, `a`, `b` and `c`,\nand wanted to end up with a tuple of all three, you could say:\n\n``` elm\nmerge3 :\n    RemoteData e a\n    -> RemoteData e b\n    -> RemoteData e c\n    -> RemoteData e ( a, b, c )\nmerge3 a b c =\n    map (,,) a\n        |> andMap b\n        |> andMap c\n```\n\nThe final tuple succeeds only if all its children succeeded.  It is\nstill `Loading` if _any_ of its children are still `Loading`. And if\nany child fails, the error is the leftmost `Failure` value.\n\nNote that this provides a general pattern for `map2`, `map3`, ..,\n`mapN`. If you find yourself wanting `map4` or `map5`, just use:\n\n``` elm\nfoo f a b c d e =\n    map f a\n        |> andMap b\n        |> andMap c\n        |> andMap d\n        |> andMap e\n```\n\nIt's a general recipe that doesn't require us to ever have the\ndiscussion, \"Could you just add `map7`? Could you just add `map8`?\nCould you just...\".\n\nCategory theory points: This is `apply` with the arguments flipped.\n",
                "type": "RemoteData e a -> RemoteData e (a -> b) -> RemoteData e b"
            },
            {
                "name": "andThen",
                "comment": " Chain together RemoteData function calls.\n",
                "type": "(a -> RemoteData e b) -> RemoteData e a -> RemoteData e b"
            },
            {
                "name": "append",
                "comment": " Append - join two `RemoteData` values together as though\nthey were one.\n\nIf either value is `NotAsked`, the result is `NotAsked`.\nIf either value is `Loading`, the result is `Loading`.\nIf both values are `Failure`, the left one wins.\n",
                "type": "RemoteData e a -> RemoteData e b -> RemoteData e ( a, b )"
            },
            {
                "name": "asCmd",
                "comment": " Convert a web `Task`, probably produced from elm-http, to a `Cmd (RemoteData e a)`.\n",
                "type": "Task e a -> Cmd (RemoteData e a)"
            },
            {
                "name": "fromResult",
                "comment": " Convert a `Result Error`, probably produced from elm-http, to a RemoteData value.\n",
                "type": "Result e a -> RemoteData e a"
            },
            {
                "name": "fromTask",
                "comment": " Convert a task to RemoteData.\n\nThis is fairly low-level. Most people will use `sendRequest` instead\nand stay above `Task`s entirely.\n",
                "type": "Task e a -> Task x (RemoteData e a)"
            },
            {
                "name": "isFailure",
                "comment": " State-checking predicate. Returns true if we've failed to load some data.\n",
                "type": "RemoteData e a -> Bool"
            },
            {
                "name": "isLoading",
                "comment": " State-checking predicate. Returns true if we're loading.\n",
                "type": "RemoteData e a -> Bool"
            },
            {
                "name": "isNotAsked",
                "comment": " State-checking predicate. Returns true if we haven't asked for data yet.\n",
                "type": "RemoteData e a -> Bool"
            },
            {
                "name": "isSuccess",
                "comment": " State-checking predicate. Returns true if we've successfully loaded some data.\n",
                "type": "RemoteData e a -> Bool"
            },
            {
                "name": "map",
                "comment": " Map a function into the `Success` value.\n",
                "type": "(a -> b) -> RemoteData e a -> RemoteData e b"
            },
            {
                "name": "map2",
                "comment": " Combine two remote data sources with the given function. The\nresult will succeed when (and if) both sources succeed.\n",
                "type": "(a -> b -> c) -> RemoteData e a -> RemoteData e b -> RemoteData e c"
            },
            {
                "name": "map3",
                "comment": " Combine three remote data sources with the given function. The\nresult will succeed when (and if) all three sources succeed.\n\nIf you need `map4`, `map5`, etc, see the documentation for `andMap`.\n",
                "type": "(a -> b -> c -> d) -> RemoteData e a -> RemoteData e b -> RemoteData e c -> RemoteData e d"
            },
            {
                "name": "mapBoth",
                "comment": " Map function into both the `Success` and `Failure` value.\n",
                "type": "(a -> b) -> (e -> f) -> RemoteData e a -> RemoteData f b"
            },
            {
                "name": "mapError",
                "comment": " Map a function into the `Failure` value.\n",
                "type": "(e -> f) -> RemoteData e a -> RemoteData f a"
            },
            {
                "name": "prism",
                "comment": " A monocle-compatible Prism.\n\nIf you use Monocle, you'll want this, otherwise you can ignore it.\n\nThe type signature is actually:\n\n``` elm\nprism : Prism (RemoteData e a) a\n```\n\n...but we use the more verbose type here to avoid introducing a dependency on Monocle.\n",
                "type": "{ getOption : RemoteData e a -> Maybe a, reverseGet : a -> RemoteData e a }"
            },
            {
                "name": "sendRequest",
                "comment": " Convenience function for dispatching `Http.Request`s. It's like\n`Http.send`, but yields a `WebData` response.\n\n``` elm\ngetNews : Cmd Msg\ngetNews =\n    Http.get \"/news\" decodeNews\n        |> RemoteData.sendRequest\n```\n",
                "type": "Request a -> Cmd (WebData a)"
            },
            {
                "name": "succeed",
                "comment": " Lift an ordinary value into the realm of RemoteData.\n\nCategory theory points: This is `pure`.\n",
                "type": "a -> RemoteData e a"
            },
            {
                "name": "toMaybe",
                "comment": " Convert a `RemoteData e a` to a `Maybe a`\n",
                "type": "RemoteData e a -> Maybe a"
            },
            {
                "name": "update",
                "comment": " Apply an Elm update function - `Model -> (Model, Cmd Msg)` - to any `Successful`-ly loaded data.\n\nIt's quite common in Elm to want to run a model-update function, over\nsome remote data, but only once it's actually been loaded.\n\nFor example, we might want to handle UI messages changing the users\nsettings, but that only makes sense once those settings have been\nreturned from the server.\n\nThis function makes it more convenient to reach inside a\n`RemoteData.Success` value and apply an update. If the data is not\n`Success a`, it is returned unchanged with a `Cmd.none`.\n\n",
                "type": "(a -> ( b, Cmd c )) -> RemoteData e a -> ( RemoteData e b, Cmd c )"
            },
            {
                "name": "withDefault",
                "comment": " Return the `Success` value, or the default.\n",
                "type": "a -> RemoteData e a -> a"
            }
        ],
        "binops": []
    }
]