Getting Started Introduction Installation UpgradingContent Types PathsStructure Layouts Media Themes StaticConfiguration Baseurl PaginationMagic Variables allContent allLayouts paramsCommands New Site New Type Build Serve EjectTheme Commands Theme Add Theme Enable Theme Disable Theme Update Theme RemoveDeployment GitHub Actions GitLab Pipelines Gitea ActionsCMS Setup New Content Content Components Discoverability Media Field Widgets

Layouts

Svelte

All the templating is done in a reactive UI component framework called Svelte. Svelte offers a simplified syntax and creates a welcoming developer experience for folks coming directly from an HTML/CSS background. It also offers some performance benefits over similar frameworks since it doesn't require a virtual DOM and its runtime is rather small.

layouts/global/html.svelte

The layouts/global/html.svelte file is important and changing its name will break your app. You could also potentially break your routing if you're not careful with <svelte:component this={layout} {...content.fields} {allContent} />. Once you're aware of those two things, this file shouldn't be too scary and is meant for you to customize.

It is common practice (but not required) to use a JS spread operator {...content.fields} inside a dynamic component <svelte:component this={layout}/> in your layouts/global/html.svelte file to make the keys you define in your content source easier to access. That resolves routes without requiring you to manually check them and load the corresponding layout and allows you to access keys defined in your content source directly at the top level of your layouts/content/YOUR_TYPE.svelte templates like:

<script>
  export let title;
</script>

<h1>{title}</h1>

layouts/content/

Files that live in this folder correspond directly to the types defined in your content source. For example if you have blog type (content/blog/post-whatever.json) you would create a corresponding template at layouts/content/blog.svelte. One template should be used per type and it will feed many content files to create individual nodes (endpoints).

The rest of the structure is really up to you. We try to create logical default folders, such as layouts/components/ for reusable widgets and layouts/scripts/ for helper functions, but feel free to completely change these and make the structure your own.