view is able to set head tags which can be used for site metadata and SEO data.
manifest lets you configure the manifest.json for your PWA (Progressive Web App).
canonicalSiteUrl is the default domain for your <head> tags for SEO purposes (you can override it with canonicalUrlOverride,
see <Head.Seo>. Learn more about canonical URLs and why they are important in this article.
internals is an opaque data type with some internal boilerplate from your elm-pages content. You should pass it internals = Pages.internals.
Otherwise, you have a standard Elm app which
elm-pages Lifecycle
It's helpful to understand the elm-pages lifecycle and how it compares to a vanilla elm app (i.e. a Browser.application).
Generate Step (elm-pages build)
Whereas a vanilla Elm app simply compiles your Elm code at build time, elm-pages performs some lifecycle events at this stage.
Performs all StaticHttp.Requests (see <Pages.StaticHttp>) for every static page in your app. The StaticHttp Responses are stored in JSON
files called content.json (one JSON file for each static page in your site).
Pre-renders HTML pages, including the <head> tags for the page from your view's head.
Optimizes image assets and copies over files from static folder to the dist folder.
Initial Load (from user's browser)
The user will see the pre-rendered HTML when they initially load a page on your elm-pages site (unless you are in dev mode, i.e. elm-pages develop, in
which case there is no pre-rendering).
Hydration
Fetch all the StaticHttp responses and page data (the content.json file for the current page).
The Elm app hydrates and starts executing and running your Elm app's init function and update loop (not just the pre-rendered HTML content).
At this point, all of your subscriptions, etc. will behave as they would in a regular Elm application.
The app will now run as a single-page app. When you hover over a link to another static page on your current site,
it will pre-fetch the page data (content.json file), so that the page load is instant.
This is the entry point for your
elm-pagesapplication.This is similar to how you set up a regular Elm application using
Browser.application, but with a few differences.viewhas access toStaticHttpdata (see Pages.StaticHttp).viewis able to setheadtags which can be used for site metadata and SEO data.manifestlets you configure the manifest.json for your PWA (Progressive Web App).canonicalSiteUrlis the default domain for your<head>tags for SEO purposes (you can override it withcanonicalUrlOverride, see <Head.Seo>. Learn more about canonical URLs and why they are important in this article.internalsis an opaque data type with some internal boilerplate from yourelm-pagescontent. You should pass itinternals = Pages.internals.Otherwise, you have a standard Elm app which
elm-pagesLifecycleIt's helpful to understand the
elm-pageslifecycle and how it compares to a vanilla elm app (i.e. aBrowser.application).Generate Step (
elm-pages build)Whereas a vanilla Elm app simply compiles your Elm code at build time,
elm-pagesperforms some lifecycle events at this stage.StaticHttp.Requests (see <Pages.StaticHttp>) for every static page in your app. The StaticHttp Responses are stored in JSON files calledcontent.json(one JSON file for each static page in your site).<head>tags for the page from yourview'shead.staticfolder to thedistfolder.Initial Load (from user's browser)
The user will see the pre-rendered HTML when they initially load a page on your
elm-pagessite (unless you are in dev mode, i.e.elm-pages develop, in which case there is no pre-rendering).Hydration
StaticHttpresponses and page data (thecontent.jsonfile for the current page).initfunction andupdateloop (not just the pre-rendered HTML content). At this point, all of yoursubscriptions, etc. will behave as they would in a regular Elm application.content.jsonfile), so that the page load is instant.