Skip to content

Configuration (v7)

Alex edited this page Jul 19, 2022 · 1 revision

Configuration

Configuration Strategies

To configure your runtime options, for anything from loaders to template variables, you have a few options. For SSR, the first option is to inline every configuration into the factory function to create the given loader. You could load all your template variables right there at the start, which could be useful in a situation where you're creating loaders dynamically at runtime for a given session state. Another option is to initialize your loaders with fallback data, and then inline the overriding data to the Loader.template() function as the second argument. With SSG, you only have the option to set up fallback data, and now we will go over the ways that you can set that.

hcl-config.js

module.exports = {
    ssr_config: {
        pathRoot: 'views',
        partials: 'partials',
        templates: 'pages',
        partialInput: {},
        templateInput: {},
        watch: false,
        discoverPaths: false,
        intlCode: 'en',
        debug: {
            logMode: 'silent',
            logStrategy: 'none',
            logFile: null
        }
    }
    ssg_config: {
        pathRoot: 'views',
        partials: 'partials',
        templates: 'pages',
        partialInput: {},
        templateInput: {},
    },
    fallbacks: {}
}

It will effectively just compile all the default options possible in the library itself. The basic concepts to really focus on would be the following properties

pathRoot: 'views',
partials: 'partials',
templates: 'pages',
partialInput: {},
templateInput: {},

The pathRoot option specifies, relative to the process directory, where to look for partial / template directories. The partials and template option set the paths within the root for the partials/templates. The next options are the inputs for the corresponding chunk type. They are key value pairs that can be accessed from within the expressions available in your chunks.

Learn More

The fallbacks object allows you to specify any potential 'catch data' that can be used to attempt to suppress some sort of fatal error during runtime. An example may be a key / value of 'content': 'Page not Found'

hcl-config.json

hcl-config.js / hcl-config.json

You can create a file on the same level as package.json in your project with either of those names, and give it any of the following configuration options which will be a low priority fallback by the runtime itself.

package.json

If you set fallbacks in package.json, you would just take the same shape as above, but wrap it around hcl_config: {} in the package.json itself