# Marionette 5.0.0 documentation bundle
Version: 5.0.0
Channel: latest
Publication: stable release (published on npm)
Source revision: 0f2284ad4bbfe8c82ce82714471697a68c2acaeb
Local changes: false
Content SHA-256: 44c0d535fd36d11f31d909246f4ee7c6592eae3f25fb7513c61af65842593a90
Read individual documents for focused tasks. Each section below contains the exact published reading Markdown, including its source identity.
---
Document: docs/readme.md
Canonical URL: https://marionettejs.com/docs/
Markdown URL: https://marionettejs.com/docs/index.md
Reading SHA-256: 3d34fd8baf3ac9326ad04402c68ac93bc1b5887d4a4ecb74fa213e7d70769287
# Marionette v5 documentation
These guides target **`marionette` 5.0.0**, whose core is independent of
Backbone and jQuery. Choose the bundled guides for your installed package and
version; applications using legacy **`backbone.marionette`** need their own
contracts. When upgrading from v4, start with the [migration guide](/docs/guides/migration.md).
## Choose a starting point
- New project: [quick start](/docs/quick-start.md) for the first render; use the optional progression below as the feature grows.
- Existing application: choose a task or class reference below; follow additional contracts when needed.
- Agent work: [task routing and lookup](/docs/agents.md), with optional [skill/plugin setup](/docs/tooling.md#agent-installation).
### Learn as the feature grows
1. [Render a View in a Region](/docs/quick-start.md).
2. [Handle DOM events](/docs/api/shared/view-bindings.md#dom-events), then [edit local data](/docs/guides/local-editing.md). A View can save its own model when its data or API layer provides persistence.
3. [Add observable data](/docs/integrations/setup.md) and [compose Views with Regions](/docs/architecture.md#choose-a-responsibility), or [display a list](/docs/guides/lists.md). Optional `@mnjs/data` supplies observation; fetching and persistence require a separate API layer or another data solution.
4. When the feature needs readiness or an independent lifetime, [prepare and activate an Application](/docs/architecture.md#prepare-a-feature-then-activate-its-ui). [Retained restart](/docs/guides/retained-restart.md) repeats readiness while preserving the shell and local input. Child Applications are started or restarted explicitly. [Records](/docs/records.md) brings these pieces together.
## Common tasks
- [Migrate from another framework](/docs/guides/framework-migration.md): preserve journeys and design native ownership.
- [Migrate from v4](/docs/guides/migration.md): update configuration and lifecycle boundaries.
- [Test an application](/docs/guides/testing.md): run interaction, replacement, readiness and teardown checks.
- [Use TypeScript](/docs/guides/typescript.md): typed options, DOM handlers, state and lifecycle results.
- [Edit a View’s own model](/docs/guides/local-editing.md): live edits, local drafts, and API saves.
- [Restart readiness while retaining UI](/docs/guides/retained-restart.md): repeat preparation without rebuilding the shell or draft.
- [Add behavior to existing HTML](/docs/guides/existing-html.md): enhance existing markup and manage its lifetime.
- [Integrate with existing UI](/docs/guides/existing-ui.md): mount, communicate, and clean up under another UI owner.
- [Connect navigation](/docs/guides/routing.md): synchronous or asynchronous destinations, a retained shell, and browser subscriptions.
- [Work with lists](/docs/guides/lists.md): row identity, sorting, filtering, and empty presentation.
- [Integrate a control](/docs/guides/widgets.md): connect an imperative DOM API to View lifetime.
- [Accessibility and rendering](/docs/guides/accessibility-rendering.md): keyboard interaction, focus, and text/HTML boundaries.
- [Build and deploy](/docs/guides/production.md): installed packages, startup ownership, and production delivery checks.
## Core reference
- [API index](/docs/api.md): classes, shared contracts, and current coverage.
- [Application](/docs/api/application.md): feature readiness, child Applications, root ownership, and restart.
- [View](/docs/api/view.md): rendering, bindings, child Regions, and lifecycle.
- [CollectionView](/docs/api/collection-view.md): repeated children, sorting, filtering, and empty presentation.
- [Region](/docs/api/region.md): showing, replacing, retaining, and destroying Views.
- [Behavior](/docs/api/behavior.md): reusable host interactions and lifecycle.
- [MnObject](/docs/api/mnobject.md): nonvisual state, communication, and cleanup.
### Shared contracts and configuration
- [Events](/docs/api/shared/events.md), [state](/docs/api/shared/state.md), [common methods](/docs/api/shared/common.md), and [rendering/View bindings](/docs/api/shared/view-bindings.md) apply across classes.
- [Runtime configuration](/docs/api/runtime.md) explains setters and configuration scope.
- [Rendering/DOM providers](/docs/api/providers/dom.md) and [data/state providers](/docs/api/providers/data.md) define interfaces for supplying integrations.
## Companion packages and integration
- [@mnjs/data: Model and Collection](/docs/packages/data.md): an optional observable data layer with its own operations, events, identity, and disposal. Fetching and persistence require an API layer or another data solution.
- [@mnjs/radio: channels and requests](/docs/packages/radio.md): scoped communication, request/reply handlers, and cleanup.
- [@mnjs/utils](/docs/packages/utils.md): standalone component and object utilities.
- [@mnjs/adapters](/docs/packages/adapters.md): optional Backbone, XState, Lit, Morphdom, and jQuery contracts.
- [Renderer and data setup](/docs/integrations/setup.md): configure Lit and `@mnjs/data`.
The [records source](/docs/source/examples/records/src/main.js) is included for reading alongside the lesson. Its [README](/docs/source/examples/records/README.md) explains the repository development commands.
## Check and debug
[Application tooling](/docs/tooling.md) sets up lint and TypeScript checks and shows diagnostic lookup. Use [errors and diagnostics](/docs/api/errors.md) for the error contract.
## Find these docs from an installed package
From your application's directory:
```sh
node -p "require.resolve('marionette/package.json')"
```
Open `docs/readme.md` beside that package.json. Follow the relative Markdown links to the reference or lesson you need. This works without a documentation server or framework-specific retrieval tool.
[Canonical source](/docs/markdown/docs/readme.md) · [Source identity](/docs/manifest.json)
---
Document: docs/quick-start.md
Canonical URL: https://marionettejs.com/docs/quick-start/
Markdown URL: https://marionettejs.com/docs/quick-start.md
Reading SHA-256: 948bf55302abfe62b870d3a7583aca671578459e4995f4a1c4b65cca27b2ae7f
# Install and render a View
This guide targets Marionette 5.0.0 and is verified on the supported Node LTS lines: Node 22.22.2+ (22.x) or 24.15.0+ (24.x). Use the latest patch of either line. Newer Node versions may install; Node 26 remains advisory until its LTS support is verified. The [documentation index](/docs/index.md) identifies this package version.
## Install matching packages
Use matching `5.0.0` versions of `marionette` and the companion packages: `@mnjs/utils`, `@mnjs/radio`, `@mnjs/adapters`, and optional `@mnjs/data`. Pin the versions explicitly when installing these packages.
## Create the project
Create a project directory:
```sh
mkdir marionette-example
cd marionette-example
npm init -y
npm pkg set type=module scripts.dev="vite" scripts.build="vite build"
npm install --ignore-scripts --save-exact marionette@5.0.0 @mnjs/utils@5.0.0 @mnjs/radio@5.0.0 @mnjs/adapters@5.0.0 lit-html@3.3.3
npm install --ignore-scripts --save-dev --save-exact vite@8.3.0
```
This first UI uses `marionette`, the Lit adapter from `@mnjs/adapters`, and `lit-html`. Core also depends on `@mnjs/utils` and `@mnjs/radio`; the command pins those dependencies to the same release. `@mnjs/data` is optional and is added in the [data setup guide](/docs/integrations/setup.md).
Create `index.html`:
```html
Marionette example
```
Create `main.js`:
```js
import { Region, View, setDomApi } from 'marionette';
import LitDomApi from '@mnjs/adapters/dom/lit-html';
import { html } from 'lit-html';
setDomApi(LitDomApi);
const WelcomeView = View.extend({
template: () => html`Hello, Marionette
`
});
const region = new Region({ el: '#app' });
region.show(new WelcomeView());
```
## Run it
```sh
npm run dev
```
Open the address Vite prints. You should see “Hello, Marionette”. `npm run build` produces a production bundle in `dist`.
The View describes the content. The Region renders and mounts it, then owns replacement and destruction. Calling `region.show(anotherView)` replaces the previous View; `region.empty()` destroys the displayed View.
The Lit DOM adapter is configured once before creating Views. The default renderer calls each template function with its data.
Continue with the [learning progression](/docs/index.md#learn-as-the-feature-grows) for local interaction, data, composition, and Application readiness.
[Canonical source](/docs/markdown/docs/quick-start.md) · [Source identity](/docs/manifest.json)
---
Document: docs/architecture.md
Canonical URL: https://marionettejs.com/docs/architecture/
Markdown URL: https://marionettejs.com/docs/architecture.md
Reading SHA-256: 00127ee0bf8a03f203d621eb00654bfa2715c4911918c187751045e63cf7ce4d
# Building features
Marionette organizes UI around ownership: who prepares a feature, who presents its data, and who removes it. This guide explains those choices for **5.0.0**. Start with the [quick start](/docs/quick-start.md) for renderer setup; use the [API reference](/docs/api.md) for exact method contracts.
## Choose a responsibility
| Responsibility | Use |
| --- | --- |
| Present data and handle local interaction | A [View](/docs/api/view.md). A disclosure or form control can keep its own local state. |
| Place, replace, or remove a child View | A named [Region](/docs/api/region.md), usually declared on the containing View. |
| Present a collection as managed child Views | A [CollectionView](/docs/api/collection-view.md), with a child View for each record. |
| Prepare and coordinate a feature with a start/stop lifetime | An [Application](/docs/api/application.md), owning its UI, shared decisions, and service effects. |
| Reuse interaction behavior across Views | A [Behavior](/docs/api/behavior.md), whose lifetime follows its host View. |
| Own nonvisual state or communication | An [MnObject](/docs/api/mnobject.md), with events, state access, and explicit destruction. |
A View with Regions is enough for visual composition. Add an Application when a feature needs readiness, coordinated effects, or an independently managed lifetime. A parent Application can own the page and start child features even when the parent has no asynchronous preparation. Registering a child establishes ownership; starting it is an explicit decision.
A View can save an edit to its own model when the chosen data layer provides that operation. Keep [local interaction](/docs/api/view.md#local-interaction-and-feature-coordination) in its View and shared workflow decisions with their feature owner.
## Read the ownership tree
```text
Feature Application
├── root View
│ ├── named Region → detail View
│ └── named Region → CollectionView → row Views
└── registered child Application → its own UI
```
Each owner cleans up its children. For an embedded feature, its **host** is the surrounding UI or owner receiving it; the Application's **destination** is the specific Region used by `showView()`. A Behavior's **host** is the View or CollectionView it augments. A destination supplied as an existing Region is borrowed. Owning a root or registering a child Application does not itself show or start it. Models supplied to Views are borrowed data, not branches of this UI ownership tree.
## Prepare a feature, then activate its UI
When a feature needs asynchronous readiness, use an Application and put the required service call in `prepareStart(options, { signal })`. Return the prepared data, then consume it in `onStart(app, options, result)` to create and connect the ready UI. The [Application example](/docs/api/application.md#prepare-before-showing-ui) demonstrates this sequence.
For these feature requests, the Application calls a service/API module; Views receive data and emit user intent. This keeps request decisions at the feature lifetime while individual panels can be replaced. For a composed layout, use the Application's `setView`, populate the layout's Regions with `showChildView`, then mount it with the Application's `showView`.
Show loading or error presentation through Views and Regions. The caller of `start()` handles rejection. When abandoning a failed initial start, call synchronous `stop()` before showing an error View. A failed active restart can show feedback alongside its retained UI.
Notification hooks such as `onStart` do not await returned Promises. If a child must be ready before the parent activates, include that work in parent preparation and handle cleanup if preparation fails. If the page can be ready while its child loads, start the child from the active parent and handle its failure there. See [child Application ownership](/docs/api/application.md#child-applications).
Pass the preparation signal to the service where supported. Marionette prevents a cancelled preparation result from activating the Application. Additional side effects after an `await` must also respect cancellation. Once preparation finishes, that signal is no longer a feature-lifetime signal; later requests need their own policy.
## Choose what survives an operation
| Operation | Lifetime decision |
| --- | --- |
| Replace a panel | Show another View in its Region. The Region destroys the previous View; keep shared data outside that disposable View. |
| Reconstruct a feature | Call `stop()`, then await `start(options)`. The root and child Views are destroyed and startup creates the intended replacement. |
| Restart a feature | `restart()` repeats preparation while retaining the active root, child Applications and state. Successful completion code selects what to update. |
| End a feature permanently | `destroy()` ends its lifetime and destroys owned UI and children. The configured state provider handles owned-state disposal when supported. |
Use `restart()` to repeat feature readiness while retaining its active UI, children, and state event delivery. Apply prepared data in `onStart`, creating the shell only when absent. Current failure leaves the active feature in place; superseded preparation cannot commit. Use stop/start for reconstruction. Independent domain operations, such as saving, still need their own concurrency and cancellation policy.
Retain state at the lifetime that needs it. A local control's state can live in that View. Drafts or pending work that must survive panel replacement belong to a surviving owner. Closing a panel can empty its Region while the feature Application stays active; completions update retained data, and a replacement panel reads that data. Application stop removes its root UI and retains state; restart retains both. See [readiness and ongoing effects](/docs/api/application.md#readiness-and-ongoing-effects) for how ongoing requests use that shared data.
## Share data and communicate intent
Keep one authority for each shared decision. For example, a feature Application can own selection while list and detail Views receive the data they need. A View emits a selection event; the Application listens, changes selection, and chooses which detail View its Region shows. [Child event forwarding](/docs/api/shared/view-bindings.md#child-events) and `listenTo(view, { ... })` connect these boundaries without sibling Views reaching into each other's markup.
Observable data lets several Views respond to the same change. Configure compatible [DataApi and StateApi providers](/docs/integrations/setup.md#configure-once); use model/collection bindings or `stateEvents` for the relevant source. Initialize a new View from current data as well as observing subsequent changes. Application `stateEvents` deliver while active and do not replay changes made while stopped.
Plain data is sufficient when observation is unnecessary. Use [observable data and API access](/docs/integrations/setup.md#observable-data-and-api-access) to choose a data solution and its provider.
State supplied to another object is borrowed. State created through `createState` belongs to its owner; destruction calls the configured provider's disposal method when provided. A View's `model`, `collection`, and state are separate inputs; state is not automatically template data. See [state ownership](/docs/api/shared/state.md#ownership-and-disposal).
## Let Views and Regions manage presentation
Use templates for presentation, CollectionView for repeated children, and Regions for child placement and teardown.
Choose updates at the boundary that changed. Rendering a containing View can destroy child Views, so preserve an active editor when updating an independent status or panel. Bounded changes to a View's own controls, such as a button's disabled state, are appropriate. Keep those updates inside the owning View. The [View rendering contract](/docs/api/view.md) explains child cleanup; the [CollectionView reference](/docs/api/collection-view.md) explains record and child identity.
## Clean up at the ownership boundary
Regions destroy replaced Views. CollectionView destroys removed children. Destroying a Marionette object releases its event subscriptions and incoming callbacks; a retained listener needs no per-View `destroy` handler to call `stopListening(view)`.
Application `stop()` retains the Application, its state, and subscriptions to surviving sources. Explicitly end subscriptions whose purpose lasts only for that run. Release external resources such as timers, service requests, or widget handles at the lifetime that owns them; attaching a resource to an arbitrary property does not make it framework-owned. See [event cleanup](/docs/api/shared/events.md#cleanup).
For a runnable feature using preparation, selection, child Applications, and retry, continue with the [records lesson](/docs/records.md).
[Canonical source](/docs/markdown/docs/architecture.md) · [Source identity](/docs/manifest.json)
---
Document: docs/agents.md
Canonical URL: https://marionettejs.com/docs/agents/
Markdown URL: https://marionettejs.com/docs/agents.md
Reading SHA-256: 5f6c1f9a747519c49931b5090439b1a19fc0248a02707e8cd19d63c44001bd7c
# Work with an agent
Use the docs bundled with the application's installed Marionette package. For framework changes, follow the repository's contributor guidance.
## Find the installed contract
Check the installed package name and version first: **`marionette`** is the v5
package; **`backbone.marionette`** is the legacy package. V5 core requires neither
Backbone nor jQuery; Backbone Models and Collections integrate through optional
adapters. For installed `backbone.marionette` 4.x, preserve v4 contracts unless
upgrading; older releases need their own version-specific guidance. If both
packages are installed, check which entrypoint the feature imports.
From the application directory, resolve the package the feature imports. For v5:
```sh
node -p "require.resolve('marionette/package.json')"
```
For the legacy package instead:
```sh
node -p "require.resolve('backbone.marionette/package.json')"
```
Read the selected package's version and use its matching documentation. The paths
below apply only to v5 and are relative to the installed `marionette` package's
`docs/` directory. For rendering, observation or persistence changes, check the
configured renderer or data provider. Choose one starting page or use an exact API
lookup; follow additional references when the task needs their contract.
Shared API names such as `View.extend`, regions, triggers, `modelEvents`, and
`CollectionView` remain valid in v5, but do not guarantee shared behavior: verify
the v5 contract. For v4 upgrades, read the [migration guide](/docs/guides/migration.md).
If installed docs are absent, obtain the exact release or known source revision. Current website docs may describe a different version.
| Task | Start with |
| --- | --- |
| Install and render a first View | [Quick start](/docs/quick-start.md) |
| Migrate from another UI framework | [Framework migration](/docs/guides/framework-migration.md) |
| Migrate an existing v4 application | [Migration guide](/docs/guides/migration.md) |
| Test interaction, readiness, or teardown | [Consumer testing](/docs/guides/testing.md) |
| Choose ownership and lifetimes | [Architecture](/docs/architecture.md) |
| Bind a DOM event or trigger | [DOM events](/docs/api/shared/view-bindings.md#dom-events) |
| Read or rebind named DOM elements | [UI bindings](/docs/api/shared/view-bindings.md#ui-bindings) |
| Edit a model or retain a draft | [Local editing](/docs/guides/local-editing.md) |
| Prepare, start, restart, or stop a feature | [Application](/docs/api/application.md) |
| Restart while retaining a draft or shell | [Retained restart](/docs/guides/retained-restart.md) |
| Enhance existing markup | [Existing HTML](/docs/guides/existing-html.md) |
| Embed a feature in another UI | [Existing UI](/docs/guides/existing-ui.md) |
| Connect URLs and destination lifetimes | [Navigation](/docs/guides/routing.md) |
| Show, replace, or retain child UI | [Region](/docs/api/region.md) |
| Render, filter, or sort repeated children | [Lists](/docs/guides/lists.md) |
| Share observable data and state | [state](/docs/api/shared/state.md) |
| Connect events and clean up subscriptions | [Events](/docs/api/shared/events.md) |
| Connect channels and request/reply handlers | [Radio](/docs/packages/radio.md) |
| Configure a renderer or another data layer | [Configuration scope](/docs/api/runtime.md#choose-a-configuration-scope) |
| Write typed options, handlers, or lifecycle hooks | [TypeScript guide](/docs/guides/typescript.md) |
| Check types, lint, or diagnose a failure | [Application tooling](/docs/tooling.md) |
| Integrate an imperative control | [Widgets](/docs/guides/widgets.md) |
| Check keyboard, focus, or rendering safety | [Accessibility and rendering](/docs/guides/accessibility-rendering.md) |
| Build and deploy an application | [Production](/docs/guides/production.md) |
| Apply the concepts in a composed feature | [Records lesson](/docs/records.md) |
## Apply the contract
Keep local interaction in its View when that fits the task. An asynchronous call alone does not require an Application. A View may save its own model when the configured data layer supplies that operation. `@mnjs/data` supplies observable Models and Collections; fetching and persistence require an API layer or another provider. It does not supply `Model.save()`.
Use Application preparation for feature readiness and `restart()` to repeat it while retaining active UI. Apply the current result in `onStart`; construct retained shells once. Coordinate shared decisions and work that survives panel replacement at the lifetime that owns them. Read [architecture](/docs/architecture.md) when deciding that ownership.
Read method signatures, event payloads and cleanup for the APIs you change. Verify the affected interaction, including replacement, cancellation or teardown when relevant. A successful build does not establish those outcomes.
## Local contract lookup
Direct Markdown reading is supported. If using the installed skill's helper, choose one lookup from the application directory:
```sh
node /scripts/docs.mjs --section docs/api/view.md#local-interaction-and-feature-coordination
```
Replace `` with the installed or copied skill directory. A section link reads that contract directly. You can also select a named section with `--page docs/api/shared/view-bindings.md --section 'UI bindings'`. Use `--symbol Export.member` for signatures and primary section IDs in `primarySections`, `--search 'query'` when the location is unknown, or `--page SOURCE` for a full page. `--list` lists pages; it is optional. An external package store needs `--package-root `.
A symbol result lists primary contract section IDs in `primarySections` and incidental code mentions in `sections`. Primary routes can span several sections. An empty primary list means no member route has been assigned. `contracts` retains all applicable section IDs and diagnostic codes, including general guidance. Pass a section ID to `--section` to read it.
The helper checks the bundled manifest and hashes and reports the installed version and source revision. These identify the docs read; they do not verify the implementation.
For [skill/plugin installation](/docs/tooling.md#agent-installation) or [hosted MCP identity checks](/docs/tooling.md#hosted-documentation-mcp), follow application tooling.
[Canonical source](/docs/markdown/docs/agents.md) · [Source identity](/docs/manifest.json)
---
Document: docs/api.md
Canonical URL: https://marionettejs.com/docs/api/
Markdown URL: https://marionettejs.com/docs/api.md
Reading SHA-256: 59c7302f667e88687d1ae5756b5a55fb1a604a516208446204d9d5167e2a8f60
# API reference
These references target **5.0.0**. Use the page for the class or contract you need. Class pages define supported APIs and link shared contracts; task guides show how to use them.
## Core classes
| Class | Reference scope |
| --- | --- |
| [View](/docs/api/view.md) | Construction, rendering, UI bindings, named Regions, lifecycle, ownership, and extension points. |
| [Region](/docs/api/region.md) | Showing, replacing, detaching and emptying Views; element configuration and lifecycle. |
| [Application](/docs/api/application.md) | Preparation, lifecycle results/cancellation, restart, child Applications, root ownership, state and Radio bindings. |
| [CollectionView](/docs/api/collection-view.md) | Collection observation, sorting/filtering, empty presentation, child lookup/ownership, rendering and lifecycle. |
| [Behavior](/docs/api/behavior.md) | Host composition, reusable local interaction, UI/data bindings, forwarded events, and teardown. |
| [MnObject](/docs/api/mnobject.md) | Nonvisual objects, construction, state/Radio bindings, and synchronous destruction. |
## Shared class contracts
These behaviors apply across several classes. Class pages link to the relevant contracts.
- [Common class methods](/docs/api/shared/common.md): construction, extension, options and binding helpers.
- [Events](/docs/api/shared/events.md): subscription methods, notification arguments and cleanup.
- [Errors and diagnostics](/docs/api/errors.md): error properties, diagnostic codes, and installed lookup.
- [State](/docs/api/shared/state.md): creating, borrowing, observing and disposing state.
- [Rendering and View bindings](/docs/api/shared/view-bindings.md): templates, UI, DOM/entity events and child event forwarding shared by View and CollectionView.
## Runtime configuration
[Runtime configuration](/docs/api/runtime.md) covers defaults, configuration scope, setters, and isolated class families.
## Provider interfaces
Use these contracts when implementing or adapting an integration. For configuration with supplied packages, start with the [setup guide](/docs/integrations/setup.md).
- [Rendering and DOM providers](/docs/api/providers/dom.md): Renderer, DomApi, and EventDelegator authoring contracts.
- [Data and state providers](/docs/api/providers/data.md): reading, identity, collection notifications, subscriptions, and disposal.
## Companion packages
[@mnjs/data: Model and Collection](/docs/packages/data.md) is an optional observable data solution. Its reference covers operations, events, identity, disposal, and exported types. API access and persistence require a separate solution. Marionette can use another data layer through its core provider contracts.
[@mnjs/radio: channels and requests](/docs/packages/radio.md) covers channel registries, events, replies, cleanup, logging, and standalone use.
[@mnjs/utils: shared utilities](/docs/packages/utils.md) covers standalone component methods, callbacks, object helpers, and exports. Shared Events and class methods remain at their canonical references.
[@mnjs/adapters](/docs/packages/adapters.md) covers optional data and DOM integrations, their imports, configuration, observation, and cleanup.
## Integration and task guides
[Renderer and data setup](/docs/integrations/setup.md) connects Lit and `@mnjs/data` to Marionette. Integration guides explain configuration and use; package references define the APIs supplied by each package.
[Check and debug an application](/docs/tooling.md) covers consumer lint, declaration checks, and diagnostic lookup. [Practical TypeScript](/docs/guides/typescript.md) covers options, handlers, state and lifecycle results. [Migration](/docs/guides/migration.md) and [consumer testing](/docs/guides/testing.md) provide upgrade and verification paths.
[Existing UI](/docs/guides/existing-ui.md) and [navigation](/docs/guides/routing.md) cover mounting and destination ownership. [Lists](/docs/guides/lists.md), [imperative controls](/docs/guides/widgets.md), [accessibility/rendering](/docs/guides/accessibility-rendering.md), and [production](/docs/guides/production.md) provide further task paths.
Class pages link to the relevant [shared configuration contracts](/docs/api/shared/view-bindings.md#class-configuration); Region documents its own DOM setter.
For a first runnable result, use the [quick start](/docs/quick-start.md). For composition guidance, see [architecture](/docs/architecture.md).
Detailed coverage still pending: a complete custom immutable-store integration. The [provider contracts](/docs/api/providers/data.md) describe the integration boundary. Application lifecycle details include [destination binding order](/docs/api/application.md#destination-binding-order) and [restart from start completion](/docs/api/application.md#restart-from-start-completion).
[Canonical source](/docs/markdown/docs/api.md) · [Source identity](/docs/manifest.json)