{"feature":{"section":{"key":"patterns","label":"Patterns","eyebrow":"Composition recipes","icon":"⇄","href":"/patterns"},"slug":"live-regions","title":"Live regions — deferred and reactive slots","summary":"A page region is a real resource with its own pipeline. Mark it deferred and it streams in later as server HTML; add a refresh interval and the server keeps re-rendering it — Late HTML and Live HTML, with no client state machines.","highlights":["#[AsSlotResource]","deferred","refreshInterval","Late HTML / Live HTML","SSE over one stream"],"what":"Traditional page composition leaves nav, sidebars and widgets as special-case includes with hidden data dependencies. Semitexa promotes every region to a first-class slot resource with its own handler flow, render context and assets — rendered through the same Twig as the page.","documentBodyHtml":"
\n

Live regions — deferred and reactive slots

\n

This page covers two pillars at once: Late HTML (deferred blocks) and Live HTML (reactive slots). Both rest on the Region Contract pillar — the idea that a page region is a real resource with its own pipeline, not a partial with lucky context.

\n

A region is a resource, not a fragment

\n

Traditional page composition leaves nav, sidebars, widgets, and footers as special-case includes with hidden data dependencies, each wired by a different mechanism. Semitexa promotes every region to a first-class slot resource:

\n
php
1use Semitexa\\Ssr\\Attribute\\AsSlotResource;23#[AsSlotResource(slot: 'inventory-summary', layout: 'app')]4final class InventorySummarySlot5{6    public function resolve(InventorySummaryResource $resource): InventorySummaryResource7    {8        return $resource->withRows($this->repository->recent());9    }10}
\n

The slot has its own handler flow, its own render context, its own asset collection — and it renders through the same Twig system as the page itself. layout_slot() composes the shell declaratively while the data flow stays explicit and reviewable. You can always answer "where does this region's data come from?" by reading its resource, because the region is declared, not improvised.

\n

Late HTML — deferred blocks

\n

Add deferred: true and the region is marked for late delivery. The page sends its shell immediately; the server then renders the slow region and streams the finished HTML into position over SSE. The browser swaps in HTML — it does not rebuild the page from client state.

\n
php
1#[AsSlotResource(2    slot: 'inventory-summary',3    layout: 'app',4    deferred: true,5    skeletonTemplate: '@app/slots/inventory-summary.skeleton.html.twig',6)]7final class InventorySummarySlot { /* … */ }
\n

A skeletonTemplate gives the region a meaningful placeholder while its final HTML is in transit. The crucial distinction: deferred does not mean "replace SSR with client rendering later." It means late server HTML. The page model stays server-driven from the first byte to the final slot render.

\n

Live HTML — reactive slots

\n

Add a refreshInterval and the region keeps re-rendering itself on a timer. The server renders the slot fresh each cycle, and the page swaps the new HTML into place:

\n
php
1#[AsSlotResource(2    slot: 'inventory-summary',3    layout: 'app',4    deferred: true,5    refreshInterval: 5,   // seconds6)]7final class InventorySummarySlot { /* … */ }
\n

That is the entire live-widget contract. There is no bespoke polling loop, no hand-written reconnection handler, no per-widget HTML-replacement code — the framework owns the timed request, the HTML swap, and SSE connection recovery. Live UI without converting the page into an app shell, and without a second state machine for what is fundamentally "the server re-rendering truth."

\n

One stream, not one stream per widget

\n

All UI streaming rides a single canonical SSE channel, GET /__semitexa_kiss. The page opens that one stream via ui_page_sse_session_meta(...); individual components and slots never open their own connections. Deferred fills, live refreshes, and server-pushed component patches all arrive as typed frames on that single EventSource and flow through the same rendering and patch machinery the rest of the UI already uses. (The collaboration showcase rides this very stream — co-editing is just another consumer of the page's one feed.)

\n

A note on direction, for honesty: these slots are an SSE pull/push-down model — the server re-renders and pushes HTML to the browser. They are not bidirectional websockets. That is deliberate: the pillar is "the server keeps re-rendering truth," and a one-way server→client HTML stream is exactly the right shape for it.

\n

Why it matters

\n

Without a framework-level region contract, every live or deferred region becomes its own little app: its own fetch, its own state, its own reconnection logic, its own divergence from the page. Declaring deferred and refreshInterval on a slot resource keeps the live behaviour co-located with the region's contract and keeps the region inside the one rendering story. The shell and its live widgets never become two architectures, because they were always one.

\n
","how":"deferred: true marks a region for late delivery: the shell paints immediately and the server streams the finished HTML into position over SSE (an optional skeletonTemplate fills the gap). Adding refreshInterval: N keeps the server re-rendering the region on a timer and swapping the new HTML in place — the framework owns the request loop, the HTML swap and SSE reconnection. All of it rides one canonical stream (GET /__semitexa_kiss); slots never open their own connection.","why":"Without a region contract, every live or deferred region becomes its own little app with its own fetch, state and reconnection logic. Declaring deferred and refreshInterval on a slot keeps the live behaviour co-located with the region's contract and inside the one rendering story. The shell and its widgets never become two architectures, because they were always one. The live demo above is a real deferred slot: the skeleton paints first, then the server streams a re-rendered region in — a server tick counter, timestamp and status word that change with no reload (reactive refresh requires the persistent deferred-SSE channel to be enabled).","demo":"platform-live-regions","sources":[],"sourceLabel":"AsSlotResource — deferred + reactive","source":"#[AsSlotResource(\n slot: 'inventory-summary',\n layout: 'app',\n deferred: true,\n refreshInterval: 5, // seconds — server re-renders + swaps HTML\n skeletonTemplate: '@app/slots/inventory-summary.skeleton.html.twig',\n)]\nfinal class InventorySummarySlot\n{\n public function resolve(InventorySummaryResource $resource): InventorySummaryResource\n {\n return $resource->withRows($this->repository->recent());\n }\n}","href":"/patterns/live-regions"},"contract":{"section":"patterns","slug":"live-regions","title":"Live regions — deferred and reactive slots","sectionLabel":"Patterns","backHref":"/patterns","summary":"A page region is a real resource with its own pipeline. Mark it deferred and it streams in later as server HTML; add a refresh interval and the server keeps re-rendering it — Late HTML and Live HTML, with no client state machines.","highlights":["#[AsSlotResource]","deferred","refreshInterval","Late HTML / Live HTML","SSE over one stream"],"documentBodyHtml":"
\n

Live regions — deferred and reactive slots

\n

This page covers two pillars at once: Late HTML (deferred blocks) and Live HTML (reactive slots). Both rest on the Region Contract pillar — the idea that a page region is a real resource with its own pipeline, not a partial with lucky context.

\n

A region is a resource, not a fragment

\n

Traditional page composition leaves nav, sidebars, widgets, and footers as special-case includes with hidden data dependencies, each wired by a different mechanism. Semitexa promotes every region to a first-class slot resource:

\n
php
1use Semitexa\\Ssr\\Attribute\\AsSlotResource;23#[AsSlotResource(slot: 'inventory-summary', layout: 'app')]4final class InventorySummarySlot5{6    public function resolve(InventorySummaryResource $resource): InventorySummaryResource7    {8        return $resource->withRows($this->repository->recent());9    }10}
\n

The slot has its own handler flow, its own render context, its own asset collection — and it renders through the same Twig system as the page itself. layout_slot() composes the shell declaratively while the data flow stays explicit and reviewable. You can always answer "where does this region's data come from?" by reading its resource, because the region is declared, not improvised.

\n

Late HTML — deferred blocks

\n

Add deferred: true and the region is marked for late delivery. The page sends its shell immediately; the server then renders the slow region and streams the finished HTML into position over SSE. The browser swaps in HTML — it does not rebuild the page from client state.

\n
php
1#[AsSlotResource(2    slot: 'inventory-summary',3    layout: 'app',4    deferred: true,5    skeletonTemplate: '@app/slots/inventory-summary.skeleton.html.twig',6)]7final class InventorySummarySlot { /* … */ }
\n

A skeletonTemplate gives the region a meaningful placeholder while its final HTML is in transit. The crucial distinction: deferred does not mean "replace SSR with client rendering later." It means late server HTML. The page model stays server-driven from the first byte to the final slot render.

\n

Live HTML — reactive slots

\n

Add a refreshInterval and the region keeps re-rendering itself on a timer. The server renders the slot fresh each cycle, and the page swaps the new HTML into place:

\n
php
1#[AsSlotResource(2    slot: 'inventory-summary',3    layout: 'app',4    deferred: true,5    refreshInterval: 5,   // seconds6)]7final class InventorySummarySlot { /* … */ }
\n

That is the entire live-widget contract. There is no bespoke polling loop, no hand-written reconnection handler, no per-widget HTML-replacement code — the framework owns the timed request, the HTML swap, and SSE connection recovery. Live UI without converting the page into an app shell, and without a second state machine for what is fundamentally "the server re-rendering truth."

\n

One stream, not one stream per widget

\n

All UI streaming rides a single canonical SSE channel, GET /__semitexa_kiss. The page opens that one stream via ui_page_sse_session_meta(...); individual components and slots never open their own connections. Deferred fills, live refreshes, and server-pushed component patches all arrive as typed frames on that single EventSource and flow through the same rendering and patch machinery the rest of the UI already uses. (The collaboration showcase rides this very stream — co-editing is just another consumer of the page's one feed.)

\n

A note on direction, for honesty: these slots are an SSE pull/push-down model — the server re-renders and pushes HTML to the browser. They are not bidirectional websockets. That is deliberate: the pillar is "the server keeps re-rendering truth," and a one-way server→client HTML stream is exactly the right shape for it.

\n

Why it matters

\n

Without a framework-level region contract, every live or deferred region becomes its own little app: its own fetch, its own state, its own reconnection logic, its own divergence from the page. Declaring deferred and refreshInterval on a slot resource keeps the live behaviour co-located with the region's contract and keeps the region inside the one rendering story. The shell and its live widgets never become two architectures, because they were always one.

\n
","explanation":{"how":"deferred: true marks a region for late delivery: the shell paints immediately and the server streams the finished HTML into position over SSE (an optional skeletonTemplate fills the gap). Adding refreshInterval: N keeps the server re-rendering the region on a timer and swapping the new HTML in place — the framework owns the request loop, the HTML swap and SSE reconnection. All of it rides one canonical stream (GET /__semitexa_kiss); slots never open their own connection.","why":"Without a region contract, every live or deferred region becomes its own little app with its own fetch, state and reconnection logic. Declaring deferred and refreshInterval on a slot keeps the live behaviour co-located with the region's contract and inside the one rendering story. The shell and its widgets never become two architectures, because they were always one. The live demo above is a real deferred slot: the skeleton paints first, then the server streams a re-rendered region in — a server tick counter, timestamp and status word that change with no reload (reactive refresh requires the persistent deferred-SSE channel to be enabled)."},"sourceCode":[{"label":"AsSlotResource — deferred + reactive","code":"#[AsSlotResource(\n slot: 'inventory-summary',\n layout: 'app',\n deferred: true,\n refreshInterval: 5, // seconds — server re-renders + swaps HTML\n skeletonTemplate: '@app/slots/inventory-summary.skeleton.html.twig',\n)]\nfinal class InventorySummarySlot\n{\n public function resolve(InventorySummaryResource $resource): InventorySummaryResource\n {\n return $resource->withRows($this->repository->recent());\n }\n}"}],"demo":"platform-live-regions","href":"/patterns/live-regions"},"sidebarLayers":[{"key":"start-here","type":"feature-links","eyebrow":"Start here","label":"The one idea, then the proof","summary":"Read the rendering thesis first, then watch the same architecture turn static HTML into token-driven, live, interactive UI.","features":[{"slug":"install","title":"Install Platform-UI","summary":"Add the platform-ui package and you have the primitive registry, the grammar compiler, the skin token system and the tiny runtimes — server-side, no build step, no client framework.","href":"/get-started/install"},{"slug":"philosophy","title":"One continuous rendering architecture","summary":"Semitexa is not \"SSR for the first paint, then a second frontend for everything real\". Page, slots, deferred regions, live refresh and interactive components all stay inside one server-owned rendering story.","href":"/concepts/philosophy"},{"slug":"token-driven-ui","title":"Token-driven UI — skins as data","summary":"Visual identity is a data concern, not a code concern. Every primitive reads the active skin's --ui-* tokens, so the same templates render in moss here and terracotta elsewhere with zero component CSS.","href":"/foundations/token-driven-ui"},{"slug":"live-regions","title":"Live regions — deferred and reactive slots","summary":"A page region is a real resource with its own pipeline. Mark it deferred and it streams in later as server HTML; add a refresh interval and the server keeps re-rendering it — Late HTML and Live HTML, with no client state machines.","href":"/patterns/live-regions"}],"featureCount":4},{"key":"full-catalog","type":"section-groups","eyebrow":"Full catalog","label":"Every capability on show","summary":"The complete index — onboarding, rendering concepts, design foundations, the component library, and the composition patterns that make them live.","sectionKeys":["get-started","concepts","foundations","components","patterns"],"featureCount":28,"sections":[{"key":"get-started","label":"Get Started","eyebrow":"Onboarding","icon":"⚑","summary":"The shortest path from nothing to a working, themed, interactive Semitexa UI: install the kit, render your first component, theme the site by swapping tokens, and ship an interactive component — each step a few lines, no client framework.","href":"/get-started","featureCount":4,"starter":false,"groups":[{"key":"setup","label":"Install & render","featureCount":2,"features":[{"slug":"install","title":"Install Platform-UI","section":"get-started","href":"/get-started/install"},{"slug":"first-component","title":"Render your first component","section":"get-started","href":"/get-started/first-component"}]},{"key":"make-it-yours","label":"Make it yours","featureCount":2,"features":[{"slug":"theme-a-site","title":"Theme the site","section":"get-started","href":"/get-started/theme-a-site"},{"slug":"ship-interactive","title":"Ship an interactive component","section":"get-started","href":"/get-started/ship-interactive"}]}],"features":[{"slug":"install","title":"Install Platform-UI","summary":"Add the platform-ui package and you have the primitive registry, the grammar compiler, the skin token system and the tiny runtimes — server-side, no build step, no client framework.","href":"/get-started/install"},{"slug":"first-component","title":"Render your first component","summary":"Drop a primitive() or component() call into any template and it renders server-side, styled entirely by the active skin's tokens — no CSS to write, no client mount.","href":"/get-started/first-component"},{"slug":"theme-a-site","title":"Theme the site","summary":"Re-theme the entire UI by generating a skin and pointing the theme at it — no component touches. Light and dark come from the same token contract.","href":"/get-started/theme-a-site"},{"slug":"ship-interactive","title":"Ship an interactive component","summary":"Add a #[UiOn] handler to a component and the framework signs the event into the page, dispatches it to one endpoint, and patches the reply back — interactivity with no client framework and no bespoke endpoint.","href":"/get-started/ship-interactive"}]},{"key":"concepts","label":"Concepts","eyebrow":"Philosophy","icon":"◆","summary":"The thesis the rest of this handbook proves: page, slots, deferred regions, live refresh and interactive components all stay inside one server-owned rendering story — no second frontend, no presentation-boundary leaks. Start here; everything else is an application of these principles.","href":"/concepts","featureCount":8,"starter":true,"groups":[{"key":"thesis","label":"The thesis","featureCount":1,"features":[{"slug":"philosophy","title":"One continuous rendering architecture","section":"concepts","href":"/concepts/philosophy"}]},{"key":"pillars","label":"The seven pillars","featureCount":7,"features":[{"slug":"page-contract","title":"Page Contract","section":"concepts","href":"/concepts/page-contract"},{"slug":"presentation-boundary","title":"Presentation Boundary","section":"concepts","href":"/concepts/presentation-boundary"},{"slug":"region-contract","title":"Region Contract","section":"concepts","href":"/concepts/region-contract"},{"slug":"late-html","title":"Late HTML","section":"concepts","href":"/concepts/late-html"},{"slug":"live-html","title":"Live HTML","section":"concepts","href":"/concepts/live-html"},{"slug":"interactive-html","title":"Interactive HTML","section":"concepts","href":"/concepts/interactive-html"},{"slug":"framework-free-js","title":"Framework-Free JS","section":"concepts","href":"/concepts/framework-free-js"}]}],"features":[{"slug":"philosophy","title":"One continuous rendering architecture","summary":"Semitexa is not \"SSR for the first paint, then a second frontend for everything real\". Page, slots, deferred regions, live refresh and interactive components all stay inside one server-owned rendering story.","href":"/concepts/philosophy"},{"slug":"page-contract","title":"Page Contract","summary":"The page response is an explicit typed Resource DTO before Twig sees a single field. The template renders a prepared object instead of discovering data as it goes.","href":"/concepts/page-contract"},{"slug":"presentation-boundary","title":"Presentation Boundary","summary":"Templates are presentation surfaces, not data loaders. A template that reaches into storage is a structural failure, not a style preference.","href":"/concepts/presentation-boundary"},{"slug":"region-contract","title":"Region Contract","summary":"A region is a resource with a pipeline, not a partial with lucky context. Each region has its own handler flow, render context and asset collection.","href":"/concepts/region-contract"},{"slug":"late-html","title":"Late HTML","summary":"Deferred blocks stream server-rendered HTML later, instead of handing control to a client renderer. The shell paints immediately; slow regions arrive over SSE as finished HTML.","href":"/concepts/late-html"},{"slug":"live-html","title":"Live HTML","summary":"Reactive slots refresh from server truth without a second state machine. Set a cadence and the server keeps re-rendering the region; the page swaps the new HTML in place.","href":"/concepts/live-html"},{"slug":"interactive-html","title":"Interactive HTML","summary":"Components dispatch backend events while staying inside the SSR component model — no bespoke API glue. A component declares its event contract; the server signs it and runs the handler.","href":"/concepts/interactive-html"},{"slug":"framework-free-js","title":"Framework-Free JS","summary":"JavaScript may enhance the page, but Semitexa refuses to require React, Alpine or Angular as a mandatory second rendering layer. Script stays small, component-owned enhancement.","href":"/concepts/framework-free-js"}]},{"key":"foundations","label":"Foundations","eyebrow":"Design substrate","icon":"◎","summary":"What every component is built on: the --ui-* token contract that makes skins a data concern, and the sx-* / ui-* attribute grammar that composes layouts. Change a token or a skin and the whole UI repaints — no per-component CSS.","href":"/foundations","featureCount":6,"starter":true,"groups":[{"key":"tokens","label":"Tokens","featureCount":2,"features":[{"slug":"token-contract","title":"The token contract","section":"foundations","href":"/foundations/token-contract"},{"slug":"token-driven-ui","title":"Token-driven UI — skins as data","section":"foundations","href":"/foundations/token-driven-ui"}]},{"key":"skins","label":"Skins","featureCount":2,"features":[{"slug":"skin-algorithms","title":"Skin algorithms — balanced, glass, brutalist","section":"foundations","href":"/foundations/skin-algorithms"},{"slug":"generate-refine","title":"Generate & refine skins","section":"foundations","href":"/foundations/generate-refine"}]},{"key":"grammar","label":"Grammar","featureCount":2,"features":[{"slug":"grammar","title":"The sx-* / ui-* grammar","section":"foundations","href":"/foundations/grammar"},{"slug":"css-bundles","title":"Per-route CSS bundles","section":"foundations","href":"/foundations/css-bundles"}]}],"features":[{"slug":"token-contract","title":"The token contract","summary":"One fixed set of design tokens — surfaces, text, accent, state, border, radius, motion, type — that every skin must emit in both light and dark. Components only ever speak this contract; the skin decides the values.","href":"/foundations/token-contract"},{"slug":"token-driven-ui","title":"Token-driven UI — skins as data","summary":"Visual identity is a data concern, not a code concern. Every primitive reads the active skin's --ui-* tokens, so the same templates render in moss here and terracotta elsewhere with zero component CSS.","href":"/foundations/token-driven-ui"},{"slug":"skin-algorithms","title":"Skin algorithms — balanced, glass, brutalist","summary":"Three deterministic algorithms turn a seed colour into a full, accessible token set with a distinct personality. Each exposes a few knobs to tune character without leaving the contract.","href":"/foundations/skin-algorithms"},{"slug":"generate-refine","title":"Generate & refine skins","summary":"Skins are generated from the CLI — deterministically from a seed, or from a natural-language prompt via an optional LLM. Refine an existing skin by adjusting knobs; rebuild re-emits tokens.css from skin.json.","href":"/foundations/generate-refine"},{"slug":"grammar","title":"The sx-* / ui-* grammar","summary":"Declarative composition through two attribute namespaces. sx-* handles layout and spacing on any element; ui-* declares primitive identity and modifiers — an LLM-friendly grammar that resolves entirely from the active skin's tokens.","href":"/foundations/grammar"},{"slug":"css-bundles","title":"Per-route CSS bundles","summary":"The sx-* / ui-* grammar is a fixed vocabulary, so the compiler can scan a template, see exactly which slices it uses, and emit a per-route bundle of only those — typically under 3KB gzipped.","href":"/foundations/css-bundles"}]},{"key":"components","label":"Components","eyebrow":"Building blocks","icon":"▦","summary":"The actual building blocks, by category: primitives (button, input, badge…), form controls with signed server-side validation, and contract-driven data display. Everything reads the active skin's tokens, so the moss palette here applies with zero component-level CSS.","href":"/components","featureCount":6,"starter":false,"groups":[{"key":"primitives","label":"Primitives","featureCount":1,"features":[{"slug":"primitives","title":"Primitives & tokens","section":"components","href":"/components/primitives"}]},{"key":"form-controls","label":"Form controls","featureCount":3,"features":[{"slug":"field","title":"The field component","section":"components","href":"/components/field"},{"slug":"field-validation","title":"Live field validation","section":"components","href":"/components/field-validation"},{"slug":"form","title":"The form component","section":"components","href":"/components/form"}]},{"key":"data-display","label":"Data display","featureCount":2,"features":[{"slug":"contract-grid","title":"Contract-driven grid","section":"components","href":"/components/contract-grid"},{"slug":"live-grid","title":"Live grid — push over SSE","section":"components","href":"/components/live-grid"}]}],"features":[{"slug":"primitives","title":"Primitives & tokens","summary":"Buttons, badges and inputs rendered server-side from the platform-ui primitive registry — drawn entirely by the active skin's design tokens, with no component-level CSS.","href":"/components/primitives"},{"slug":"field","title":"The field component","summary":"A composed form control — label, the input primitive, help and error slots, optional prefix/suffix — bound together by the UiPart model. One declaration renders a complete, accessible field.","href":"/components/field"},{"slug":"field-validation","title":"Live field validation","summary":"A field component whose validation rules are signed into the page and evaluated server-side, patching the message back as you type. The client never holds a rule mirror — validation is authoritative on the server.","href":"/components/field-validation"},{"slug":"form","title":"The form component","summary":"A form whose field definitions are signed into the page and re-validated server-side on submit, then gated by action authorization and security policy before the action runs — client-local validation for feel, server truth for correctness.","href":"/components/form"},{"slug":"contract-grid","title":"Contract-driven grid","summary":"A grid that calls OPTIONS on its feed, reads the served route contract, and builds its columns from it — the template carries only an endpoint pointer, never a column config.","href":"/components/contract-grid"},{"slug":"live-grid","title":"Live grid — push over SSE","summary":"The same contract-driven grid, but the feed is an SSE stream: emit an event and a new row appears live in every open tab, no reload. Pagination, sort and filters from the static grid still apply — live is one declaration on top.","href":"/components/live-grid"}]},{"key":"patterns","label":"Patterns","eyebrow":"Composition recipes","icon":"⇄","summary":"How the building blocks compose into live behaviour: the signed interactive-HTML event runtime, deferred and reactive regions over one SSE stream, and real-time collaboration — each a configuration choice on the same architecture, never a second system.","href":"/patterns","featureCount":4,"starter":false,"groups":[{"key":"composition","label":"Composition","featureCount":1,"features":[{"slug":"composition-model","title":"The composition model — parts","section":"patterns","href":"/patterns/composition-model"}]},{"key":"interactive","label":"Interactive HTML","featureCount":1,"features":[{"slug":"event-runtime","title":"Signed event runtime — interactive HTML","section":"patterns","href":"/patterns/event-runtime"}]},{"key":"live-regions","label":"Live regions","featureCount":1,"features":[{"slug":"live-regions","title":"Live regions — deferred and reactive slots","section":"patterns","href":"/patterns/live-regions"}]},{"key":"collaboration","label":"Collaboration","featureCount":1,"features":[{"slug":"shared-form","title":"Shared live form","section":"patterns","href":"/patterns/shared-form"}]}],"features":[{"slug":"composition-model","title":"The composition model — parts","summary":"Components compose primitives through declared parts — #[UiPart] binds a primitive into a component, #[ProvidesUiPart] computes its structural props, and props resolve in a fixed order — defaults → provider → bind → caller overrides.","href":"/patterns/composition-model"},{"slug":"event-runtime","title":"Signed event runtime — interactive HTML","summary":"Components declare backend events with #[UiOn]. The server emits an inert, signed manifest into the DOM; one tiny runtime captures matching events and posts them to a single dispatch endpoint. No bespoke API glue, no client-trusted routing.","href":"/patterns/event-runtime"},{"slug":"live-regions","title":"Live regions — deferred and reactive slots","summary":"A page region is a real resource with its own pipeline. Mark it deferred and it streams in later as server HTML; add a refresh interval and the server keeps re-rendering it — Late HTML and Live HTML, with no client state machines.","href":"/patterns/live-regions"},{"slug":"shared-form","title":"Shared live form","summary":"Two participants edit one document; field deltas broadcast live over the page's single SSE feed, with echo suppression so the field you are typing in is never clobbered.","href":"/patterns/shared-form"}]}]}],"authenticated":true}