lit-ui-router-ssr / lit-ui-router-ssr / UiViewRenderer

Class: UiViewRenderer

Defined in: packages/lit-ui-router-ssr/src/ui-view-renderer.ts:206

Renders the routed component of a <ui-view> into the element's light DOM, between the part markers its client-side render() hydrates against.

The renderer does what the element does on connect: it registers an ActiveUIView with the router's view service under the address its name attribute and its enclosing <ui-view>s spell, takes the ViewConfig the registration syncs back, builds a ResolveContext over that config's path, and hands the view declaration's component the same { router, resolves, transition } props the element hands it. The registration is dropped again as soon as the markup is written, so a render leaves the view service as it found it.

The router comes from the withRouterSync scope prerender opens, so the renderer needs no configuration of its own and goes into elementRenderers as a class.

An address no state routes renders nothing between its markers, which is what the client's own first render of that view produces.

The template comes from core's routedViewTemplate, the helper <ui-view> renders through, so the served markup and the client's first render share one source. A routed LitElement class, plain or sticky, is built by core and written through LitElementRenderer into the first of the two element slots <ui-view> places a class in, with its props assigned before it renders; the served view hands that element back to core at its wake. A LightDomHydrating class is written through LightElementRenderer, its render in its light DOM, and hydrates there in place. Any other class that renders into its own light DOM is written bare, with no shadow root, and renders cold into the element the client adopts.

The pair around the component is written plain, so the walk hydrating the view's surroundings reads it as the uiViewSlot() child part and stops there; every marker between that pair carries the served-marker prefix, so the same walk reads past the view's interior and lit-ui-router-ssr/client reveals it at that view's own wake. Collecting the component's markup to prefix it is synchronous, so a component whose render awaits is not served.

Example

import { html } from 'lit';
import type { UIRouterLit } from 'lit-ui-router';
import { uiViewSlot } from 'lit-ui-router-ssr/client';

// `uiViewSlot()` is the use site's opt-in: it is what reaches this
// renderer's `renderLight()`, and it commits nothing on the client.
const page = (router: UIRouterLit) =>
  html`<ui-router .uiRouter=${router}><ui-view>${uiViewSlot()}</ui-view></ui-router>`;

Extends

• ElementRenderer

Constructors

Constructor

new UiViewRenderer(tagName): UiViewRenderer;

Defined in: node_modules/.pnpm/@lit-labs+ssr@4.1.0_@types+node@24.19.2/node_modules/@lit-labs/ssr/lib/element-renderer.d.ts:45

Called when a custom element is instantiated during a server render.

An ElementRenderer can actually instantiate the custom element class, or it could emulate the element in some other way.

Parameters

Parameter	Type
tagName	string

Returns

UiViewRenderer

Inherited from

ElementRenderer.constructor

Methods

matchesClass()

static matchesClass(_ceClass, tagName): boolean;

Defined in: packages/lit-ui-router-ssr/src/ui-view-renderer.ts:208

Answers for <ui-view>, whatever class the tag is registered with.

Parameters

Parameter	Type
_ceClass	new () => HTMLElement
tagName	string

Returns

boolean

Overrides

ElementRenderer.matchesClass