← UI Rendering & SSR

UI RENDERING & SSR FEATURE

Slot Resources

A slot is not a fragment hack. It is a real resource with its own handler pipeline, template, and lifecycle.

Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

Each page region is its own resource pipeline with the same template system as the main page — no scattered partial glue, no mystery wiring.

Composable Page Regions

Slot resources give every region a real pipeline

This is one of the strongest Semitexa rendering ideas: the page is not one monolith and its regions are not string fragments. Nav, sidebar, widgets, and live panels can all be first-class resources with the same template engine as the main page.

Why this matters

  • Traditional page composition often leaves nav, sidebar, widgets, and footers as special-case includes with hidden data dependencies.
  • Frontend and backend fragments drift apart because each region gets wired by a different mechanism.
  • When regions are not first-class resources, no one can tell where their data really comes from or how they are refreshed.
2 live slot resources in this shell
1 shared Twig system for page and slots
0 mystery data glue between regions

Fragment Sprawl

Includes and ad hoc context passing

Page regions are stitched together manually, and each fragment quietly depends on whatever data happened to be pushed into the template.

The composition works, but nobody can see one explicit pipeline for each region.

First-Class Page Regions

Slot resource pipeline

Each region is a resource with its own handler flow, render context, asset collection, and optional deferred/live lifecycle.

The same template system renders the page, the sidebar, the nav, and reactive slots. One mental model, everywhere.

Slot name Resource class Why it exists Layout call
demo_nav DemoNavSlot Top navigation as a standalone resource {{ layout_slot('demo_nav') }}
demo_sidebar DemoSidebarSlot Feature tree with its own handler pipeline {{ layout_slot('demo_sidebar') }}
#[AsSlotResource] HtmlSlotResponse layout_slot() SlotHandlerPipeline shared Twig

Verified against Semitexa Ultimate 2026.09.19.1020

Slot Resources

A slot is not a fragment hack. It is a real resource with its own handler pipeline, template, and lifecycle. Slot resources turn page regions into first-class response pipelines instead of informal partial includes.

The problem

Traditional page composition often leaves nav, sidebar, widgets, and footers as special-case includes with hidden data dependencies. Frontend and backend fragments drift apart because each region gets wired by a different mechanism. When regions are not first-class resources, no one can tell where their data really comes from or how they are refreshed.

How it works

Each region is a resource with its own handler flow, render context, asset collection, and optional deferred or live lifecycle. The same template system renders the page, the sidebar, the nav, and reactive slots.

layout_slot() composes the shell declaratively while the data flow stays explicit and reviewable.

The rules

  • A slot is a real response object, not a string include or a magical template fragment.
  • Slots use the same Twig system and rendering model as the page itself, so frontend and backend stop speaking different dialects.
  • Each region can evolve independently: own handler, own template, own assets, own deferred or reactive lifecycle.
  • layout_slot() composes the shell declaratively while the data flow stays explicit and reviewable.

Key mechanisms

  • #[AsSlotResource] — registers a named page region as a first-class resource for one layout handle.
  • SlotHandlerPipeline — runs the region through typed slot handlers before it renders.
  • Shared Twig — the page template and the slot template use the same rendering engine and conventions.

© Linus Torvalds: "Talk is cheap. Show me the code."

Fragment Sprawl Example Implementation slice
<aside class="dashboard-sidebar">  {% include 'partials/sidebar-nav.html.twig' with { items: nav_items } %}  {% if user is defined %}    {% include 'partials/sidebar-user-card.html.twig' with {      user: user,      permissions: permissions,      team: current_team    } %}  {% endif %}  {% include 'partials/sidebar-metrics.html.twig' with {    stats: stats,    alerts: alerts,    recommendations: recommendations  } %}</aside>

Unified Template System

One rendering model for the whole shell

The power here is not only composition. It is consistency. The same mental model drives the page resource, the slot resources, deferred regions, and live updates. No extra fragment system, no special frontend dialect.

A slot is a real response object, not a string include or a magical template fragment.

Slots use the same Twig system and rendering model as the page itself, so frontend and backend stop speaking different dialects.

Each region can evolve independently: own handler, own template, own assets, own deferred or reactive lifecycle.

layout_slot() composes the shell declaratively while the data flow stays explicit and reviewable.

Slot concern What Semitexa makes explicit
#[AsSlotResource] Registers a named page region as a first-class resource for one layout handle.
SlotHandlerPipeline Runs the region through typed slot handlers before it renders.
Shared Twig The page template and the slot template use the same rendering engine and conventions.

Support Semitexa
Built for developers who prefer control over magic. Your support helps keep it fast, open, and evolving.

Donate via PayPal