lit-ui-router-ssr / withServedRender
Function: withServedRender()
function withServedRender(Base): ServedUiViewConstructor & typeof UiView;Defined in: packages/lit-ui-router-ssr/src/served-view.ts:121
Adds the served-render side of <ui-view> to Base.
The result is still a <ui-view>: it extends the class it is given, so instanceof UiView holds, an enclosing view adopts it as a parent, and the ui-view tag map entry still describes it.
What it adds is the element's half of a prerendered page. The view sleeps while defer-hydration is on it, rendering nothing and holding the nodes the server drew. Removing the attribute wakes it: it re-seeks its router, so the render it is about to make reads the settled registration, then requests adoptUiViewContext once and calls the adopter it gets. With none, it drops the held render and renders cold, warning in development. A view detached before that wake update runs stays asleep, holding its nodes, until it is attached again. Whatever the author wrote ahead of the held render is the view's fallback set, taken at the wake and left standing where it is. renderLight() answers the uiViewSlot part with noChange.
lit-ui-router-ssr/register applies it to core's UiView and defines the ui-view tag with the result. Apply it by hand to put a served view under a tag of your own, alongside lit-ui-router/pure, which registers nothing.
Parameters
| Parameter | Type | Description |
|---|---|---|
Base | typeof UiView | core's UiView |
Returns
ServedUiViewConstructor & typeof UiView
the served class, branded
Example
import { UiView } from 'lit-ui-router/pure';
import { withServedRender } from 'lit-ui-router-ssr/client';
customElements.define('app-view', withServedRender(UiView));