---
url: >-
  https://lit-ui-router.dev/reference/lit-ui-router-ssr/client/variables/uiViewSlot.md
---
[lit-ui-router-ssr](../../index.md) / [client](../index.md) / uiViewSlot

# Variable: uiViewSlot

```ts
const uiViewSlot: typeof renderLight;
```

Defined in: [packages/lit-ui-router-ssr/src/client.ts:208](https://github.com/simshanith/lit-ui-router/blob/740888c2b2ba358c4dfa52a122e927df6a604b12/packages/lit-ui-router-ssr/src/client.ts#L208)

The hole a `<ui-view>` fills, written at the use site.

On the server `@lit-labs/ssr` reaches the renderer's `renderLight()` only
through this directive in the element's child part, so the routed markup goes
where the template puts it. On the client it wakes the `<ui-view>` it sits
in — the enclosing template hydrating is what reaches the directive, parent
template first — and resolves to `noChange`, so the walk reads past the
interior the server prefixed and a later render of that template leaves the
view's own nodes alone. A view holding a served pair is also pinned to [hydrateRoot](../functions/hydrateRoot.md)'s adopter, so a view the app detaches before its own update —
which sleeps until it is attached again — is adopted on its return; the pin
answers for that one view, once, and comes off. On a cold render there is no
pair to adopt and no attribute to remove.

## Example

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

declare const router: UIRouterLit;

html`<ui-router .uiRouter=${router}><ui-view>${uiViewSlot()}</ui-view></ui-router>`;
```