Hello World: Welcome to Elder.js!

This hook receives the hookInterface.ts file which defines all hook interactions. You can customize all 'props' and 'mutable' of all hooks by using this hook. This is a power user hook and unless you know Elder.js internals don't mess with it.

• Often used to populate the empty query object with a database or API connection as query is passed to the all() function which is used to generate request objects.
• Internally used to automatically populate the helpers object with the helpers found in './src/helpers/index.js'.
• Can be used to set information on the data object that is needed throughout the entire lifecycle. (sitewide settings)

The main use here is to allow users to adjust the requests that Elder.js is aware of.

• This could be used for incremental builds. By filtering and overwriting the allRequests array building just a single route or even a single request is doable.
• This hook is used by elderjs-plugin-random to register temporary requests that it later intercepts to redirect to a random page of a route.
• This hook is used by elderjs-plugin-markdown to register processed markdown files and their slugs Elder.js

NOTE: If you are modifying 'allRequests' you must set 'request.route' key for each request.

If you're looking to use Elder.js with express/polka to build a server rendered website, then you'll be interested in this hook as it includes the familiar 'req' and 'next' objects as often used in Express middleware.

• Under the hood Elder.js uses this hook to power the server implementation.
• If you want to change the route of a request, you can do so by modifying the 'request.route' to the name of the new request, and it will be picked up by the default Elder.js server.
• If you're looking to set user or session information stored on the 'req' prop we recommend using a hook to modify the 'request' object or 'data' objects. Change to the request object will be passed down.
• If you're looking to pass in details about the query string deeper into your application, you could use this hook to do so.
• Anything you'd use an Express 'req' or 'next' for you can do and customize other parts of the Elder.js on this hook.

This hook gives access to the entire state of a request lifecycle before it starts.

• Primarily used to set 'request' specific data that is required by all routes so doesn't make sense to share across multiple 'data' functions.
• If you have helper functions that need a closure isolated to a specific page generation lifecycle here is where you should attach them.
• If you need to programmatically change the route, you can do so here. This is how the elderjs-plugin-random works.
• This hook is commonly uses by plugins that need to add route level data that is dependent on the request to populate.

This hook is mainly used by plugins/hooks to offer functionality at the route level that is dependent on the route's "data" function has returning but isn't suitable to live in multiple data function across many routes due to code duplication.

Examples of things we (ElderGuide.com) have done or have seen users do:

• LD+JSON: Plugins/hooks that add LD+JSON may need the a route's "data" function to be executed before they have the data needed to run.
• Breadcrumbs: Plugins/hooks that add breadcrumbs may be dependent on the "data" function of a route.
• Table Of Contents: Plugins/hooks that automatically generate a table of contents will be dependent on data from a route's data function.
• Reference Plugins: Plugins/hooks that collect references from content and add them to the footer of the page content.
• Last Updated Data: Determining the last updated date for a page is often better to do in a central place instead of in many "data" functions.

Stacks are made available here so that strings can be added to the head or footer of the page easily.

Elder.js uses this hook to process shortcodes. The vast majority of users won't need to use this hook, but if you were so inclined you could write your own shortcode parser or if you'd like to disable shortcodes completely, you can add 'elderProcessShortcodes' to hooks.disable in your elder.config.js file.

NOTE: Don't use this hook for anything besides shortcodes.

Elder.js uses 'stacks' to manage it's string concatenation. If you are unfamiliar, stacks are basically an array of strings, with a priority, and some meta data. This hook let's you manipulate or view the stacks before they are written to the page and is designed for use by plugins.

This hook will mainly be used when you need to add arbitrary strings to the footer. In most cases, users should be using <svelte:head></svelte:head> to add content to the head.

• headStack: Internally all content used in are added to the head stack. If you were looking to add ld+json to the page, you could do it here. If you're looking to write <title> tags, we recommend doing it within Svelte templates unless you are writing a plugin in which case you may want to also look at the 'head' hook.
• cssStack: The 'cssStack' represents all of the css strings added by hooks and plugins. Plugins can add css here (our in the head stack if you need to add CSS before the Elder.js CSS file), but we recommend users add them directly in Svelte files. Note: Do not wrap strings added to the stack in <style></style>.
• beforeHydrateStack: Polyfills for hydration could be added here. This stack is not run unless there are Svelte components to be hydrated.
• hydrateStack: the hydrateStack contains strings which represent all of the root svelte components which will be hydrated.
• customJsStack: Used to add custom JS to the site. This is done after the Svelte components are written to the page.
• footerStack: the footerStack which is an array of html or html friendly strings that will be written to the footer. This is generally the ideal place for plugins to add Analytics scripts as it fires after all other JS.

This hook's headSting represents everything that will be written to <head> tag.

There are many possible SEO uses to this hook, especially for plugins. That said, we recommend users who want to set common SEO elements such as tags <title> and meta descriptions programmatically to do it from within Svelte templates using the <svelte:head></svelte:head> tag. Chances are you won't need this field unless you're a power user and need access to the raw head.

This hook should only be used when you need to have full control over the <html> document. Make sure if you use this to add 'elderCompileHtml' to the 'hooks.disable' array in your elder.config.js or your template will be overwritten.

This hook receives the full html of the document. With great power comes great responsibility.

• Can be used to compress the html/css/js.
• Could be used to programmatically extract h2/h3 tags and build/inject a table of contents with something like Cheeriojs.
• If you need to modify the final html output, here is where you can do it.

This hook is triggered on an individual 'request object' completing whether Elder.js is being used in the "build" or a "server" mode.

• Internally, Elder.js uses this hook to write html to the "public folder".
• Useful for uploading static html to s3 or another source.
• Could also be used to write the output of a route's "data" function file to help with client site routing if you were so inclined.
• This hook may also be used by plugins to clean up any request specific 'state' they have stored.
• By default Elder.js adds a hook here to all server requests that outputs how long the request took to generate. If you want to see detailed output from this hook set debug.speed = true in your config file.

As the script encounters errors, they are collected and presented on this hook at the end of a request and the end of an entire build.

Contains whether the build was successful. If not it contains errors for the entire build. Also includes average performance details, and a granular performance object. Could be used to fire off additional scripts such as generating a sitemap or copying asset files to the public folder.

Plugins: Because builds are split across processes, a plugin doesn't not have a shared memory space across all processes.