Advanced Patterns

Learn advanced techniques for working with regions in complex applications.

TL;DR - What This Page Covers

This guide focuses on region inheritance using load functions (+layout.server.ts / +page.server.ts). You'll learn how to use await parent() to inherit, override, and extend regions across nested route hierarchies.

• Best for: Server-side data fetching with nested layouts
• Key technique: Spread parent regions, then add or override
• Alternative strategies: Component Wrapper and Snippet (see Strategy Comparison)

Prerequisites

This guide assumes you're comfortable with:

• SvelteKit load functions - How +layout.server.ts and +page.server.ts work (SvelteKit docs)
• Basic region usage - How to define and render regions (Quick Start guide)

SvelteKit Layout Hierarchy

Before diving into region inheritance, it's important to understand how SvelteKit's load function hierarchy works. Our regions system builds on top of these core SvelteKit concepts.

Load Functions: Layout vs Page

SvelteKit provides two types of server-side load functions that work together in a hierarchy:

+layout.server.ts

• Runs once per layout level and applies to all child routes
• Best for data that's common across multiple pages (navigation, auth, section-wide settings)
• Can access route params if the layout is nested (e.g., /products/[category]/+layout.server.ts)
• Returns data available to both the layout AND all descendant pages

+page.server.ts

• Runs only for this specific page
• Best for page-specific data fetching (product details, user profile, article content)
• Can call await parent() to access all parent layout data
• Can merge or override parent data before returning

Common Patterns

Scenario 1: Section-wide data in layout

typescript

Scenario 2: Page-specific data only

typescript

How This Connects to Regions

Our regions system automatically reads from the regions key in your load function return data. This works for BOTH +layout.server.ts and +page.server.ts files:

Both of these work automatically:

• Layout load functions: +layout.server.ts → defines regions for entire section
• Page load functions: +page.server.ts → defines regions for specific page
• No useLayoutRegions() call needed for load function data
• <LayoutRegion> automatically reads from page.data.regions

When to use useLayoutRegions()

The useLayoutRegions() function is for programmatic region definition in Svelte components—it's NOT needed when using load functions.

Load Function Strategy (this page): Define regions in +layout.server.ts or +page.server.ts. Data flows to page.data.regions automatically. No useLayoutRegions() call needed.
Component Wrapper / Snippet Strategies: Call useLayoutRegions() in your content component (e.g., GalleryHeader.svelte or +page.svelte) to provide region content. The +layout.svelte contains the region slot component (e.g., <LayoutRegion>) that renders it.

TL;DR: If you're defining regions in load functions, you never call useLayoutRegions(). For Component Wrapper/Snippet strategies, you call it in the component providing content, not in the layout.

Learn more about SvelteKit load functions →

Region Inheritance

Region inheritance allows child pages to inherit and extend regions defined in parent layouts. This is useful for nested layouts where you want to preserve parent regions while adding or overriding specific ones at deeper nesting levels.

Live Example

See region inheritance in action with visual indicators showing inherited, overridden, and added regions.

View Interactive Demo →

The Pattern

Use the parent() function in your load function to access parent data and merge regions:

typescript

Important: Spread .regions, Not All Parent Data

The parentData object contains all data returned by parent load functions—not just regions. This might include user, session, breadcrumbs, or any other data your parent layouts return.

Only spread parentData.regions, not the entire parentData object:

Correct:

regions: { ...(parentData.regions || {}), pageHeader: {...} }

Wrong:

regions: { ...parentData, pageHeader: {...} }

This would include user, session, etc. in your regions object!

Key Points:

• Spread first: ...(parentData.regions || {}) preserves parent regions
• Override after: Define regions with the same name to override parent's version
• Safety fallback: || {} handles undefined parent regions

Server vs Universal Load Inheritance

The parent() function behaves differently depending on your file type:

• In +page.server.ts or +layout.server.ts: Returns data only from parent +layout.server.ts files
• In +page.ts or +layout.ts: Returns data from parent +layout.ts files, OR from parent +layout.server.ts files if no +layout.ts shadows them

For this regions pattern, we recommend using .server.ts files consistently for simpler, more predictable inheritance.

How It Works

1. Inheritance: Child pages automatically receive all regions from parent layouts

2. Override: Child can redefine a region with the same name to replace parent's version

3. Addition: Child can add new regions alongside inherited ones

Example Scenario - Addition:

• Parent layout defines: { "breadcrumbs", "sidebar" }
• Child page defines: { "pageHeader", "footer" }
• Final merged regions: { "breadcrumbs", "sidebar", "pageHeader", "footer" }

Example Scenario - Override:

• Parent layout defines: { "breadcrumbs", "sidebar": { items: ["Home", "About"] } }
• Child page defines: { "breadcrumbs", "sidebar": { items: ["Products", "Categories"] }, "pageHeader" }
• Final merged regions: { "breadcrumbs" (child version), "sidebar" (child version), "pageHeader" (new) }

Complete Example

Here's a complete example showing region inheritance across multiple layout levels:

Root Layout

Defines global navigation available on all pages:

typescript

Section Layout

Inherits breadcrumbs, adds section-specific sidebar:

typescript

Page Level

Inherits breadcrumbs and sidebar, adds page-specific header:

typescript

Result at /products/123:

• breadcrumbs: Home → Products → Product Name
• sidebar: Products section navigation
• pageHeader: Product-specific header

Common Patterns

Global Navigation

Define breadcrumbs or navigation in root layout, extend in nested layouts:

typescript

Section-Specific Sidebars

Add sidebars at section level, inherit in deeper pages:

typescript

Conditional Override

Override parent regions based on page conditions:

typescript

Gotchas & Best Practices

Order Matters

Always spread parent regions first, then define your overrides. Spreading after will erase your changes!

typescript

Type Safety

Parent data is typed as Awaited<ReturnType<typeof import('./$types').LayoutServerLoad>> but regions are unknown. Cast parent data to access regions and use type assertions for specific region data:

typescript

Performance Considerations

await parent() waits for all parent load functions to complete. This is sequential by design and usually fast, but be aware of the dependency chain in deeply nested routes.

For performance optimization tips, see the SvelteKit performance guide.

Pro Tip: Null to Reset

Set a region to null to explicitly remove a parent's region (suppresses both content and fallback):

typescript

Next Steps

API Reference

Complete reference for all exports, types, and interfaces