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

# Function: bootstrap()

```ts
function bootstrap(
   router, 
   container, 
   value, 
   options?
): Promise<BootstrapResult>;
```

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

Boots `router` into the page `container` holds, and resolves once that page
is live.

It owns the whole client boot. The boot transition is seeded first, with
`options.payload` when given, and otherwise with the resolves the
container's signature carries ([readResolvePayload](readResolvePayload.md)): each resolve the
document was drawn with adopts its value in place of running its function,
and every other resolve runs as it would without a payload. The
container's [signature](readHydrationSignature.md) is read before
anything else touches the document; a container [hydrateRoot](hydrateRoot.md) would not adopt — no signature, another release line, stripped
markers — is emptied and `value` rendered into it at once, and the router
then starts. Otherwise the router starts, the call waits for the boot
transition to land, following redirects to the one that succeeds, and then
hydrates the container with `value`.

The boot decides once what the page does:

* The boot lands where the signature says the document was drawn: every
  served view adopts, and a view that still mismatches warns in development,
  since that is a template the two halves render differently.
* The boot lands elsewhere — a static host serving one document for a
  family of urls, or a redirect: the views that match adopt, and the views
  that differ render cold without a warning of their own. A view whose
  state, or whose url parameters, its own and inherited, differ from the
  drawn ones renders cold. Once the page is live, a boot into another state
  warns once in development, naming both states and how many views rendered
  cold; a boot into other url parameters of the drawn state is silent.
* The boot fails, or the url starts no transition: the container is emptied
  and `value` rendered cold. The root `hydrate()` throwing, as over a
  mutated document, does the same. The call resolves rather than rejects.

Every served view still reports its own [AdoptOutcome](../type-aliases/AdoptOutcome.md), as a [UiViewAdoptEvent](../type-aliases/UiViewAdoptEvent.md) and to `options.onAdopt`, and the result collects them in
[BootstrapResult.views](../interfaces/BootstrapResult.md#views). Views are tracked by what they report to the
adopter, whose request is a composed event, so a view in a shadow root is
reported like any other; nothing queries the document for views. The call
waits until the views awake under the boot have
updated, nested views and views in shadow roots their hosts hydrated
included, and resolves then, reporting a view the signature lists that has
not woken as `pending`. The adopter stays installed on `container` until
every view the signature lists has reported, so a view whose host hydrates
later still adopts and still reaches `onAdopt`; a view the app detached
keeps its pin. A signed document that booted where it was drawn and adopted
none of the views it was drawn with warns once in development.

In development a sleeping view's "still asleep" warning stands down while
the boot transition runs, and is checked again once the walk has settled.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `router` | [`UIRouterLit`](/reference/lit-ui-router/core/UIRouterLit) | the client router, its states registered and not yet started |
| `container` | `HTMLElement` | the element the server's markup was written into, or an empty one |
| `value` | `unknown` | the same template the server rendered, with every `<ui-view>` hole empty |
| `options?` | [`BootstrapOptions`](../interfaces/BootstrapOptions.md) | lit render options, `onAdopt`, and the boot transition's `payload` and `transport` |

## Returns

`Promise`<[`BootstrapResult`](../interfaces/BootstrapResult.md)>

what the boot came to, and what each view came to, once the awake views have updated

## Example

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

declare const root: HTMLElement;
declare const router: UIRouterLit;
declare function page(router: UIRouterLit): TemplateResult;

const { outcome } = await bootstrap(router, root, page(router));
```

## Throws

what `router.start()` throws, as on a router already started

## Throws

the `TypeError` `seed` throws on a payload with no `resolves`, before the router starts