[{"name":"DataSource","comment":" StaticHttp requests are an alternative to doing Elm HTTP requests the traditional way using the `elm/http` package.\n\nThe key differences are:\n\n - `StaticHttp.Request`s are performed once at build time (`Http.Request`s are performed at runtime, at whenever point you perform them)\n - `StaticHttp.Request`s strip out unused JSON data from the data your decoder doesn't touch to minimize the JSON payload\n - `StaticHttp.Request`s can use [`Pages.Secrets`](Pages.Secrets) to securely use credentials from your environment variables which are completely masked in the production assets.\n - `StaticHttp.Request`s have a built-in `StaticHttp.andThen` that allows you to perform follow-up requests without using tasks\n\n\n## Scenarios where StaticHttp is a good fit\n\nIf you need data that is refreshed often you may want to do a traditional HTTP request with the `elm/http` package.\nThe kinds of situations that are served well by static HTTP are with data that updates moderately frequently or infrequently (or never).\nA common pattern is to trigger a new build when data changes. Many JAMstack services\nallow you to send a WebHook to your host (for example, Netlify is a good static file host that supports triggering builds with webhooks). So\nyou may want to have your site rebuild everytime your calendar feed has an event added, or whenever a page or article is added\nor updated on a CMS service like Contentful.\n\nIn scenarios like this, you can serve data that is just as up-to-date as it would be using `elm/http`, but you get the performance\ngains of using `StaticHttp.Request`s as well as the simplicity and robustness that comes with it. Read more about these benefits\nin [this article introducing StaticHttp requests and some concepts around it](https://elm-pages.com/blog/static-http).\n\n\n## Scenarios where StaticHttp is not a good fit\n\n - Data that is specific to the logged-in user\n - Data that needs to be the very latest and changes often (for example, sports scores)\n\n@docs DataSource\n\n@docs map, succeed, fail\n\n@docs fromResult\n\n\n## Building a StaticHttp Request Body\n\nThe way you build a body is analogous to the `elm/http` package. Currently, only `emptyBody` and\n`stringBody` are supported. If you have a use case that calls for a different body type, please open a Github issue\nand describe your use case!\n\n@docs Body, emptyBody, stringBody, jsonBody\n\n\n## Chaining Requests\n\n@docs andThen, resolve, combine\n\n@docs map2, map3, map4, map5, map6, map7, map8, map9\n\n","unions":[],"aliases":[{"name":"Body","comment":" A body for a StaticHttp request.\n","args":[],"type":"Pages.Internal.StaticHttpBody.Body"},{"name":"DataSource","comment":" A DataSource represents data that will be gathered at build time. Multiple `DataSource`s can be combined together using the `mapN` functions,\nvery similar to how you can manipulate values with Json Decoders in Elm.\n","args":["value"],"type":"Pages.StaticHttpRequest.RawRequest value"}],"values":[{"name":"andThen","comment":" Build off of the response from a previous `StaticHttp` request to build a follow-up request. You can use the data\nfrom the previous response to build up the URL, headers, etc. that you send to the subsequent request.\n\n import DataSource\n import Json.Decode as Decode exposing (Decoder)\n\n licenseData : StaticHttp.Request String\n licenseData =\n StaticHttp.get\n (Secrets.succeed \"https://api.github.com/repos/dillonkearns/elm-pages\")\n (Decode.at [ \"license\", \"url\" ] Decode.string)\n |> StaticHttp.andThen\n (\\licenseUrl ->\n StaticHttp.get (Secrets.succeed licenseUrl) (Decode.field \"description\" Decode.string)\n )\n\n","type":"(a -> DataSource.DataSource b) -> DataSource.DataSource a -> DataSource.DataSource b"},{"name":"combine","comment":"Turnalistof`StaticHttp.Request`sintoasingleone.\n\nimportDataSource\nimportJson.DecodeasDecodeexposing(Decoder)\n\ntypealiasPokemon=
