lit-ui-router-ssr / client / bootstrap

Function: bootstrap()

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

Defined in: packages/lit-ui-router-ssr/src/client.ts:1291

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): 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 is read before anything else touches the document; a container hydrateRoot 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, as a UiViewAdoptEvent and to options.onAdopt, and the result collects them in BootstrapResult.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	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	lit render options, onAdopt, and the boot transition's payload and transport

Returns

Promise<BootstrapResult>

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

Example

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