[{"name":"ApiRoute","comment":"\n\n@docs Done, Handler, Response, buildTimeRoutes, capture, int, literal, single, slash, succeed, getBuildTimeRoutes\n\n","unions":[],"aliases":[{"name":"Done","comment":" ","args":["response"],"type":"Internal.ApiRoute.Done response"},{"name":"Handler","comment":" ","args":["a","constructor"],"type":"Internal.ApiRoute.Handler a constructor"},{"name":"Response","comment":" ","args":[],"type":"{ body : String.String }"}],"values":[{"name":"buildTimeRoutes","comment":" ","type":"(constructor -> DataSource.DataSource (List.List (List.List String.String))) -> ApiRoute.Handler (DataSource.DataSource ApiRoute.Response) constructor -> ApiRoute.Done ApiRoute.Response"},{"name":"capture","comment":" ","type":"ApiRoute.Handler (String.String -> a) constructor -> ApiRoute.Handler a (String.String -> constructor)"},{"name":"getBuildTimeRoutes","comment":" ","type":"ApiRoute.Done response -> DataSource.DataSource (List.List String.String)"},{"name":"int","comment":" ","type":"ApiRoute.Handler (Basics.Int -> a) constructor -> ApiRoute.Handler a (Basics.Int -> constructor)"},{"name":"literal","comment":" ","type":"String.String -> ApiRoute.Handler a constructor -> ApiRoute.Handler a constructor"},{"name":"single","comment":" ","type":"ApiRoute.Handler (DataSource.DataSource ApiRoute.Response) (List.List String.String) -> ApiRoute.Done ApiRoute.Response"},{"name":"slash","comment":" ","type":"ApiRoute.Handler a constructor -> ApiRoute.Handler a constructor"},{"name":"succeed","comment":" ","type":"a -> ApiRoute.Handler a (List.List String.String)"}],"binops":[]},{"name":"DataSource","comment":" In an `elm-pages` app, each page can define a value `data` which is a `DataSource` that will be resolved **before** `init` is called. That means it is also available\nwhen the page's HTML is pre-rendered during the build step. You can also access the resolved data in `head` to use it for the page's SEO meta tags.\n\nA `DataSource` lets you pull in data from:\n\n - Local files ([`DataSource.File`](DataSource-File))\n - HTTP requests ([`DataSource.Http`](DataSource-Http))\n - Globs, i.e. listing out local files based on a pattern like `content/*.txt` ([`DataSource.Glob`](DataSource-Glob))\n - Ports, i.e. getting JSON data from running custom NodeJS, similar to a port in a vanilla Elm app except run at build-time in NodeJS, rather than at run-time in the browser ([`DataSource.Port`](DataSource-Port))\n - Hardcoded data (`DataSource.succeed \"Hello!\"`)\n - Or any combination of the above, using `DataSource.map2`, `DataSource.andThen`, or other combining/continuing helpers from this module\n\n\n## Where Does DataSource Data Come From?\n\nData from a `DataSource` is resolved when you load a page in the `elm-pages` dev server, or when you run `elm-pages build`.\n\nBecause `elm-pages` hydrates into a full Elm single-page app, it does need the data in order to initialize the Elm app.\nSo why not just get the data the old-fashioned way, with `elm/http`, for example?\n\nA few reasons:\n\n1. DataSource's allow you to pull in data that you wouldn't normally be able to access from an Elm app, like local files, or listings of files in a folder. Not only that, but the dev server knows to automatically hot reload the data when the files it depends on change, so you can edit the files you used in your DataSource and see the page hot reload as you save!\n2. Because `elm-pages` has a build step, you know that your `DataSource.Http` requests succeeded, your decoders succeeded, your custom DataSource validations succeeded, and everything went smoothly. If something went wrong, you get a build failure and can deal with the issues before the site goes live. That means your users won't see those errors, and as a developer you don't need to handle those error cases in your code! Think of it as \"parse, don't validate\",butforyourentirebuild.\n3.Youdon'thavetoworryaboutanAPIbeingdown,orhittingitrepeatedly.YoucanbuildindataanditwillendupasJSONfilesservedupwithalltheotherassetsofyoursite.If
