---
url: /guide/7guis.md
---

# 7 GUIs

To verify that Vue Lynx behaves identically to Vue in real GUI scenarios, we forked the [7 GUIs](https://eugenkiss.github.io/7guis/) examples from the [official Vue.js documentation](https://vuejs.org/examples/#7-guis-counter) — seven classic tasks that cover typical challenges in GUI programming, from a simple counter to a full spreadsheet.

## Examples

### 1. Counter

A simple button that increments a counter. Tests basic state management and event handling.

<Go example="7guis" defaultFile="src/counter/App.vue" entry="src/counter" defaultEntryName="counter" />

### 2. Temperature Converter

Bidirectional conversion between Celsius and Fahrenheit. Tests two-way data flow and constraint handling.

<Go example="7guis" defaultFile="src/temperature-converter/App.vue" entry="src/temperature-converter" defaultEntryName="temperature-converter" />

### 3. Flight Booker

A flight booking form with conditional validation. Tests constraints, conditional visibility, and input validation.

<Go example="7guis" defaultFile="src/flight-booker/App.vue" entry="src/flight-booker" defaultEntryName="flight-booker" />

### 4. Timer

An elapsed-time gauge with adjustable duration. Tests concurrency, competing user/signal interactions, and continuous updates.

<Go example="7guis" defaultFile="src/timer/App.vue" entry="src/timer" defaultEntryName="timer" />

### 5. CRUD

A filterable list with create, read, update, and delete operations. Tests managing a dynamic collection of data.

<Go example="7guis" defaultFile="src/crud/App.vue" entry="src/crud" defaultEntryName="crud" />

### 6. Circle Drawer

Draw circles on a canvas with undo/redo support. Tests custom drawing, a non-trivial undo model, and dialog control flow.

<Go example="7guis" defaultFile="src/circle-drawer/App.vue" entry="src/circle-drawer" defaultEntryName="circle-drawer" />

### 7. Cells

A simple spreadsheet with formula evaluation. Tests change propagation, cell references, and reactive computation.

<Go example="7guis" defaultFile="src/cells/App.vue" entry="src/cells" defaultEntryName="cells" />



---
url: /guide/ai-chat.md
---

# AI Chat

A full-featured AI chatbot ported feature-by-feature from the official [Nuxt AI Chatbot template](https://github.com/nuxt-ui-templates/chat) (Nuxt UI + Vercel AI SDK) — probably the most demanding "real-world" validation of Vue Lynx so far: streaming responses with thinking/reasoning, markdown with highlighted code blocks and tables, tool-call cards (weather, charts, web-search sources), chat history with date grouping, votes, message editing, share/rename/delete flows, a model picker, persisted runtime theming with light/dark mode, attachments, fuzzy command-palette search, and a responsive mobile layout with a slide-over sidebar.

Try the quick prompts below — *"What is the weather in Bordeaux?"* streams a reasoning section and a weather card; *"Show me a chart of sales data"* renders an SVG line chart; *"Help me create a Vue composable"* shows markdown with highlighted code. Scan the QR code in the native tab to run the same bundle in [LynxExplorer](https://lynxjs.org/guide/start/quick-start.html).

<Go example="ai-chat" defaultFile="src/App.vue" />

The playground above runs fully self-contained: the app probes for its API server and, when unreachable, falls back to an in-app demo backend with the same seeded history and deterministic mock AI streams. When you run the example locally with `pnpm dev:server`, the same UI talks to a standalone Node server that reimplements the Nuxt template's API routes — and streams **real models** through the [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) if you set `AI_GATEWAY_API_KEY`.

## Native chat techniques

A polished chat send is not one animation. It is a handoff between the composer, message list, keyboard, and streaming response. [Vercel’s account of building the v0 iOS app](https://vercel.com/blog/how-we-built-the-v0-ios-app) inspired us to describe the work through those visible moments, then trace each moment back to the system that makes it possible.

### The first send establishes the stage

Before an assistant message exists, the app captures the composer and viewport geometry. The outgoing text stays in a temporary animation layer while the app commits the real message, scroll position, and response space. The assistant reveal begins only after that update, so there is no target-position flash.

<TechniqueVideo src="/media/ai-chat/native-first-send.mp4" poster="/media/ai-chat/native-first-send.webp" label="The first native chat message moves from the composer into the conversation" caption="First send: the bubble leaves the composer, settles into its anchor, and makes room for the response." />

The launch distance depends on the bubble height, viewport, composer, and keyboard. We stage the bubble at the captured composer position, commit layout, then start its transform on a later frame. Layout and animation never compete for the same first frame.

### The second send is the real test

Repeat sends expose mistakes that the empty state hides. Native aligns the new user turn at the top, but keeps the previous turn stable until the moving bubble reaches its target. Vue Lynx [`nextTick()`](https://vue.lynxjs.org/guide/api/vue-lynx/Function.nextTick) waits for pending operations to reach the main thread before [`scrollIntoView`](https://lynxjs.org/api/elements/built-in/scroll-view#scrollintoview) performs the final alignment. Only then does the assistant stream appear.

<TechniqueVideo src="/media/ai-chat/native-second-send.mp4" poster="/media/ai-chat/native-second-send.webp" label="A second native chat message travels from the bottom composer to the top anchor" caption="Second send: the old turn remains stable while the next bubble travels to the top anchor." />

Web uses a different policy because it does not have the same native positioning guarantees: observed `scroll-top` updates keep the message list pinned to the bottom during sends and streaming. The interaction stays familiar even when the mechanism changes.

### The keyboard participates in layout

Lynx [`<input>` elements do not avoid the keyboard automatically](https://lynxjs.org/api/elements/built-in/input#keyboard-avoidance). The composer remains absolutely positioned at the bottom and listens for the [`keyboardstatuschanged` global event](https://lynxjs.org/api/lynx-api/event/global-event#keyboardstatuschanged). It applies the reported keyboard height with `setNativeProps`; the message list follows only if it was already following new output.

<TechniqueVideo src="/media/ai-chat/native-keyboard-follow.mp4" poster="/media/ai-chat/native-keyboard-follow.webp" label="The native chat composer follows the iOS keyboard" caption="Keyboard follow: the composer tracks the keyboard while the current turn stays readable." />

### Gesture feedback stays on the main thread

Drawer gestures and press feedback use Vue Lynx [Main Thread Script](https://vue.lynxjs.org/guide/main-thread-script). Functions marked with `'main thread'` update element styles from `main-thread-bindtouch*` events without a background-thread round trip. The regular `tap` handler still performs the application action on Vue’s background thread.

## Porting notes

The port keeps the original's data model (AI SDK v5 `UIMessage` parts over the UI-message-stream protocol) and nearly all of its composable/page logic, while re-implementing the DOM-coupled layers with Lynx elements:

| Aspect | Nuxt original | Vue Lynx |
|--------|---------------|----------|
| **UI kit** | @nuxt/ui v4 (`UChat*`, `UDashboard*`, Reka UI portals) | Hand-built Lynx components (`view`/`text`/`image`/`scroll-view`/`input`) with Nuxt UI's semantic design tokens |
| **Chat state** | `@ai-sdk/vue` `useChat` | Custom `useChat` speaking the same protocol (SSE on web; incremental polling + cancellation on native) |
| **Markdown** | Comark + Shiki (HTML) | Markdown, including tables, → native-node renderer + lightweight code tokenizer |
| **Charts** | nuxt-charts / Unovis (SVG DOM) | Chart generated as an inline SVG string for the native `<svg>` element |
| **Dropdowns / modals** | Anchored popovers, portals | Action sheets + centered modals at app root |
| **Theming** | Tailwind v4 + `app.config` | Runtime `--ui-*` CSS variables via inline vars (17 primary × 5 neutral picker included) |
| **Responsive** | Tailwind `lg:` breakpoint | `SystemInfo.pixelWidth / pixelRatio` branch (no media queries on Lynx) |

The example directory contains a complete [PRD with per-feature parity status](https://github.com/huxpro/vue-lynx/blob/main/examples/ai-chat/PRD.md) (65 features ported/adapted, 10 skipped with reasons), a [PORTING.md](https://github.com/huxpro/vue-lynx/blob/main/examples/ai-chat/PORTING.md) documenting what was reused vs rewritten plus the platform quirks discovered along the way, and [side-by-side screenshot comparisons](https://github.com/huxpro/vue-lynx/blob/main/examples/ai-chat/screenshots/COMPARISON.md) against the live original captured on Lynx for Web.



---
url: /guide/api/plugin/Function.pluginVueLynx.md
---

[vue-lynx/plugin](/guide/api/plugin/index.md) / pluginVueLynx

# Function: pluginVueLynx()

```ts
function pluginVueLynx(options): RsbuildPlugin[]
```

Create rsbuild / rspeedy plugins for Vue-Lynx dual-thread rendering.

Returns an array of two plugins:

1. `@rsbuild/plugin-vue` — Vue SFC support (rspack-vue-loader + VueLoaderPlugin)
2. `lynx:vue` — Lynx dual-thread entry splitting, PAPI bootstrap, and CSS handling

## Parameters

| Parameter | Type |
| ------ | ------ |
| `options` | [`PluginVueLynxOptions`](/guide/api/plugin/Interface.PluginVueLynxOptions.md) |

## Returns

`RsbuildPlugin`\[]

## Defined in

index.ts:206



---
url: /guide/api/plugin/Interface.PluginVueLynxOptions.md
---

[vue-lynx/plugin](/guide/api/plugin/index.md) / PluginVueLynxOptions

# Interface: PluginVueLynxOptions

Options for [pluginVueLynx](/guide/api/plugin/Function.pluginVueLynx.md).

## Properties

| Property | Type | Default value | Description | Defined in |
| ------ | ------ | ------ | ------ | ------ |
| `optionsApi?` | `boolean` | `true` | Whether to enable Vue's Options API support. Disabling it reduces bundle size. | index.ts:55 |
| `prodDevtools?` | `boolean` | `false` | Whether to enable Vue devtools in production builds. | index.ts:61 |
| `enableCSSSelector?` | `boolean` | `true` | Whether to enable CSS selector support in the Lynx template. When enabled, CSS from Vue `<style>` blocks and imported CSS files will be compiled into the Lynx bundle and applied via class selectors. | index.ts:69 |
| `enableCSSInheritance?` | `boolean` | `false` | Whether to enable CSS inheritance in the Lynx engine. When enabled, CSS property values (including CSS custom properties / variables) cascade from parent elements to children, matching standard CSS behavior. Required for design-token patterns where CSS variables are set on a parent and consumed by descendants. | index.ts:79 |
| `customCSSInheritanceList?` | `string`\[] | `undefined` | A list of additional CSS properties to inherit beyond the engine defaults. Only effective when [enableCSSInheritance](/guide/api/plugin/Interface.PluginVueLynxOptions.md) is `true`. | index.ts:86 |
| `enableCSSInlineVariables?` | `boolean` | `false` | Whether to enable CSS custom properties (variables) in inline styles. When enabled, setting `--*` properties via `:style` bindings will be recognized by the Lynx engine at runtime. | index.ts:94 |
| `debugInfoOutside?` | `boolean` | `true` | Whether to place debug info outside the template bundle. Reduces template size in dev builds. | index.ts:101 |
| ~~`autoPixelUnit?`~~ | `boolean` | `true` | Whether to automatically append `'px'` to numeric style values (e.g. `fontSize: 24` → `'24px'`). Dimensionless properties like `flex`, `opacity`, and `zIndex` are never converted. This convenience behavior is **deprecated** and will default to `false` in the next major version. Prefer explicit string units (e.g. `fontSize: '24px'`). **Deprecated** Will default to `false` in the next major version. | index.ts:115 |
| `enableElementTemplates?` | `boolean` | `enableIFR` | Whether to enable element templates (compile-time template lowering). Eligible template subtrees — plain elements with compile-time-known structure — are lowered into "element templates": the static skeleton becomes a straight-line element-creation function executed on the main thread via a single `INSTANTIATE_TEMPLATE` op, and interior dynamic parts ("holes") receive deterministic ids updated through the ordinary ops. This removes the per-static-node vdom/ops/interpreter cost on first render and shrinks the cross-thread payload — for both the normal pipeline and IFR (they compose). Structural features (components, v-if/v-for hosts, slots, refs, directives, `<list>`) always stay on the normal vdom path; lowering is purely an optimization and never changes rendering semantics. Defaults to the value of `enableIFR`: enabling IFR also enables element templates unless this option is explicitly set to `false`. It can still be enabled independently when IFR is off. | index.ts:139 |
| `enableIFR?` | `boolean` | `false` | Whether to enable IFR (Instant First-Frame Rendering). When enabled, the main-thread bundle contains the full Vue runtime and app code (instead of only worklet registrations). The first screen is rendered synchronously on the main thread during `loadTemplate` — before any background JavaScript runs — eliminating the blank-frame gap. When the background thread boots, its initial render is hydrated against the main-thread output instead of being re-applied. Constraints (matching ReactLynx IFR): - First-screen render output must be deterministic and thread-agnostic (no `Math.random()` / `Date.now()` in render, no thread-dependent branching). Divergence is detected and falls back to a full background render, losing the IFR benefit for that screen. - Side effects belong in lifecycle hooks (`onMounted`, `watch` callbacks) — these never run during the main-thread render. - Increases the main-thread bundle size (it now carries the Vue runtime). **See** https://lynxjs.org/guide/interaction/ifr | index.ts:164 |
| `includeWorkletPackages?` | readonly (`string` | `RegExp`)\[] | `[]` | Allowlist of bare-import specifiers whose `'main thread'` worklets should be reached by the MT bundler. The worklet loader follows relative imports (`./foo`, `../bar`) and resolves non-relative imports: path aliases and tsconfig `paths` that point at project source (outside `node_modules`) are followed automatically. Imports resolving INTO `node_modules` are dropped by default — list the package names (or RegExps matching them) here to follow worklets shipped as a published/installed package. Both checkpoints reduce their input to the package root before matching, so a pattern always matches the package name (e.g. `'@my-org/foo'`), never a subpath or the resolved filesystem path: - strings match the root exactly — `'@vue-lynx/motion-mini'` covers the package and all its subpath imports, but NOT `'@vue-lynx/motion-mini-x'`; - a RegExp like `/^@my-org//` matches whether the package is reached as an import or carved out of the `node_modules` loader exclude. **Example** `pluginVueLynx({ includeWorkletPackages: ['@vue-lynx/motion-mini', /^@my-org/lynx-/], })` | index.ts:194 |



---
url: /guide/api/plugin/Variable.LAYERS.md
---

[vue-lynx/plugin](/guide/api/plugin/index.md) / LAYERS

# Variable: LAYERS

```ts
const LAYERS: object;
```

Webpack module layers used to separate the dual-thread bundles.

## Type declaration

### BACKGROUND

```ts
readonly BACKGROUND: "vue:background" = 'vue:background';
```

### MAIN\_THREAD

```ts
readonly MAIN_THREAD: "vue:main-thread" = 'vue:main-thread';
```

## Defined in

layers.ts:6



---
url: /guide/api/plugin/index.md
---

# vue-lynx/plugin

A rsbuild / rspeedy plugin that integrates Vue 3 with Lynx's dual-thread
architecture (Background Thread renderer + Main Thread PAPI executor).

## Example

```ts
// lynx.config.ts
import { defineConfig } from '@lynx-js/rspeedy'
import { pluginVueLynx } from 'vue-lynx/plugin'

export default defineConfig({
  plugins: [pluginVueLynx()],
})
```

## Interfaces

| Interface | Description |
| ------ | ------ |
| [PluginVueLynxOptions](/guide/api/plugin/Interface.PluginVueLynxOptions.md) | Options for [pluginVueLynx](/guide/api/plugin/Function.pluginVueLynx.md). |

## Variables

| Variable | Description |
| ------ | ------ |
| [LAYERS](/guide/api/plugin/Variable.LAYERS.md) | Webpack module layers used to separate the dual-thread bundles. |

## Functions

| Function | Description |
| ------ | ------ |
| [pluginVueLynx](/guide/api/plugin/Function.pluginVueLynx.md) | Create rsbuild / rspeedy plugins for Vue-Lynx dual-thread rendering. |



---
url: /guide/api/testing-library/Function.cleanup.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / cleanup

# Function: cleanup()

```ts
function cleanup(): void
```

## Returns

`void`

## Defined in

packages/testing-library/src/render.ts:35



---
url: /guide/api/testing-library/Function.fireEvent.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / fireEvent

# Function: fireEvent()

```ts
function fireEvent(elem, event): boolean
```

Fire a raw DOM event on a JSDOM element.
Switches to BG thread before dispatching so event handlers run on BG.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `elem` | `Element` |
| `event` | `Event` |

## Returns

`boolean`

## Defined in

packages/testing-library/src/fire-event.ts:46



---
url: /guide/api/testing-library/Function.getQueriesForElement.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / getQueriesForElement

# Function: getQueriesForElement()

```ts
function getQueriesForElement<QueriesToBind, T>(element, queriesToBind?): BoundFunctions<T>
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `QueriesToBind` *extends* `Queries` | `__module` |
| `T` *extends* `Queries` | `QueriesToBind` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `element` | `HTMLElement` |
| `queriesToBind`? | `T` |

## Returns

`BoundFunctions`\<`T`>

## Defined in

node\_modules/.pnpm/@testing-library+dom@10.4.1/node\_modules/@testing-library/dom/types/get-queries-for-element.d.ts:178



---
url: /guide/api/testing-library/Function.render.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / render

# Function: render()

```ts
function render(rootComponent, rootProps?): RenderResult
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `rootComponent` | `Component` |
| `rootProps`? | `Record`\<`string`, `unknown`> |

## Returns

[`RenderResult`](/guide/api/testing-library/Interface.RenderResult.md)

## Defined in

packages/testing-library/src/render.ts:44



---
url: /guide/api/testing-library/Function.waitForUpdate.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / waitForUpdate

# Function: waitForUpdate()

```ts
function waitForUpdate(): Promise<void>
```

Wait for all pending Vue reactive updates to flush through the pipeline.
Use this after programmatic state changes (ref.value = X) that happen
outside of event handlers.

## Returns

`Promise`\<`void`>

## Defined in

packages/testing-library/src/render.ts:103



---
url: /guide/api/testing-library/Function.within.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / within

# Function: within()

```ts
function within<QueriesToBind, T>(element, queriesToBind?): BoundFunctions<T>
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `QueriesToBind` *extends* `Queries` | `__module` |
| `T` *extends* `Queries` | `QueriesToBind` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `element` | `HTMLElement` |
| `queriesToBind`? | `T` |

## Returns

`BoundFunctions`\<`T`>

## Defined in

node\_modules/.pnpm/@testing-library+dom@10.4.1/node\_modules/@testing-library/dom/types/index.d.ts:7



---
url: /guide/api/testing-library/Interface.RenderResult.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / RenderResult

# Interface: RenderResult

## Indexable

\[`key`: `string`]: `any`

## Properties

| Property | Type | Description | Defined in |
| ------ | ------ | ------ | ------ |
| `container` | `Element` | The JSDOM root element (page element) containing all rendered children. | packages/testing-library/src/render.ts:23 |
| `unmount` | () => `void` | Unmount the current Vue app. | packages/testing-library/src/render.ts:25 |
| `rerender` | (`component`: `Component`, `props`?: `Record`\<`string`, `unknown`>) => [`RenderResult`](/guide/api/testing-library/Interface.RenderResult.md) | Re-render with a new root component. | packages/testing-library/src/render.ts:27 |



---
url: /guide/api/testing-library/Variable.eventMap.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / eventMap

# Variable: eventMap

```ts
const eventMap: Record<string, object>;
```

## Defined in

packages/testing-library/src/fire-event.ts:18



---
url: /guide/api/testing-library/Variable.screen.md
---

[vue-lynx/testing-library](/guide/api/testing-library/index.md) / screen

# Variable: screen

```ts
const screen: Screen;
```

## Defined in

node\_modules/.pnpm/@testing-library+dom@10.4.1/node\_modules/@testing-library/dom/types/screen.d.ts:22



---
url: /guide/api/testing-library/index.md
---

# vue-lynx/testing-library

Vue Lynx Testing Library provides simple utilities for testing Vue 3 Lynx components in a Node.js environment. It renders components through the full dual-thread pipeline (Background Thread renderer → Main Thread native elements → JSDOM) so your tests exercise the same code path as production.

> Inspired by [Vue Testing Library](https://testing-library.com/docs/vue-testing-library/intro/) and [@lynx-js/react/testing-library](https://lynxjs.org/api/reactlynx-testing-library/)

For setup instructions and examples, see the [VueLynx Testing Library guide](/guide/testing-library.md).

## Quick Example

```ts
import { expect, it, vi } from 'vitest';
import { h, defineComponent } from 'vue-lynx';
import { render, fireEvent } from 'vue-lynx-testing-library';

it('fires tap event', () => {
  const onClick = vi.fn();
  const Comp = defineComponent({
    setup() {
      return () => h('view', { bindtap: onClick }, [
        h('text', null, 'Click me'),
      ]);
    },
  });

  const { container, getByText } = render(Comp);
  fireEvent.tap(container.querySelector('view')!);

  expect(onClick).toHaveBeenCalledTimes(1);
  expect(getByText('Click me')).not.toBeNull();
});
```

Auto-cleanup is built in — after each test, the rendered app is automatically unmounted and the JSDOM is reset.

## API Reference

| Name | Kind |
| ------ | ------ |
| [cleanup](/guide/api/testing-library/Function.cleanup.md) | Function |
| [fireEvent](/guide/api/testing-library/Function.fireEvent.md) | Function |
| [getQueriesForElement](/guide/api/testing-library/Function.getQueriesForElement.md) | Function |
| [render](/guide/api/testing-library/Function.render.md) | Function |
| [waitForUpdate](/guide/api/testing-library/Function.waitForUpdate.md) | Function |
| [within](/guide/api/testing-library/Function.within.md) | Function |
| [RenderResult](/guide/api/testing-library/Interface.RenderResult.md) | Interface |
| [eventMap](/guide/api/testing-library/Variable.eventMap.md) | Variable |
| [screen](/guide/api/testing-library/Variable.screen.md) | Variable |



---
url: /guide/api/vue-lynx/Class.MainThreadRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / MainThreadRef

# Class: MainThreadRef\<T>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `unknown` |

## Constructors

### new MainThreadRef()

```ts
new MainThreadRef<T>(initValue): MainThreadRef<T>
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `initValue` | `T` |

#### Returns

[`MainThreadRef`](/guide/api/vue-lynx/Class.MainThreadRef.md)\<`T`>

#### Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:41

## Properties

| Property | Modifier | Type | Description | Defined in |
| ------ | ------ | ------ | ------ | ------ |
| `_wvid` | `readonly` | `number` | Worklet value id — used by the Main Thread worklet runtime to resolve. | packages/vue-lynx/runtime/src/main-thread-ref.ts:36 |

## Accessors

### value

#### Get Signature

```ts
get value(): T
```

`.value` — reactive read-only on the Background Thread.
Reading triggers Vue dependency tracking (shallowRef).
Writing is blocked — no BG→MT sync channel exists yet.

##### Returns

`T`

#### Set Signature

```ts
set value(_v): void
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `_v` | `T` |

##### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:56

***

### current

#### Get Signature

```ts
get current(): T
```

`.current` — worklet convention alias, read-only on BG.
On the Main Thread, worklet-runtime replaces this object entirely,
so `.current` is read-write there. On BG it exists only for SWC
worklet transform compatibility.

##### Returns

`T`

#### Set Signature

```ts
set current(_v): void
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `_v` | `T` |

##### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:75

***

### \_initValue

#### Get Signature

```ts
get _initValue(): T
```

The initial value passed to useMainThreadRef().

##### Returns

`T`

#### Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:89

## Methods

### toJSON()

```ts
toJSON(): object
```

Serialize for cross-thread transfer (ops buffer JSON).

#### Returns

`object`

##### \_wvid

```ts
_wvid: number;
```

##### \_initValue

```ts
_initValue: T;
```

#### Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:94



---
url: /guide/api/vue-lynx/Class.ShadowElement.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ShadowElement

# Class: ShadowElement

## Constructors

### new ShadowElement()

```ts
new ShadowElement(type, forceId?): ShadowElement
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` |
| `forceId`? | `number` |

#### Returns

[`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md)

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:78

## Properties

| Property | Modifier | Type | Default value | Defined in |
| ------ | ------ | ------ | ------ | ------ |
| `nextId` | `static` | `number` | `2` | packages/vue-lynx/runtime/src/shadow-element.ts:23 |
| `id` | `public` | `number` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:25 |
| `type` | `public` | `string` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:26 |
| `parent` | `public` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) | `null` | packages/vue-lynx/runtime/src/shadow-element.ts:27 |
| `firstChild` | `public` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) | `null` | packages/vue-lynx/runtime/src/shadow-element.ts:28 |
| `lastChild` | `public` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) | `null` | packages/vue-lynx/runtime/src/shadow-element.ts:29 |
| `prev` | `public` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) | `null` | packages/vue-lynx/runtime/src/shadow-element.ts:30 |
| `next` | `public` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) | `null` | packages/vue-lynx/runtime/src/shadow-element.ts:31 |
| `_textValue` | `public` | `string` | `''` | packages/vue-lynx/runtime/src/shadow-element.ts:36 |
| `_mtCreated` | `public` | `boolean` | `false` | packages/vue-lynx/runtime/src/shadow-element.ts:37 |
| `_mtInserted` | `public` | `boolean` | `false` | packages/vue-lynx/runtime/src/shadow-element.ts:38 |
| `_style` | `public` | `Record`\<`string`, `unknown`> | `{}` | packages/vue-lynx/runtime/src/shadow-element.ts:42 |
| `_vShowHidden` | `public` | `boolean` | `false` | packages/vue-lynx/runtime/src/shadow-element.ts:44 |
| `_baseClass` | `public` | `string` | `''` | packages/vue-lynx/runtime/src/shadow-element.ts:50 |
| `_transitionClasses` | `public` | `Set`\<`string`> | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:51 |
| `_transitionEndId` | `public` | `number` | `0` | packages/vue-lynx/runtime/src/shadow-element.ts:57 |
| `_vModelValue` | `public` | `undefined` | `string` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:60 |
| `_vModelHandler` | `public` | `undefined` | (`data`) => `void` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:61 |
| `_vModelEventProp` | `public` | `undefined` | `string` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:62 |
| `_id` | `public` | `undefined` | `string` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:65 |
| `_cssId` | `public` | `undefined` | `number` | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:70 |
| `_tplHoleKeys` | `public` | `undefined` | `string`\[] | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:75 |
| `_tplHoles` | `public` | `undefined` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md)\[] | `undefined` | packages/vue-lynx/runtime/src/shadow-element.ts:76 |

## Accessors

### \_selector

#### Get Signature

```ts
get _selector(): string
```

CSS attribute selector that uniquely identifies this element on MT.

##### Returns

`string`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:95

## Methods

### invoke()

```ts
invoke(options): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `options` | `uiMethodOptions` |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:103

***

### setNativeProps()

```ts
setNativeProps(nativeProps): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `nativeProps` | `Record`\<`string`, `unknown`> |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:107

***

### fields()

```ts
fields(fieldsParam, callback): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `fieldsParam` | `Record`\<`string`, `boolean`> |
| `callback` | (`data`, `status`) => `void` |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:113

***

### path()

```ts
path(callback): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `callback` | (`data`, `status`) => `void` |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:123

***

### animate()

```ts
animate(animations): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `animations` | `AnimationV2` | `AnimationV2`\[] |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:132

***

### playAnimation()

```ts
playAnimation(ids): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `ids` | `string` | `string`\[] |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:136

***

### pauseAnimation()

```ts
pauseAnimation(ids): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `ids` | `string` | `string`\[] |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:140

***

### cancelAnimation()

```ts
cancelAnimation(ids): SelectorQuery
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `ids` | `string` | `string`\[] |

#### Returns

`SelectorQuery`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:144

***

### insertBefore()

```ts
insertBefore(child, anchor): void
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `child` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |
| `anchor` | `null` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:148

***

### removeChild()

```ts
removeChild(child): void
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `child` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:180



---
url: /guide/api/vue-lynx/Function.Transition.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Transition

# Function: Transition()

```ts
function Transition(props, ctx): any
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `TransitionProps` & `object` |
| `ctx` | `Omit`\<`object`, `"expose"`> |

## Returns

`any`

## Defined in

packages/vue-lynx/runtime/src/Transition.ts:203



---
url: /guide/api/vue-lynx/Function.cloneVNode.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / cloneVNode

# Function: cloneVNode()

```ts
function cloneVNode<T, U>(
   vnode, 
   extraProps?, 
   mergeRef?, 
cloneTransition?): VNode<T, U>
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |
| `U` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `vnode` | [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`T`, `U`, `object`> |
| `extraProps`? | `null` | `Data` & `VNodeProps` |
| `mergeRef`? | `boolean` |
| `cloneTransition`? | `boolean` |

## Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`T`, `U`>

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1294



---
url: /guide/api/vue-lynx/Function.computed.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / computed

# Function: computed()

## computed(getter, debugOptions)

```ts
function computed<T>(getter, debugOptions?): ComputedRef<T>
```

Takes a getter function and returns a readonly reactive ref object for the
returned value from the getter. It can also take an object with get and set
functions to create a writable ref object.

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `getter` | `ComputedGetter`\<`T`> | Function that produces the next value. |
| `debugOptions`? | `DebuggerOptions` | For debugging. See [https://vuejs.org/guide/extras/reactivity-in-depth.html#computed-debugging](https://vuejs.org/guide/extras/reactivity-in-depth.html#computed-debugging). |

### Returns

[`ComputedRef`](/guide/api/vue-lynx/Interface.ComputedRef.md)\<`T`>

### Example

```js
// Creating a readonly computed ref:
const count = ref(1)
const plusOne = computed(() => count.value + 1)

console.log(plusOne.value) // 2
plusOne.value++ // error
```

```js
// Creating a writable computed ref:
const count = ref(1)
const plusOne = computed({
  get: () => count.value + 1,
  set: (val) => {
    count.value = val - 1
  }
})

plusOne.value = 1
console.log(count.value) // 0
```

### See

[https://vuejs.org/api/reactivity-core.html#computed](https://vuejs.org/api/reactivity-core.html#computed)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:6

## computed(options, debugOptions)

```ts
function computed<T, S>(options, debugOptions?): WritableComputedRef<T, S>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `S` | `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `options` | `WritableComputedOptions`\<`T`, `S`> |
| `debugOptions`? | `DebuggerOptions` |

### Returns

[`WritableComputedRef`](/guide/api/vue-lynx/Interface.WritableComputedRef.md)\<`T`, `S`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:6



---
url: /guide/api/vue-lynx/Function.createApp.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / createApp

# Function: createApp()

```ts
function createApp(rootComponent, rootProps?): VueLynxApp
```

Create a Vue Lynx application instance.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `rootComponent` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md) | The root Vue component |
| `rootProps`? | `Record`\<`string`, `unknown`> | Optional props to pass to the root component |

## Returns

[`VueLynxApp`](/guide/api/vue-lynx/Interface.VueLynxApp.md)

A [VueLynxApp](/guide/api/vue-lynx/Interface.VueLynxApp.md) instance

## Example

```ts
import { createApp } from 'vue-lynx';
import App from './App.vue';

createApp(App).mount();
```

## Defined in

packages/vue-lynx/runtime/src/index.ts:180



---
url: /guide/api/vue-lynx/Function.createElementVNode.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / createElementVNode

# Function: createElementVNode()

```ts
function createElementVNode(
   type, 
   props?, 
   children?, 
   patchFlag?, 
   dynamicProps?, 
   shapeFlag?, 
   isBlockNode?, 
   needFullChildrenNormalization?): VNode
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `VNodeTypes` | *typeof* `NULL_DYNAMIC_COMPONENT` | `ClassComponent` |
| `props`? | `null` | `Data` & `VNodeProps` |
| `children`? | `unknown` |
| `patchFlag`? | `number` |
| `dynamicProps`? | `null` | `string`\[] |
| `shapeFlag`? | `number` |
| `isBlockNode`? | `boolean` |
| `needFullChildrenNormalization`? | `boolean` |

## Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1289



---
url: /guide/api/vue-lynx/Function.createPageRoot.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / createPageRoot

# Function: createPageRoot()

```ts
function createPageRoot(): ShadowElement
```

Create the page root shadow element with the reserved id=1.

## Returns

[`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md)

## Defined in

packages/vue-lynx/runtime/src/shadow-element.ts:202



---
url: /guide/api/vue-lynx/Function.createVNode.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / createVNode

# Function: createVNode()

```ts
function createVNode(
   type, 
   props?, 
   children?, 
   patchFlag?, 
   dynamicProps?, 
   isBlockNode?): VNode
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `VNodeTypes` | *typeof* `NULL_DYNAMIC_COMPONENT` | `ClassComponent` |
| `props`? | `null` | `Data` & `VNodeProps` |
| `children`? | `unknown` |
| `patchFlag`? | `number` |
| `dynamicProps`? | `null` | `string`\[] |
| `isBlockNode`? | `boolean` |

## Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1291



---
url: /guide/api/vue-lynx/Function.customRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / customRef

# Function: customRef()

```ts
function customRef<T>(factory): Ref<T>
```

Creates a customized ref with explicit control over its dependency tracking
and updates triggering.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `factory` | `CustomRefFactory`\<`T`> | The function that receives the `track` and `trigger` callbacks. |

## Returns

[`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<`T`>

## See

[https://vuejs.org/api/reactivity-advanced.html#customref](https://vuejs.org/api/reactivity-advanced.html#customref)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:547



---
url: /guide/api/vue-lynx/Function.defineAsyncComponent.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineAsyncComponent

# Function: defineAsyncComponent()

```ts
function defineAsyncComponent<T>(source): T
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` *extends* [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> | () => [`ComponentPublicInstance`](/guide/api/vue-lynx/TypeAlias.ComponentPublicInstance.md)\<`object`, `object`, `object`, `object`, `object`, `object`, `object`, `object`, `false`, `ComponentOptionsBase`\<`any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`>, `object`, `object`, `""`, `object`, `any`> |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `source` | `AsyncComponentLoader`\<`T`> | `AsyncComponentOptions`\<`T`> |

## Returns

`T`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1533



---
url: /guide/api/vue-lynx/Function.defineComponent.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineComponent

# Function: defineComponent()

## defineComponent(setup, options)

```ts
function defineComponent<Props, E, EE, S>(setup, options?): DefineSetupFnComponent<Props, E, S>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `Props` *extends* `Record`\<`string`, `any`> | - |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `EE` *extends* `string` | `string` |
| `S` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`Record`\<`string`, `any`>> | `object` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `setup` | (`props`, `ctx`) => `RenderFunction` | `Promise`\<`RenderFunction`> |
| `options`? | `Pick`\<`ComponentOptions`\<`object`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `string`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`>, `"name"` | `"inheritAttrs"`> & `object` |

### Returns

`DefineSetupFnComponent`\<`Props`, `E`, `S`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:987

## defineComponent(setup, options)

```ts
function defineComponent<Props, E, EE, S>(setup, options?): DefineSetupFnComponent<Props, E, S>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `Props` *extends* `Record`\<`string`, `any`> | - |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `EE` *extends* `string` | `string` |
| `S` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`Record`\<`string`, `any`>> | `object` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `setup` | (`props`, `ctx`) => `RenderFunction` | `Promise`\<`RenderFunction`> |
| `options`? | `Pick`\<`ComponentOptions`\<`object`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `string`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`>, `"name"` | `"inheritAttrs"`> & `object` |

### Returns

`DefineSetupFnComponent`\<`Props`, `E`, `S`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:992

## defineComponent(options)

```ts
function defineComponent<TypeProps, RuntimePropsOptions, RuntimePropsKeys, TypeEmits, RuntimeEmitsOptions, RuntimeEmitsKeys, Data, SetupBindings, Computed, Methods, Mixin, Extends, InjectOptions, InjectKeys, Slots, LocalComponents, Directives, Exposed, Provide, ResolvedEmits, InferredProps, TypeRefs, TypeEl>(options): DefineComponent<InferredProps, SetupBindings, Data, Computed, Methods, Mixin, Extends, ResolvedEmits, RuntimeEmitsKeys, PublicProps, ToResolvedProps<InferredProps, ResolvedEmits>, ExtractDefaultPropTypes<RuntimePropsOptions>, Slots, LocalComponents, Directives, Exposed, Provide, unknown extends TypeProps ? true : false, TypeRefs, TypeEl>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `TypeProps` | - |
| `RuntimePropsOptions` *extends* `ComponentObjectPropsOptions`\<`Data`> | `ComponentObjectPropsOptions`\<`Data`> |
| `RuntimePropsKeys` *extends* `string` | `string` |
| `TypeEmits` *extends* `ComponentTypeEmits` | `object` |
| `RuntimeEmitsOptions` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `RuntimeEmitsKeys` *extends* `string` | `string` |
| `Data` | `object` |
| `SetupBindings` | `object` |
| `Computed` *extends* `ComputedOptions` | `object` |
| `Methods` *extends* `MethodOptions` | `object` |
| `Mixin` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |
| `Extends` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |
| `InjectOptions` *extends* `ComponentInjectOptions` | `object` |
| `InjectKeys` *extends* `string` | `string` |
| `Slots` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`Record`\<`string`, `any`>> | `object` |
| `LocalComponents` *extends* `Record`\<`string`, [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`>> | `object` |
| `Directives` *extends* `Record`\<`string`, [`Directive`](/guide/api/vue-lynx/TypeAlias.Directive.md)\<`any`, `any`, `string`, `any`>> | `object` |
| `Exposed` *extends* `string` | `string` |
| `Provide` *extends* `ComponentProvideOptions` | `ComponentProvideOptions` |
| `ResolvedEmits` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` *extends* `RuntimeEmitsOptions` ? `TypeEmitsToOptions`\<`TypeEmits`> : `RuntimeEmitsOptions` |
| `InferredProps` | `IsKeyValues`\<`TypeProps`> *extends* `true` ? `TypeProps` : `string` *extends* `RuntimePropsKeys` ? `ComponentObjectPropsOptions`\<`Data`> *extends* `RuntimePropsOptions` ? `object` : [`ExtractPropTypes`](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md)\<`RuntimePropsOptions`> : `{ [key in string]?: any }` |
| `TypeRefs` *extends* `Record`\<`string`, `unknown`> | `object` |
| `TypeEl` *extends* `Element` | `any` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `options` | `object` & `ComponentOptionsBase`\<`ToResolvedProps`\<`InferredProps`, `ResolvedEmits`>, `SetupBindings`, `Data`, `Computed`, `Methods`, `Mixin`, `Extends`, `RuntimeEmitsOptions`, `RuntimeEmitsKeys`, `object`, `InjectOptions`, `InjectKeys`, `Slots`, `LocalComponents`, `Directives`, `Exposed`, `Provide`> & `ThisType`\<`CreateComponentPublicInstanceWithMixins`\<`ToResolvedProps`\<`InferredProps`, `ResolvedEmits`>, `SetupBindings`, `Data`, `Computed`, `Methods`, `Mixin`, `Extends`, `ResolvedEmits`, `object`, `object`, `false`, `InjectOptions`, `Slots`, `LocalComponents`, `Directives`, `string`, `object`, `any`, `ComponentProvideOptions`, `IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"P"`> & `EnsureNonVoid`\<`ToResolvedProps`\<`InferredProps`, `ResolvedEmits`>>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"B"`> & `EnsureNonVoid`\<`SetupBindings`>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"D"`> & `EnsureNonVoid`\<`Data`>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"C"`> & `EnsureNonVoid`\<`Computed`>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"M"`> & `EnsureNonVoid`\<`Methods`>, `UnwrapMixinsType`\<`IntersectionMixin`\<`Mixin`> & `IntersectionMixin`\<`Extends`>, `"Defaults"`> & `object`>> |

### Returns

[`DefineComponent`](/guide/api/vue-lynx/TypeAlias.DefineComponent.md)\<`InferredProps`, `SetupBindings`, `Data`, `Computed`, `Methods`, `Mixin`, `Extends`, `ResolvedEmits`, `RuntimeEmitsKeys`, `PublicProps`, `ToResolvedProps`\<`InferredProps`, `ResolvedEmits`>, `ExtractDefaultPropTypes`\<`RuntimePropsOptions`>, `Slots`, `LocalComponents`, `Directives`, `Exposed`, `Provide`, `unknown` *extends* `TypeProps` ? `true` : `false`, `TypeRefs`, `TypeEl`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:997



---
url: /guide/api/vue-lynx/Function.defineEmits.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineEmits

# Function: defineEmits()

## defineEmits(emitOptions)

```ts
function defineEmits<EE>(emitOptions): EmitFn<EE[]>
```

Vue `<script setup>` compiler macro for declaring a component's emitted
events. The expected argument is the same as the component `emits` option.

Example runtime declaration:

```js
const emit = defineEmits(['change', 'update'])
```

Example type-based declaration:

```ts
const emit = defineEmits<{
  // <eventName>: <expected arguments>
  change: []
  update: [value: number] // named tuple syntax
}>()

emit('change')
emit('update', 1)
```

This is only usable inside `<script setup>`, is compiled away in the
output and should **not** be actually called at runtime.

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `EE` *extends* `string` | `string` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `emitOptions` | `EE`\[] |

### Returns

`EmitFn`\<`EE`\[]>

### See

[https://vuejs.org/api/sfc-script-setup.html#defineprops-defineemits](https://vuejs.org/api/sfc-script-setup.html#defineprops-defineemits)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:226

## defineEmits(emitOptions)

```ts
function defineEmits<E>(emitOptions): EmitFn<E>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `emitOptions` | `E` |

### Returns

`EmitFn`\<`E`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:227

## defineEmits()

```ts
function defineEmits<T>(): T extends (...args) => any ? T : ShortEmits<T>
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `ComponentTypeEmits` |

### Returns

`T` *extends* (...`args`) => `any` ? `T` : `ShortEmits`\<`T`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:228



---
url: /guide/api/vue-lynx/Function.defineExpose.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineExpose

# Function: defineExpose()

```ts
function defineExpose<Exposed>(exposed?): void
```

Vue `<script setup>` compiler macro for declaring a component's exposed
instance properties when it is accessed by a parent component via template
refs.

`<script setup>` components are closed by default - i.e. variables inside
the `<script setup>` scope is not exposed to parent unless explicitly exposed
via `defineExpose`.

This is only usable inside `<script setup>`, is compiled away in the
output and should **not** be actually called at runtime.

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `Exposed` *extends* `Record`\<`string`, `any`> | `Record`\<`string`, `any`> |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `exposed`? | `Exposed` |

## Returns

`void`

## See

[https://vuejs.org/api/sfc-script-setup.html#defineexpose](https://vuejs.org/api/sfc-script-setup.html#defineexpose)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:248



---
url: /guide/api/vue-lynx/Function.defineModel.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineModel

# Function: defineModel()

## defineModel(options)

```ts
function defineModel<T, M, G, S>(options): ModelRef<T, M, G, S>
```

Vue `<script setup>` compiler macro for declaring a
two-way binding prop that can be consumed via `v-model` from the parent
component. This will declare a prop with the same name and a corresponding
`update:propName` event.

If the first argument is a string, it will be used as the prop name;
Otherwise the prop name will default to "modelValue". In both cases, you
can also pass an additional object which will be used as the prop's options.

The returned ref behaves differently depending on whether the parent
provided the corresponding v-model props or not:

* If yes, the returned ref's value will always be in sync with the parent
  prop.
* If not, the returned ref will behave like a normal local ref.

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `M` *extends* `PropertyKey` | `string` |
| `G` | `T` |
| `S` | `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `options` | `object` | `object` & `PropOptions`\<`T`, `T`> & `DefineModelOptions`\<`T`, `G`, `S`> |

### Returns

`ModelRef`\<`T`, `M`, `G`, `S`>

### Example

```ts
// default model (consumed via `v-model`)
const modelValue = defineModel<string>()
modelValue.value = "hello"

// default model with options
const modelValue = defineModel<string>({ required: true })

// with specified name (consumed via `v-model:count`)
const count = defineModel<number>('count')
count.value++

// with specified name and default value
const count = defineModel<number>('count', { default: 0 })
```

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:316

## defineModel(options)

```ts
function defineModel<T, M, G, S>(options?): ModelRef<T | undefined, M, G | undefined, S | undefined>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `M` *extends* `PropertyKey` | `string` |
| `G` | `T` |
| `S` | `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `options`? | `PropOptions`\<`T`, `T`> & `DefineModelOptions`\<`T`, `G`, `S`> |

### Returns

`ModelRef`\<`T` | `undefined`, `M`, `G` | `undefined`, `S` | `undefined`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:321

## defineModel(name, options)

```ts
function defineModel<T, M, G, S>(name, options): ModelRef<T, M, G, S>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `M` *extends* `PropertyKey` | `string` |
| `G` | `T` |
| `S` | `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |
| `options` | `object` | `object` & `PropOptions`\<`T`, `T`> & `DefineModelOptions`\<`T`, `G`, `S`> |

### Returns

`ModelRef`\<`T`, `M`, `G`, `S`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:322

## defineModel(name, options)

```ts
function defineModel<T, M, G, S>(name, options?): ModelRef<T | undefined, M, G | undefined, S | undefined>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `M` *extends* `PropertyKey` | `string` |
| `G` | `T` |
| `S` | `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |
| `options`? | `PropOptions`\<`T`, `T`> & `DefineModelOptions`\<`T`, `G`, `S`> |

### Returns

`ModelRef`\<`T` | `undefined`, `M`, `G` | `undefined`, `S` | `undefined`>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:327



---
url: /guide/api/vue-lynx/Function.defineOptions.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineOptions

# Function: defineOptions()

```ts
function defineOptions<RawBindings, D, C, M, Mixin, Extends>(options?): void
```

Vue `<script setup>` compiler macro for declaring a component's additional
options. This should be used only for options that cannot be expressed via
Composition API - e.g. `inheritAttrs`.

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `RawBindings` | `object` |
| `D` | `object` |
| `C` *extends* `ComputedOptions` | `object` |
| `M` *extends* `MethodOptions` | `object` |
| `Mixin` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |
| `Extends` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `options`? | `ComponentOptionsBase`\<`object`, `RawBindings`, `D`, `C`, `M`, `Mixin`, `Extends`, `object`, `string`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`> & `object` |

## Returns

`void`

## See

[https://vuejs.org/api/sfc-script-setup.html#defineoptions](https://vuejs.org/api/sfc-script-setup.html#defineoptions)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:256



---
url: /guide/api/vue-lynx/Function.defineProps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineProps

# Function: defineProps()

## defineProps(props)

```ts
function defineProps<PropNames>(props): Prettify<Readonly<{ [key in PropNames]?: any }>>
```

Vue `<script setup>` compiler macro for declaring component props. The
expected argument is the same as the component `props` option.

Example runtime declaration:

```js
// using Array syntax
const props = defineProps(['foo', 'bar'])
// using Object syntax
const props = defineProps({
  foo: String,
  bar: {
    type: Number,
    required: true
  }
})
```

Equivalent type-based declaration:

```ts
// will be compiled into equivalent runtime declarations
const props = defineProps<{
  foo?: string
  bar: number
}>()
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `PropNames` *extends* `string` | `string` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `PropNames`\[] |

### Returns

`Prettify`\<`Readonly`\<`{ [key in PropNames]?: any }`>>

### See

[https://vuejs.org/api/sfc-script-setup.html#defineprops-defineemits](https://vuejs.org/api/sfc-script-setup.html#defineprops-defineemits)

This is only usable inside `<script setup>`, is compiled away in the
output and should **not** be actually called at runtime.

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:191

## defineProps(props)

```ts
function defineProps<PP>(props): Prettify<Readonly<ExtractPropTypes<PP>>>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `PP` *extends* `ComponentObjectPropsOptions`\<`Data`> | `ComponentObjectPropsOptions`\<`Data`> |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `PP` |

### Returns

`Prettify`\<`Readonly`\<[`ExtractPropTypes`](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md)\<`PP`>>>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:194

## defineProps()

```ts
function defineProps<TypeProps>(): DefineProps<LooseRequired<TypeProps>, BooleanKey<TypeProps>>
```

### Type Parameters

| Type Parameter |
| ------ |
| `TypeProps` |

### Returns

`DefineProps`\<`LooseRequired`\<`TypeProps`>, `BooleanKey`\<`TypeProps`>>

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:195



---
url: /guide/api/vue-lynx/Function.defineSlots.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / defineSlots

# Function: defineSlots()

```ts
function defineSlots<S>(): StrictUnwrapSlotsType<SlotsType<S>>
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `S` *extends* `Record`\<`string`, `any`> | `Record`\<`string`, `any`> |

## Returns

`StrictUnwrapSlotsType`\<[`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`S`>>

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:274



---
url: /guide/api/vue-lynx/Function.effectScope.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / effectScope

# Function: effectScope()

```ts
function effectScope(detached?): EffectScope
```

Creates an effect scope object which can capture the reactive effects (i.e.
computed and watchers) created within it so that these effects can be
disposed together. For detailed use cases of this API, please consult its
corresponding [RFC](https://github.com/vuejs/rfcs/blob/master/active-rfcs/0041-reactivity-effect-scope.md).

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `detached`? | `boolean` | Can be used to create a "detached" effect scope. |

## Returns

`EffectScope`

## See

[https://vuejs.org/api/reactivity-advanced.html#effectscope](https://vuejs.org/api/reactivity-advanced.html#effectscope)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:685



---
url: /guide/api/vue-lynx/Function.getCurrentInstance.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / getCurrentInstance

# Function: getCurrentInstance()

```ts
function getCurrentInstance(): null | ComponentInternalInstance
```

## Returns

`null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1472



---
url: /guide/api/vue-lynx/Function.getCurrentScope.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / getCurrentScope

# Function: getCurrentScope()

```ts
function getCurrentScope(): EffectScope | undefined
```

Returns the current active effect scope if there is one.

## Returns

`EffectScope` | `undefined`

## See

[https://vuejs.org/api/reactivity-advanced.html#getcurrentscope](https://vuejs.org/api/reactivity-advanced.html#getcurrentscope)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:691



---
url: /guide/api/vue-lynx/Function.guardReactiveProps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / guardReactiveProps

# Function: guardReactiveProps()

```ts
function guardReactiveProps(props): Data & VNodeProps | null
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `null` | `Data` & `VNodeProps` |

## Returns

`Data` & `VNodeProps` | `null`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1293



---
url: /guide/api/vue-lynx/Function.h.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / h

# Function: h()

## h(type, children)

```ts
function h<K>(type, children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `K` *extends* keyof `HTMLElementTagNameMap` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `K` |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<K>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `K` *extends* keyof `HTMLElementTagNameMap` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `K` |
| `props`? | `null` | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `HTMLElementEventHandler` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h(
   type, 
   props?, 
   children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` |
| `props`? | `null` | `RawProps` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | *typeof* [`Text`](/guide/api/vue-lynx/Variable.Text.md) | *typeof* [`Comment`](/guide/api/vue-lynx/Variable.Comment.md) |
| `children`? | `string` | `number` | `boolean` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h(
   type, 
   props?, 
   children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | *typeof* [`Text`](/guide/api/vue-lynx/Variable.Text.md) | *typeof* [`Comment`](/guide/api/vue-lynx/Variable.Comment.md) |
| `props`? | `null` |
| `children`? | `string` | `number` | `boolean` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | () => `object` |
| `type.__isFragment` | `true` |
| `children`? | `VNodeArrayChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h(
   type, 
   props?, 
   children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | () => `object` |
| `type.__isFragment` | `true` |
| `props`? | `null` | `RawProps` |
| `children`? | `VNodeArrayChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h(
   type, 
   props, 
   children): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | () => `object` |
| `type.__isTeleport` | `true` |
| `props` | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `TeleportProps` |
| `children` | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | () => `object` |
| `type.__isSuspense` | `true` |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h(
   type, 
   props?, 
   children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | () => `object` |
| `type.__isSuspense` | `true` |
| `props`? | `null` | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `SuspenseProps` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P, E, S>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `P` | - |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `S` *extends* `Record`\<`string`, `any`> | `any` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | [`FunctionalComponent`](/guide/api/vue-lynx/Interface.FunctionalComponent.md)\<`P`, `any`, `S`, `any`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` | `IfAny`\<`S`, `RawSlots`, `S`> |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h<P>(type, children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` | `ConcreteComponent`\<`object`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` | `ConcreteComponent`\<`P`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`P`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `props`? | `null` | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `ComponentOptions`\<`P`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `string`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `Constructor`\<`any`> |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `Constructor`\<`P`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | [`DefineComponent`](/guide/api/vue-lynx/TypeAlias.DefineComponent.md)\<`object`, `object`, `object`, `ComputedOptions`, `MethodOptions`, `ComponentOptionsMixin`, `ComponentOptionsMixin`, `object`, `string`, `PublicProps`, `Readonly`\<[`ExtractPropTypes`](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md)\<`object`>>, `object`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`, `true`, `object`, `any`> |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | [`DefineComponent`](/guide/api/vue-lynx/TypeAlias.DefineComponent.md)\<`P`, `object`, `object`, `ComputedOptions`, `MethodOptions`, `ComponentOptionsMixin`, `ComponentOptionsMixin`, `object`, `string`, `PublicProps`, `Readonly`\<`P` *extends* `ComponentPropsOptions`\<`Data`> ? [`ExtractPropTypes`](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md)\<`P`\<`P`>> : `P`>, `ExtractDefaultPropTypes`\<`P`>, `object`, `object`, `object`, `string`, `ComponentProvideOptions`, `true`, `object`, `any`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, children)

```ts
function h(type, children?): VNode
```

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `children`? | `RawChildren` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803

## h(type, props, children)

```ts
function h<P>(
   type, 
   props?, 
   children?): VNode
```

### Type Parameters

| Type Parameter |
| ------ |
| `P` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `type` | `string` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`P`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> |
| `props`? | `VNodeProps` & `object` & `Record`\<`string`, `any`> & `P` | `object` *extends* `P` ? `null` : `never` |
| `children`? | `RawChildren` | `RawSlots` |

### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)

### Defined in

packages/vue-lynx/runtime/src/index.ts:803



---
url: /guide/api/vue-lynx/Function.hasInjectionContext.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / hasInjectionContext

# Function: hasInjectionContext()

```ts
function hasInjectionContext(): boolean
```

Returns true if `inject()` can be used without warning about being called in the wrong place (e.g. outside of
setup()). This is used by libraries that want to use `inject()` internally without triggering a warning to the end
user. One example is `useRoute()` in `vue-router`.

## Returns

`boolean`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:980



---
url: /guide/api/vue-lynx/Function.inject.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / inject

# Function: inject()

## inject(key)

```ts
function inject<T>(key): T | undefined
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `string` | [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`T`> |

### Returns

`T` | `undefined`

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:972

## inject(key, defaultValue, treatDefaultAsFactory)

```ts
function inject<T>(
   key, 
   defaultValue, 
   treatDefaultAsFactory?): T
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `string` | [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`T`> |
| `defaultValue` | `T` |
| `treatDefaultAsFactory`? | `false` |

### Returns

`T`

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:973

## inject(key, defaultValue, treatDefaultAsFactory)

```ts
function inject<T>(
   key, 
   defaultValue, 
   treatDefaultAsFactory): T
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `string` | [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`T`> |
| `defaultValue` | `T` | () => `T` |
| `treatDefaultAsFactory` | `true` |

### Returns

`T`

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:974



---
url: /guide/api/vue-lynx/Function.isIfrMainThread.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isIfrMainThread

# Function: isIfrMainThread()

```ts
function isIfrMainThread(): boolean
```

## Returns

`boolean`

## Defined in

packages/vue-lynx/runtime/src/ifr-env.ts:28



---
url: /guide/api/vue-lynx/Function.isMemoSame.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isMemoSame

# Function: isMemoSame()

```ts
function isMemoSame(cached, memo): boolean
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `cached` | [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`> |
| `memo` | `any`\[] |

## Returns

`boolean`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1712



---
url: /guide/api/vue-lynx/Function.isProxy.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isProxy

# Function: isProxy()

```ts
function isProxy(value): boolean
```

Checks if an object is a proxy created by [reactive](/guide/api/vue-lynx/Function.reactive.md),
[readonly](/guide/api/vue-lynx/Function.readonly.md), [shallowReactive](/guide/api/vue-lynx/Function.shallowReactive.md) or [shallowReadonly](/guide/api/vue-lynx/Function.shallowReadonly.md).

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `any` | The value to check. |

## Returns

`boolean`

## See

[https://vuejs.org/api/reactivity-utilities.html#isproxy](https://vuejs.org/api/reactivity-utilities.html#isproxy)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:185



---
url: /guide/api/vue-lynx/Function.isReactive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isReactive

# Function: isReactive()

```ts
function isReactive(value): boolean
```

Checks if an object is a proxy created by [reactive](/guide/api/vue-lynx/Function.reactive.md) or
[shallowReactive](/guide/api/vue-lynx/Function.shallowReactive.md) (or [ref](/guide/api/vue-lynx/Function.ref.md) in some cases).

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `unknown` | The value to check. |

## Returns

`boolean`

## Example

```js
isReactive(reactive({}))            // => true
isReactive(readonly(reactive({})))  // => true
isReactive(ref({}).value)           // => true
isReactive(readonly(ref({})).value) // => true
isReactive(ref(true))               // => false
isReactive(shallowRef({}).value)    // => false
isReactive(shallowReactive({}))     // => true
```

## See

[https://vuejs.org/api/reactivity-utilities.html#isreactive](https://vuejs.org/api/reactivity-utilities.html#isreactive)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:164



---
url: /guide/api/vue-lynx/Function.isReadonly.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isReadonly

# Function: isReadonly()

```ts
function isReadonly(value): boolean
```

Checks whether the passed value is a readonly object. The properties of a
readonly object can change, but they can't be assigned directly via the
passed object.

The proxies created by [readonly](/guide/api/vue-lynx/Function.readonly.md) and [shallowReadonly](/guide/api/vue-lynx/Function.shallowReadonly.md) are
both considered readonly, as is a computed ref without a set function.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `unknown` | The value to check. |

## Returns

`boolean`

## See

[https://vuejs.org/api/reactivity-utilities.html#isreadonly](https://vuejs.org/api/reactivity-utilities.html#isreadonly)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:176



---
url: /guide/api/vue-lynx/Function.isRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isRef

# Function: isRef()

```ts
function isRef<T>(r): r is Ref<T, T>
```

Checks if a value is a ref object.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `r` | `unknown` | The value to inspect. |

## Returns

`r is Ref<T, T>`

## See

[https://vuejs.org/api/reactivity-utilities.html#isref](https://vuejs.org/api/reactivity-utilities.html#isref)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:432



---
url: /guide/api/vue-lynx/Function.isShallow.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isShallow

# Function: isShallow()

```ts
function isShallow(value): boolean
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `value` | `unknown` |

## Returns

`boolean`

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:177



---
url: /guide/api/vue-lynx/Function.isVNode.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / isVNode

# Function: isVNode()

```ts
function isVNode(value): value is VNode<RendererNode, RendererElement, Object>
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `value` | `any` |

## Returns

`value is VNode<RendererNode, RendererElement, Object>`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1280



---
url: /guide/api/vue-lynx/Function.markRaw.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / markRaw

# Function: markRaw()

```ts
function markRaw<T>(value): Raw<T>
```

Marks an object so that it will never be converted to a proxy. Returns the
object itself.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `T` | The object to be marked as "raw". |

## Returns

`Raw`\<`T`>

## Example

```js
const foo = markRaw({})
console.log(isReactive(reactive(foo))) // false

// also works when nested inside other reactive objects
const bar = reactive({ foo })
console.log(isReactive(bar.foo)) // false
```

**Warning:** `markRaw()` together with the shallow APIs such as
[shallowReactive](/guide/api/vue-lynx/Function.shallowReactive.md) allow you to selectively opt-out of the default
deep reactive/readonly conversion and embed raw, non-proxied objects in your
state graph.

## See

[https://vuejs.org/api/reactivity-advanced.html#markraw](https://vuejs.org/api/reactivity-advanced.html#markraw)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:235



---
url: /guide/api/vue-lynx/Function.mergeProps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / mergeProps

# Function: mergeProps()

```ts
function mergeProps(...args): Data
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| ...`args` | `Data` & `VNodeProps`\[] |

## Returns

`Data`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1307



---
url: /guide/api/vue-lynx/Function.nextTick.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / nextTick

# Function: nextTick()

```ts
function nextTick(fn?): Promise<void>
```

Wait for the next DOM update flush **and** the main-thread ops acknowledgement.

Unlike standard Vue's `nextTick` which only waits for the scheduler flush,
Vue Lynx's version also waits for the main thread to apply the ops, so
native Lynx elements are fully materialised when the callback fires.

Caveat: some Lynx builds never invoke the `callLepusMethod` callback that
carries the acknowledgement. Until the engine has delivered one real
acknowledgement, each flush falls back to a short timer so `nextTick()`
cannot hang forever — on such engines the materialisation guarantee is
best-effort (a dev-mode warning is logged when the fallback fires). Once a
real acknowledgement has been observed, the strict guarantee applies.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `fn`? | () => `void` | Optional callback to execute after flush |

## Returns

`Promise`\<`void`>

A promise that resolves when the main thread has applied all pending ops

## See

[Vue nextTick](https://vuejs.org/api/general.html#nexttick) — Vue Lynx extends the standard behavior.

## Defined in

packages/vue-lynx/runtime/src/index.ts:250



---
url: /guide/api/vue-lynx/Function.normalizeClass.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / normalizeClass

# Function: normalizeClass()

```ts
function normalizeClass(value): string
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `value` | `unknown` |

## Returns

`string`

## Defined in

node\_modules/.pnpm/@vue+shared@3.5.30/node\_modules/@vue/shared/dist/shared.d.ts:240



---
url: /guide/api/vue-lynx/Function.normalizeProps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / normalizeProps

# Function: normalizeProps()

```ts
function normalizeProps(props): Record<string, any> | null
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `null` | `Record`\<`string`, `any`> |

## Returns

`Record`\<`string`, `any`> | `null`

## Defined in

node\_modules/.pnpm/@vue+shared@3.5.30/node\_modules/@vue/shared/dist/shared.d.ts:241



---
url: /guide/api/vue-lynx/Function.normalizeStyle.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / normalizeStyle

# Function: normalizeStyle()

```ts
function normalizeStyle(value): NormalizedStyle | string | undefined
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `value` | `unknown` |

## Returns

`NormalizedStyle` | `string` | `undefined`

## Defined in

node\_modules/.pnpm/@vue+shared@3.5.30/node\_modules/@vue/shared/dist/shared.d.ts:237



---
url: /guide/api/vue-lynx/Function.onActivated.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onActivated

# Function: onActivated()

```ts
function onActivated(hook, target?): void
```

Registers a hook to be called when the component is inserted into the DOM
as part of a tree cached by `<KeepAlive>`.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `Function` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onactivated)

## Defined in

packages/vue-lynx/runtime/src/index.ts:607



---
url: /guide/api/vue-lynx/Function.onBeforeMount.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onBeforeMount

# Function: onBeforeMount()

```ts
function onBeforeMount(hook, target?): void
```

Registers a hook to be called right before the component is to be mounted.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onbeforemount)

## Defined in

packages/vue-lynx/runtime/src/index.ts:535



---
url: /guide/api/vue-lynx/Function.onBeforeUnmount.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onBeforeUnmount

# Function: onBeforeUnmount()

```ts
function onBeforeUnmount(hook, target?): void
```

Registers a hook to be called right before the component is about to be unmounted.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onbeforeunmount)

## Defined in

packages/vue-lynx/runtime/src/index.ts:551



---
url: /guide/api/vue-lynx/Function.onBeforeUpdate.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onBeforeUpdate

# Function: onBeforeUpdate()

```ts
function onBeforeUpdate(hook, target?): void
```

Registers a hook to be called right before the component is about to update.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onbeforeupdate)

## Defined in

packages/vue-lynx/runtime/src/index.ts:569



---
url: /guide/api/vue-lynx/Function.onDeactivated.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onDeactivated

# Function: onDeactivated()

```ts
function onDeactivated(hook, target?): void
```

Registers a hook to be called when the component is removed from the DOM
as part of a tree cached by `<KeepAlive>`.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `Function` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#ondeactivated)

## Defined in

packages/vue-lynx/runtime/src/index.ts:616



---
url: /guide/api/vue-lynx/Function.onErrorCaptured.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onErrorCaptured

# Function: onErrorCaptured()

```ts
function onErrorCaptured<TError>(hook, target?): void
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `TError` | `Error` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `ErrorCapturedHook`\<`TError`> |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:739



---
url: /guide/api/vue-lynx/Function.onMounted.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onMounted

# Function: onMounted()

```ts
function onMounted(hook, target?): void
```

Registers a callback to be called after the component is mounted.

In Vue Lynx, the callback only runs on the background thread — during an
IFR main-thread first-screen render, registration is a no-op.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onmounted)

## Defined in

packages/vue-lynx/runtime/src/index.ts:527



---
url: /guide/api/vue-lynx/Function.onRenderTracked.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onRenderTracked

# Function: onRenderTracked()

```ts
function onRenderTracked(hook, target?): void
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `DebuggerHook` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:737



---
url: /guide/api/vue-lynx/Function.onRenderTriggered.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onRenderTriggered

# Function: onRenderTriggered()

```ts
function onRenderTriggered(hook, target?): void
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `DebuggerHook` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:736



---
url: /guide/api/vue-lynx/Function.onScopeDispose.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onScopeDispose

# Function: onScopeDispose()

```ts
function onScopeDispose(fn, failSilently?): void
```

Registers a dispose callback on the current active effect scope. The
callback will be invoked when the associated effect scope is stopped.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `fn` | () => `void` | The callback function to attach to the scope's cleanup. |
| `failSilently`? | `boolean` | - |

## Returns

`void`

## See

[https://vuejs.org/api/reactivity-advanced.html#onscopedispose](https://vuejs.org/api/reactivity-advanced.html#onscopedispose)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:699



---
url: /guide/api/vue-lynx/Function.onUnmounted.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onUnmounted

# Function: onUnmounted()

```ts
function onUnmounted(hook, target?): void
```

Registers a callback to be called after the component is unmounted.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onunmounted)

## Defined in

packages/vue-lynx/runtime/src/index.ts:543



---
url: /guide/api/vue-lynx/Function.onUpdated.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onUpdated

# Function: onUpdated()

```ts
function onUpdated(hook, target?): void
```

Registers a callback to be called after the component has updated its DOM tree.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `hook` | `any` |
| `target`? | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) |

## Returns

`void`

## See

[Vue docs](https://vuejs.org/api/composition-api-lifecycle.html#onupdated)

## Defined in

packages/vue-lynx/runtime/src/index.ts:561



---
url: /guide/api/vue-lynx/Function.onWatcherCleanup.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / onWatcherCleanup

# Function: onWatcherCleanup()

```ts
function onWatcherCleanup(
   cleanupFn, 
   failSilently?, 
   owner?): void
```

Registers a cleanup callback on the current active effect. This
registered cleanup callback will be invoked right before the
associated effect re-runs.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `cleanupFn` | () => `void` | The callback function to attach to the effect's cleanup. |
| `failSilently`? | `boolean` | if `true`, will not throw warning when called without an active effect. |
| `owner`? | `ReactiveEffect`\<`any`> | The effect that this cleanup function should be attached to. By default, the current active effect. |

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:750



---
url: /guide/api/vue-lynx/Function.provide.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / provide

# Function: provide()

```ts
function provide<T, K>(key, value): void
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `K` | `string` | `number` | [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`T`> |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `K` |
| `value` | `K` *extends* [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`V`> ? `V` : `T` |

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:971



---
url: /guide/api/vue-lynx/Function.reactive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / reactive

# Function: reactive()

```ts
function reactive<T>(target): Reactive<T>
```

Returns a reactive proxy of the object.

The reactive conversion is "deep": it affects all nested properties. A
reactive object also deeply unwraps any properties that are refs while
maintaining reactivity.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `target` | `T` | The source object. |

## Returns

[`Reactive`](/guide/api/vue-lynx/TypeAlias.Reactive.md)\<`T`>

## Example

```js
const obj = reactive({ count: 0 })
```

## See

[https://vuejs.org/api/reactivity-core.html#reactive](https://vuejs.org/api/reactivity-core.html#reactive)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:44



---
url: /guide/api/vue-lynx/Function.readonly.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / readonly

# Function: readonly()

```ts
function readonly<T>(target): DeepReadonly<UnwrapNestedRefs<T>>
```

Takes an object (reactive or plain) or a ref and returns a readonly proxy to
the original.

A readonly proxy is deep: any nested property accessed will be readonly as
well. It also has the same ref-unwrapping behavior as [reactive](/guide/api/vue-lynx/Function.reactive.md),
except the unwrapped values will also be made readonly.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `target` | `T` | The source object. |

## Returns

[`DeepReadonly`](/guide/api/vue-lynx/TypeAlias.DeepReadonly.md)\<[`UnwrapNestedRefs`](/guide/api/vue-lynx/TypeAlias.UnwrapNestedRefs.md)\<`T`>>

## Example

```js
const original = reactive({ count: 0 })

const copy = readonly(original)

watchEffect(() => {
  // works for reactivity tracking
  console.log(copy.count)
})

// mutating original will trigger watchers relying on the copy
original.count++

// mutating the copy will fail and result in a warning
copy.count++ // warning!
```

## See

[https://vuejs.org/api/reactivity-core.html#readonly](https://vuejs.org/api/reactivity-core.html#readonly)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:114



---
url: /guide/api/vue-lynx/Function.ref.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ref

# Function: ref()

## ref(value)

```ts
function ref<T>(value): [T] extends [Ref] ? IfAny<T, Ref<T>, T> : Ref<UnwrapRef<T>, UnwrapRef<T> | T>
```

Takes an inner value and returns a reactive and mutable ref object, which
has a single property `.value` that points to the inner value.

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `T` | The object to wrap in the ref. |

### Returns

\[`T`] *extends* \[[`Ref`](/guide/api/vue-lynx/Interface.Ref.md)] ? `IfAny`\<`T`, [`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<`T`>, `T`> : [`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<[`UnwrapRef`](/guide/api/vue-lynx/TypeAlias.UnwrapRef.md)\<`T`>, [`UnwrapRef`](/guide/api/vue-lynx/TypeAlias.UnwrapRef.md)\<`T`> | `T`>

### See

[https://vuejs.org/api/reactivity-core.html#ref](https://vuejs.org/api/reactivity-core.html#ref)

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:440

## ref()

```ts
function ref<T>(): Ref<T | undefined>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |

### Returns

[`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<`T` | `undefined`>

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:441



---
url: /guide/api/vue-lynx/Function.runOnBackground.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / runOnBackground

# Function: runOnBackground()

```ts
function runOnBackground<R, Fn>(_fn): (...args) => Promise<R>
```

Call a Background Thread function from a `'main thread'` worklet.

At build time the SWC transform replaces all `runOnBackground(fn)` call
sites. This export exists only for TypeScript import resolution — it is
never called at runtime on the BG thread.

## Type Parameters

| Type Parameter |
| ------ |
| `R` |
| `Fn` *extends* (...`args`) => `R` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `_fn` | `Fn` |

## Returns

`Function`

### Parameters

| Parameter | Type |
| ------ | ------ |
| ...`args` | `Parameters`\<`Fn`> |

### Returns

`Promise`\<`R`>

## Defined in

packages/vue-lynx/runtime/src/run-on-background.ts:141



---
url: /guide/api/vue-lynx/Function.runOnMainThread.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / runOnMainThread

# Function: runOnMainThread()

```ts
function runOnMainThread<R, Fn>(fn): (...args) => Promise<R>
```

Mark a function to be executed on the Main Thread.

Returns a wrapper that, when called from the Background Thread, dispatches
the call to the Main Thread via the worklet runtime and returns a Promise
that resolves to the function's return value.

The SWC worklet transform replaces the `fn` argument with a worklet context
object at build time. Without the transform, `fn` is passed through as-is
(dev warning in non-production builds).

## Type Parameters

| Type Parameter |
| ------ |
| `R` |
| `Fn` *extends* (...`args`) => `R` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `fn` | `Fn` |

## Returns

`Function`

### Parameters

| Parameter | Type |
| ------ | ------ |
| ...`args` | `Parameters`\<`Fn`> |

### Returns

`Promise`\<`R`>

## Example

```ts
const animate = runOnMainThread((x: number) => {
  'main thread'
  element.setStyleProperty('opacity', String(x))
})
await animate(0.5) // executes on Main Thread
```

## Defined in

packages/vue-lynx/runtime/src/cross-thread.ts:41



---
url: /guide/api/vue-lynx/Function.shallowReactive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / shallowReactive

# Function: shallowReactive()

```ts
function shallowReactive<T>(target): ShallowReactive<T>
```

Shallow version of [reactive](/guide/api/vue-lynx/Function.reactive.md).

Unlike [reactive](/guide/api/vue-lynx/Function.reactive.md), there is no deep conversion: only root-level
properties are reactive for a shallow reactive object. Property values are
stored and exposed as-is - this also means properties with ref values will
not be automatically unwrapped.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `target` | `T` | The source object. |

## Returns

`ShallowReactive`\<`T`>

## Example

```js
const state = shallowReactive({
  foo: 1,
  nested: {
    bar: 2
  }
})

// mutating state's own properties is reactive
state.foo++

// ...but does not convert nested objects
isReactive(state.nested) // false

// NOT reactive
state.nested.bar++
```

## See

[https://vuejs.org/api/reactivity-advanced.html#shallowreactive](https://vuejs.org/api/reactivity-advanced.html#shallowreactive)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:79



---
url: /guide/api/vue-lynx/Function.shallowReadonly.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / shallowReadonly

# Function: shallowReadonly()

```ts
function shallowReadonly<T>(target): Readonly<T>
```

Shallow version of [readonly](/guide/api/vue-lynx/Function.readonly.md).

Unlike [readonly](/guide/api/vue-lynx/Function.readonly.md), there is no deep conversion: only root-level
properties are made readonly. Property values are stored and exposed as-is -
this also means properties with ref values will not be automatically
unwrapped.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `target` | `T` | The source object. |

## Returns

`Readonly`\<`T`>

## Example

```js
const state = shallowReadonly({
  foo: 1,
  nested: {
    bar: 2
  }
})

// mutating state's own properties will fail
state.foo++

// ...but works on nested objects
isReadonly(state.nested) // false

// works
state.nested.bar++
```

## See

[https://vuejs.org/api/reactivity-advanced.html#shallowreadonly](https://vuejs.org/api/reactivity-advanced.html#shallowreadonly)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:145



---
url: /guide/api/vue-lynx/Function.shallowRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / shallowRef

# Function: shallowRef()

## shallowRef(value)

```ts
function shallowRef<T>(value): Ref extends T ? T extends Ref ? IfAny<T, ShallowRef<T>, T> : ShallowRef<T> : ShallowRef<T>
```

Shallow version of [ref](/guide/api/vue-lynx/Function.ref.md).

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `value` | `T` | The "inner value" for the shallow ref. |

### Returns

[`Ref`](/guide/api/vue-lynx/Interface.Ref.md) *extends* `T` ? `T` *extends* [`Ref`](/guide/api/vue-lynx/Interface.Ref.md) ? `IfAny`\<`T`, [`ShallowRef`](/guide/api/vue-lynx/TypeAlias.ShallowRef.md)\<`T`>, `T`> : [`ShallowRef`](/guide/api/vue-lynx/TypeAlias.ShallowRef.md)\<`T`> : [`ShallowRef`](/guide/api/vue-lynx/TypeAlias.ShallowRef.md)\<`T`>

### Example

```js
const state = shallowRef({ count: 1 })

// does NOT trigger change
state.value.count = 2

// does trigger change
state.value = { count: 2 }
```

### See

[https://vuejs.org/api/reactivity-advanced.html#shallowref](https://vuejs.org/api/reactivity-advanced.html#shallowref)

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:463

## shallowRef()

```ts
function shallowRef<T>(): ShallowRef<T | undefined>
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |

### Returns

[`ShallowRef`](/guide/api/vue-lynx/TypeAlias.ShallowRef.md)\<`T` | `undefined`>

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:464



---
url: /guide/api/vue-lynx/Function.takeOps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / takeOps

# Function: takeOps()

```ts
function takeOps(): unknown[]
```

## Returns

`unknown`\[]

## Defined in

packages/vue-lynx/runtime/src/ops.ts:15



---
url: /guide/api/vue-lynx/Function.toRaw.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / toRaw

# Function: toRaw()

```ts
function toRaw<T>(observed): T
```

Returns the raw, original object of a Vue-created proxy.

`toRaw()` can return the original object from proxies created by
[reactive](/guide/api/vue-lynx/Function.reactive.md), [readonly](/guide/api/vue-lynx/Function.readonly.md), [shallowReactive](/guide/api/vue-lynx/Function.shallowReactive.md) or
[shallowReadonly](/guide/api/vue-lynx/Function.shallowReadonly.md).

This is an escape hatch that can be used to temporarily read without
incurring proxy access / tracking overhead or write without triggering
changes. It is **not** recommended to hold a persistent reference to the
original object. Use with caution.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `observed` | `T` | The object for which the "raw" value is requested. |

## Returns

`T`

## Example

```js
const foo = {}
const reactiveFoo = reactive(foo)

console.log(toRaw(reactiveFoo) === foo) // true
```

## See

[https://vuejs.org/api/reactivity-advanced.html#toraw](https://vuejs.org/api/reactivity-advanced.html#toraw)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:209



---
url: /guide/api/vue-lynx/Function.toRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / toRef

# Function: toRef()

## toRef(value)

```ts
function toRef<T>(value): T extends () => infer R ? Readonly<Ref<R>> : T extends Ref ? T : Ref<UnwrapRef<T>>
```

Used to normalize values / refs / getters into refs.

### Type Parameters

| Type Parameter |
| ------ |
| `T` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `value` | `T` |

### Returns

`T` *extends* () => infer R ? `Readonly`\<[`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<`R`>> : `T` *extends* [`Ref`](/guide/api/vue-lynx/Interface.Ref.md) ? `T` : [`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<[`UnwrapRef`](/guide/api/vue-lynx/TypeAlias.UnwrapRef.md)\<`T`>>

### Examples

```js
// returns existing refs as-is
toRef(existingRef)

// creates a ref that calls the getter on .value access
toRef(() => props.foo)

// creates normal refs from non-function values
// equivalent to ref(1)
toRef(1)
```

Can also be used to create a ref for a property on a source reactive object.
The created ref is synced with its source property: mutating the source
property will update the ref, and vice-versa.

```js
const state = reactive({
  foo: 1,
  bar: 2
})

const fooRef = toRef(state, 'foo')

// mutating the ref updates the original
fooRef.value++
console.log(state.foo) // 2

// mutating the original also updates the ref
state.foo++
console.log(fooRef.value) // 3
```

### See

[https://vuejs.org/api/reactivity-utilities.html#toref](https://vuejs.org/api/reactivity-utilities.html#toref)

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:604

## toRef(object, key)

```ts
function toRef<T, K>(object, key): ToRef<T[K]>
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |
| `K` *extends* `string` | `number` | `symbol` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `object` | `T` |
| `key` | `K` |

### Returns

`ToRef`\<`T`\[`K`]>

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:605

## toRef(object, key, defaultValue)

```ts
function toRef<T, K>(
   object, 
   key, 
defaultValue): ToRef<Exclude<T[K], undefined>>
```

### Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |
| `K` *extends* `string` | `number` | `symbol` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `object` | `T` |
| `key` | `K` |
| `defaultValue` | `T`\[`K`] |

### Returns

`ToRef`\<`Exclude`\<`T`\[`K`], `undefined`>>

### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:606



---
url: /guide/api/vue-lynx/Function.toRefs.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / toRefs

# Function: toRefs()

```ts
function toRefs<T>(object): ToRefs<T>
```

Converts a reactive object to a plain object where each property of the
resulting object is a ref pointing to the corresponding property of the
original object. Each individual ref is created using [toRef](/guide/api/vue-lynx/Function.toRef.md).

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `object` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `object` | `T` | Reactive object to be made into an object of linked refs. |

## Returns

`ToRefs`\<`T`>

## See

[https://vuejs.org/api/reactivity-utilities.html#torefs](https://vuejs.org/api/reactivity-utilities.html#torefs)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:559



---
url: /guide/api/vue-lynx/Function.toValue.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / toValue

# Function: toValue()

```ts
function toValue<T>(source): T
```

Normalizes values / refs / getters to values.
This is similar to [unref](/guide/api/vue-lynx/Function.unref.md), except that it also normalizes getters.
If the argument is a getter, it will be invoked and its return value will
be returned.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `source` | [`MaybeRefOrGetter`](/guide/api/vue-lynx/TypeAlias.MaybeRefOrGetter.md)\<`T`> | A getter, an existing ref, or a non-function value. |

## Returns

`T`

## Example

```js
toValue(1) // 1
toValue(ref(1)) // 1
toValue(() => 1) // 1
```

## See

[https://vuejs.org/api/reactivity-utilities.html#tovalue](https://vuejs.org/api/reactivity-utilities.html#tovalue)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:526



---
url: /guide/api/vue-lynx/Function.transformToWorklet.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / transformToWorklet

# Function: transformToWorklet()

```ts
function transformToWorklet(obj): JsFnHandle
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `obj` | (...`args`) => `unknown` |

## Returns

`JsFnHandle`

## Defined in

packages/vue-lynx/runtime/src/transform-to-worklet.ts:17



---
url: /guide/api/vue-lynx/Function.triggerRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / triggerRef

# Function: triggerRef()

```ts
function triggerRef(ref): void
```

Force trigger effects that depends on a shallow ref. This is typically used
after making deep mutations to the inner value of a shallow ref.

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `ref` | [`Ref`](/guide/api/vue-lynx/Interface.Ref.md)\<`any`, `any`> | The ref whose tied effects shall be executed. |

## Returns

`void`

## Example

```js
const shallow = shallowRef({
  greet: 'Hello, world'
})

// Logs "Hello, world" once for the first run-through
watchEffect(() => {
  console.log(shallow.value.greet)
})

// This won't trigger the effect because the ref is shallow
shallow.value.greet = 'Hello, universe'

// Logs "Hello, universe"
triggerRef(shallow)
```

## See

[https://vuejs.org/api/reactivity-advanced.html#triggerref](https://vuejs.org/api/reactivity-advanced.html#triggerref)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:490



---
url: /guide/api/vue-lynx/Function.unref.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / unref

# Function: unref()

```ts
function unref<T>(ref): T
```

Returns the inner value if the argument is a ref, otherwise return the
argument itself. This is a sugar function for
`val = isRef(val) ? val.value : val`.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `ref` | [`MaybeRef`](/guide/api/vue-lynx/TypeAlias.MaybeRef.md)\<`T`> | [`ComputedRef`](/guide/api/vue-lynx/Interface.ComputedRef.md)\<`T`> | Ref or plain value to be converted into the plain value. |

## Returns

`T`

## Example

```js
function useFoo(x: number | Ref<number>) {
  const unwrapped = unref(x)
  // unwrapped is guaranteed to be number now
}
```

## See

[https://vuejs.org/api/reactivity-utilities.html#unref](https://vuejs.org/api/reactivity-utilities.html#unref)

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:509



---
url: /guide/api/vue-lynx/Function.useAttrs.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useAttrs

# Function: useAttrs()

```ts
function useAttrs(): SetupContext["attrs"]
```

## Returns

[`SetupContext`](/guide/api/vue-lynx/TypeAlias.SetupContext.md)\[`"attrs"`]

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:364



---
url: /guide/api/vue-lynx/Function.useGlobalEvent.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useGlobalEvent

# Function: useGlobalEvent()

```ts
function useGlobalEvent(eventName, handler): void
```

Registers a listener on Lynx's global event emitter for the current scope.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `eventName` | `string` |
| `handler` | `GlobalEventHandler` |

## Returns

`void`

## Defined in

packages/vue-lynx/runtime/src/use-global-event.ts:14



---
url: /guide/api/vue-lynx/Function.useId.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useId

# Function: useId()

```ts
function useId(): string
```

## Returns

`string`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1542



---
url: /guide/api/vue-lynx/Function.useMainThreadRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useMainThreadRef

# Function: useMainThreadRef()

```ts
function useMainThreadRef<T>(initValue): MainThreadRef<T>
```

Create a MainThreadRef — a ref whose `.value` is reactive (read-only) on
the Background Thread and whose `.current` is read-write on the Main Thread
inside worklet functions.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `initValue` | `T` | Initial value (typically `null` for element refs, or a primitive for shared state). |

## Returns

[`MainThreadRef`](/guide/api/vue-lynx/Class.MainThreadRef.md)\<`T`>

## Example

```ts
const elRef = useMainThreadRef<ViewElement>(null)
// <view :main-thread-ref="elRef" />
```

## Defined in

packages/vue-lynx/runtime/src/main-thread-ref.ts:113



---
url: /guide/api/vue-lynx/Function.useModel.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useModel

# Function: useModel()

```ts
function useModel<M, T, K, G, S>(
   props, 
   name, 
options?): ModelRef<T[K], M, G, S>
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `M` *extends* `PropertyKey` | - |
| `T` *extends* `Record`\<`string`, `any`> | - |
| `K` *extends* `string` | `number` | `symbol` | - |
| `G` | `T`\[`K`] |
| `S` | `T`\[`K`] |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `T` |
| `name` | `K` |
| `options`? | `DefineModelOptions`\<`T`\[`K`], `G`, `S`> |

## Returns

`ModelRef`\<`T`\[`K`], `M`, `G`, `S`>

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1537



---
url: /guide/api/vue-lynx/Function.useSlots.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useSlots

# Function: useSlots()

```ts
function useSlots(): SetupContext["slots"]
```

## Returns

[`SetupContext`](/guide/api/vue-lynx/TypeAlias.SetupContext.md)\[`"slots"`]

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:363



---
url: /guide/api/vue-lynx/Function.useTemplateRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / useTemplateRef

# Function: useTemplateRef()

```ts
function useTemplateRef<T, Keys>(key): TemplateRef<T>
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `unknown` |
| `Keys` *extends* `string` | `string` |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `Keys` |

## Returns

`TemplateRef`\<`T`>

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1540



---
url: /guide/api/vue-lynx/Function.watch.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / watch

# Function: watch()

## watch(source, cb, options)

```ts
function watch<T, Immediate>(
   source, 
   cb, 
   options?): WatchHandle
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `Immediate` *extends* `Readonly`\<`boolean`> | `false` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `source` | `WatchSource`\<`T`> |
| `cb` | `WatchCallback`\<`T`, `MaybeUndefined`\<`T`, `Immediate`>> |
| `options`? | [`WatchOptions`](/guide/api/vue-lynx/Interface.WatchOptions.md)\<`Immediate`> |

### Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1498

## watch(sources, cb, options)

```ts
function watch<T, Immediate>(
   sources, 
   cb, 
   options?): WatchHandle
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` *extends* readonly (`object` | `WatchSource`\<`unknown`>)\[] | - |
| `Immediate` *extends* `Readonly`\<`boolean`> | `false` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `sources` | `T` | readonly \[`T`] |
| `cb` | \[`T`] *extends* \[`ReactiveMarker`] ? `WatchCallback`\<`T`\<`T`>, `MaybeUndefined`\<`T`\<`T`>, `Immediate`>> : `WatchCallback`\<`MapSources`\<`T`, `false`>, `MapSources`\<`T`, `Immediate`>> |
| `options`? | [`WatchOptions`](/guide/api/vue-lynx/Interface.WatchOptions.md)\<`Immediate`> |

### Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1499

## watch(sources, cb, options)

```ts
function watch<T, Immediate>(
   sources, 
   cb, 
   options?): WatchHandle
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` *extends* `MultiWatchSources` | - |
| `Immediate` *extends* `Readonly`\<`boolean`> | `false` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `sources` | \[`...T[]`] |
| `cb` | `WatchCallback`\<`MapSources`\<`T`, `false`>, `MapSources`\<`T`, `Immediate`>> |
| `options`? | [`WatchOptions`](/guide/api/vue-lynx/Interface.WatchOptions.md)\<`Immediate`> |

### Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1500

## watch(source, cb, options)

```ts
function watch<T, Immediate>(
   source, 
   cb, 
   options?): WatchHandle
```

### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` *extends* `object` | - |
| `Immediate` *extends* `Readonly`\<`boolean`> | `false` |

### Parameters

| Parameter | Type |
| ------ | ------ |
| `source` | `T` |
| `cb` | `WatchCallback`\<`T`, `MaybeUndefined`\<`T`, `Immediate`>> |
| `options`? | [`WatchOptions`](/guide/api/vue-lynx/Interface.WatchOptions.md)\<`Immediate`> |

### Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1501



---
url: /guide/api/vue-lynx/Function.watchEffect.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / watchEffect

# Function: watchEffect()

```ts
function watchEffect(effect, options?): WatchHandle
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `effect` | `WatchEffect` |
| `options`? | `WatchEffectOptions` |

## Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1494



---
url: /guide/api/vue-lynx/Function.watchPostEffect.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / watchPostEffect

# Function: watchPostEffect()

```ts
function watchPostEffect(effect, options?): WatchHandle
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `effect` | `WatchEffect` |
| `options`? | `DebuggerOptions` |

## Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1495



---
url: /guide/api/vue-lynx/Function.watchSyncEffect.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / watchSyncEffect

# Function: watchSyncEffect()

```ts
function watchSyncEffect(effect, options?): WatchHandle
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `effect` | `WatchEffect` |
| `options`? | `DebuggerOptions` |

## Returns

[`WatchHandle`](/guide/api/vue-lynx/Interface.WatchHandle.md)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1496



---
url: /guide/api/vue-lynx/Function.withDefaults.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / withDefaults

# Function: withDefaults()

```ts
function withDefaults<T, BKeys, Defaults>(props, defaults): PropsWithDefaults<T, Defaults, BKeys>
```

Vue `<script setup>` compiler macro for providing props default values when
using type-based `defineProps` declaration.

Example usage:

```ts
withDefaults(defineProps<{
  size?: number
  labels?: string[]
}>(), {
  size: 3,
  labels: () => ['default label']
})
```

This is only usable inside `<script setup>`, is compiled away in the output
and should **not** be actually called at runtime.

## Type Parameters

| Type Parameter |
| ------ |
| `T` |
| `BKeys` *extends* `string` | `number` | `symbol` |
| `Defaults` *extends* `InferDefaults`\<`T`> |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `DefineProps`\<`T`, `BKeys`> |
| `defaults` | `Defaults` |

## Returns

`PropsWithDefaults`\<`T`, `Defaults`, `BKeys`>

## See

[https://vuejs.org/guide/typescript/composition-api.html#typing-component-props](https://vuejs.org/guide/typescript/composition-api.html#typing-component-props)

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:362



---
url: /guide/api/vue-lynx/Function.withDirectives.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / withDirectives

# Function: withDirectives()

```ts
function withDirectives<T>(vnode, directives): T
```

Adds directives to a VNode.

## Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`> |

## Parameters

| Parameter | Type |
| ------ | ------ |
| `vnode` | `T` |
| `directives` | `DirectiveArguments` |

## Returns

`T`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:428



---
url: /guide/api/vue-lynx/Function.withMemo.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / withMemo

# Function: withMemo()

```ts
function withMemo(
   memo, 
   render, 
   cache, 
index): VNode<any, any>
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `memo` | `any`\[] |
| `render` | () => [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`any`, `any`, `object`> |
| `cache` | `any`\[] |
| `index` | `number` |

## Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`any`, `any`>

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1711



---
url: /guide/api/vue-lynx/Function.withModifiers.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / withModifiers

# Function: withModifiers()

```ts
function withModifiers(fn, modifiers): (...args) => unknown
```

Wraps an event handler with Lynx event modifiers.

Supported modifiers:

* `.once`    — handler is invoked at most once; subsequent events are ignored
* `.stop`    — registers the event as `catchEvent` (native Lynx stop-propagation)
  and also calls `event.stopPropagation()` for DOM environments
* `.prevent` — accepted for code portability; no-op on Lynx (no browser default actions exist)
* `.self`    — skips the handler unless the event target is the listener element

The wrapped function is cached on `fn._withMods` keyed by the modifier
string so that stable function references survive re-renders.

`.stop` sets `_lynxCatch = true` on the wrapper so that `patchProp` can
register the event as `catchEvent` — the native Lynx mechanism for stopping
event bubbling. Calling `stopPropagation()` at the JS level alone is not
sufficient because native Lynx bubbling is decided before JS handlers run.

## Parameters

| Parameter | Type |
| ------ | ------ |
| `fn` | (...`args`) => `unknown` |
| `modifiers` | `string`\[] |

## Returns

`Function`

### Parameters

| Parameter | Type |
| ------ | ------ |
| ...`args` | `unknown`\[] |

### Returns

`unknown`

## Defined in

packages/vue-lynx/runtime/src/index.ts:1331



---
url: /guide/api/vue-lynx/Interface.App.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / App

# Interface: App\<HostElement>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `HostElement` | `any` |

## Properties

| Property | Type | Defined in |
| ------ | ------ | ------ |
| `version` | `string` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1021 |
| `config` | `AppConfig` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1022 |
| `_uid` | `number` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1053 |
| `_component` | `ConcreteComponent`\<`object`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1054 |
| `_props` | `null` | `Data` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1055 |
| `_container` | `null` | `HostElement` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1056 |
| `_context` | `AppContext` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1057 |
| `_instance` | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1058 |

## Methods

### use()

#### use(plugin, options)

```ts
use<Options>(plugin, ...options): this
```

##### Type Parameters

| Type Parameter |
| ------ |
| `Options` *extends* `unknown`\[] |

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `plugin` | [`Plugin`](/guide/api/vue-lynx/TypeAlias.Plugin.md)\<`Options`, `Options` *extends* `unknown`\[] ? `Options`\<`Options`> : \[`Options`]> |
| ...`options` | `NoInfer`\<`Options`> |

##### Returns

`this`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1023

#### use(plugin, options)

```ts
use<Options>(plugin, options): this
```

##### Type Parameters

| Type Parameter |
| ------ |
| `Options` |

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `plugin` | [`Plugin`](/guide/api/vue-lynx/TypeAlias.Plugin.md)\<`Options`, `Options` *extends* `unknown`\[] ? `Options`\<`Options`> : \[`Options`]> |
| `options` | `NoInfer`\<`Options`> |

##### Returns

`this`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1024

***

### mixin()

```ts
mixin(mixin): this
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `mixin` | `ComponentOptions`\<`object`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `string`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`> |

#### Returns

`this`

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1025

***

### component()

#### component(name)

```ts
component(name): undefined | Component<any, any, any, ComputedOptions, MethodOptions, object, any>
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |

##### Returns

`undefined` | [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`>

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1026

#### component(name, component)

```ts
component<T>(name, component): this
```

##### Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)\<`any`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> | [`DefineComponent`](/guide/api/vue-lynx/TypeAlias.DefineComponent.md)\<`object`, `object`, `object`, `ComputedOptions`, `MethodOptions`, `ComponentOptionsMixin`, `ComponentOptionsMixin`, `object`, `string`, `PublicProps`, `Readonly`\<[`ExtractPropTypes`](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md)\<`object`>>, `object`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`, `true`, `object`, `any`> |

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |
| `component` | `T` |

##### Returns

`this`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1027

***

### directive()

#### directive(name)

```ts
directive<HostElement, Value, Modifiers, Arg>(name): undefined | Directive<HostElement, Value, Modifiers, Arg>
```

##### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `HostElement` | `any` |
| `Value` | `any` |
| `Modifiers` *extends* `string` | `string` |
| `Arg` | `any` |

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |

##### Returns

`undefined` | [`Directive`](/guide/api/vue-lynx/TypeAlias.Directive.md)\<`HostElement`, `Value`, `Modifiers`, `Arg`>

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1028

#### directive(name, directive)

```ts
directive<HostElement, Value, Modifiers, Arg>(name, directive): this
```

##### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `HostElement` | `any` |
| `Value` | `any` |
| `Modifiers` *extends* `string` | `string` |
| `Arg` | `any` |

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |
| `directive` | [`Directive`](/guide/api/vue-lynx/TypeAlias.Directive.md)\<`HostElement`, `Value`, `Modifiers`, `Arg`> |

##### Returns

`this`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1029

***

### mount()

```ts
mount(rootContainer): ComponentPublicInstance<object, object, object, object, object, object, object, object, false, ComponentOptionsBase<any, any, any, any, any, any, any, any, any, object, object, string, object, object, object, string, ComponentProvideOptions>, object, object, "", object, any>
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `rootContainer` | `string` | `HostElement` |

#### Returns

[`ComponentPublicInstance`](/guide/api/vue-lynx/TypeAlias.ComponentPublicInstance.md)\<`object`, `object`, `object`, `object`, `object`, `object`, `object`, `object`, `false`, `ComponentOptionsBase`\<`any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`>, `object`, `object`, `""`, `object`, `any`>

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1030

***

### unmount()

```ts
unmount(): void
```

#### Returns

`void`

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1043

***

### onUnmount()

```ts
onUnmount(cb): void
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `cb` | () => `void` |

#### Returns

`void`

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1044

***

### provide()

```ts
provide<T, K>(key, value): this
```

#### Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `K` | `string` | `number` | [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`T`> |

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `K` |
| `value` | `K` *extends* [`InjectionKey`](/guide/api/vue-lynx/TypeAlias.InjectionKey.md)\<`V`> ? `V` : `T` |

#### Returns

`this`

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1045

***

### runWithContext()

```ts
runWithContext<T>(fn): T
```

Runs a function with the app as active instance. This allows using of `inject()` within the function to get access
to variables provided via `app.provide()`.

#### Type Parameters

| Type Parameter |
| ------ |
| `T` |

#### Parameters

| Parameter | Type | Description |
| ------ | ------ | ------ |
| `fn` | () => `T` | function to run with the app as active instance |

#### Returns

`T`

#### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1052

***

### filter()?

#### filter(name)

```ts
optional filter(name): undefined | Function
```

v2 compat only

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |

##### Returns

`undefined` | `Function`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1062

#### filter(name, filter)

```ts
optional filter(name, filter): this
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `name` | `string` |
| `filter` | `Function` |

##### Returns

`this`

##### Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1063



---
url: /guide/api/vue-lynx/Interface.ComponentInternalInstance.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ComponentInternalInstance

# Interface: ComponentInternalInstance

We expose a subset of properties on the internal instance as they are
useful for advanced external libraries and tools.

## Properties

| Property | Type | Description | Defined in |
| ------ | ------ | ------ | ------ |
| `uid` | `number` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1434 |
| `type` | `ConcreteComponent`\<`object`, `any`, `any`, `ComputedOptions`, `MethodOptions`, `object`, `any`> | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1435 |
| `parent` | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1436 |
| `root` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1437 |
| `appContext` | `AppContext` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1438 |
| `vnode` | [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`> | Vnode representing this component in its parent's vdom tree | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1442 |
| `subTree` | [`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`> | Root vnode of this component's own vdom tree | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1446 |
| `effect` | `ReactiveEffect`\<`any`> | Render effect instance | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1450 |
| `update` | () => `void` | Force update render effect | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1454 |
| `job` | `SchedulerJob` | Render effect job to be passed to scheduler (checks if dirty) | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1458 |
| `proxy` | `null` | [`ComponentPublicInstance`](/guide/api/vue-lynx/TypeAlias.ComponentPublicInstance.md)\<`object`, `object`, `object`, `object`, `object`, `object`, `object`, `object`, `false`, `ComponentOptionsBase`\<`any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `object`, `object`, `string`, `object`, `object`, `object`, `string`, `ComponentProvideOptions`>, `object`, `object`, `""`, `object`, `any`> | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1459 |
| `exposed` | `null` | `Record`\<`string`, `any`> | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1460 |
| `exposeProxy` | `null` | `Record`\<`string`, `any`> | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1461 |
| `data` | `Data` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1462 |
| `props` | `Data` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1463 |
| `attrs` | `Data` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1464 |
| `slots` | `InternalSlots` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1465 |
| `refs` | `Data` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1466 |
| `emit` | (`event`: `string`, ...`args`: `any`\[]) => `void` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1467 |
| `isMounted` | `boolean` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1468 |
| `isUnmounted` | `boolean` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1469 |
| `isDeactivated` | `boolean` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1470 |



---
url: /guide/api/vue-lynx/Interface.ComputedRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ComputedRef

# Interface: ComputedRef\<T>

## Extends

* `BaseComputedRef`\<`T`>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |

## Properties

| Property | Modifier | Type | Description | Overrides | Inherited from | Defined in |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| `[ComputedRefSymbol]` | `public` | `true` | - | - | `BaseComputedRef.[ComputedRefSymbol]` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:346 |
| ~~`effect`~~ | `public` | `ComputedRefImpl`\<`any`> | **Deprecated** computed no longer uses effect | - | `BaseComputedRef.effect` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:350 |
| `value` | `readonly` | `T` | - | `BaseComputedRef.value` | - | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:353 |
| `[RefSymbol]` | `public` | `true` | Type differentiator only. We need this to be in public d.ts but don't want it to show up in IDE autocomplete, so we use a private Symbol instead. | - | `BaseComputedRef.[RefSymbol]` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:424 |



---
url: /guide/api/vue-lynx/Interface.FunctionalComponent.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / FunctionalComponent

# Interface: FunctionalComponent()\<P, E, S, EE>

## Extends

* `ComponentInternalOptions`

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `P` | `object` |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `Record`\<`string`, `any`\[]> | `object` |
| `S` *extends* `Record`\<`string`, `any`> | `any` |
| `EE` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `ShortEmitsToObject`\<`E`> |

```ts
interface FunctionalComponent(props, ctx): any
```

## Parameters

| Parameter | Type |
| ------ | ------ |
| `props` | `P` & `EmitsToProps`\<`EE`> |
| `ctx` | `Omit`\<[`SetupContext`](/guide/api/vue-lynx/TypeAlias.SetupContext.md)\<`EE`, `IfAny`\<`S`, `object`, [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`S`>>>, `"expose"`> |

## Returns

`any`

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1398

## Properties

| Property | Type | Description | Inherited from | Defined in |
| ------ | ------ | ------ | ------ | ------ |
| `__isBuiltIn?` | `boolean` | Compat build only, for bailing out of certain compatibility behavior | `ComponentInternalOptions.__isBuiltIn` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1387 |
| `__file?` | `string` | This one should be exposed so that devtools can make use of it | `ComponentInternalOptions.__file` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1391 |
| `__name?` | `string` | name inferred from filename | `ComponentInternalOptions.__name` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1395 |
| `props?` | `ComponentPropsOptions`\<`P`> | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1399 |
| `emits?` | `EE` | keyof `EE`\[] | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1400 |
| `slots?` | `IfAny`\<`S`, `Readonly`\<`InternalSlots`>, [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md)\<`S`>> | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1401 |
| `inheritAttrs?` | `boolean` | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1402 |
| `displayName?` | `string` | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1403 |
| `compatConfig?` | `CompatConfig` | - | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1404 |



---
url: /guide/api/vue-lynx/Interface.Ref.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Ref

# Interface: Ref\<T, S>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |
| `S` | `T` |

## Properties

| Property | Type | Description | Defined in |
| ------ | ------ | ------ | ------ |
| `[RefSymbol]` | `true` | Type differentiator only. We need this to be in public d.ts but don't want it to show up in IDE autocomplete, so we use a private Symbol instead. | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:424 |

## Accessors

### value

#### Get Signature

```ts
get value(): T
```

##### Returns

`T`

#### Set Signature

```ts
set value(_): void
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `_` | `S` |

##### Returns

`void`

#### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:417



---
url: /guide/api/vue-lynx/Interface.VNode.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / VNode

# Interface: VNode\<HostNode, HostElement, ExtraProps>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `HostNode` | `RendererNode` |
| `HostElement` | `RendererElement` |
| `ExtraProps` | `object` |

## Properties

| Property | Type | Description | Defined in |
| ------ | ------ | ------ | ------ |
| `type` | `VNodeTypes` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1210 |
| `props` | `null` | `VNodeProps` & `ExtraProps` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1211 |
| `key` | `null` | `PropertyKey` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1212 |
| `ref` | `null` | `VNodeNormalizedRef` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1213 |
| `scopeId` | `null` | `string` | SFC only. This is assigned on vnode creation using currentScopeId which is set alongside currentRenderingInstance. | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1218 |
| `children` | `VNodeNormalizedChildren` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1219 |
| `component` | `null` | [`ComponentInternalInstance`](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1220 |
| `dirs` | `null` | `DirectiveBinding`\<`any`, `string`, `any`>\[] | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1221 |
| `transition` | `null` | `TransitionHooks`\<`HostElement`> | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1222 |
| `el` | `null` | `HostNode` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1223 |
| `placeholder` | `null` | `HostNode` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1224 |
| `anchor` | `null` | `HostNode` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1225 |
| `target` | `null` | `HostElement` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1226 |
| `targetStart` | `null` | `HostNode` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1227 |
| `targetAnchor` | `null` | `HostNode` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1228 |
| `suspense` | `null` | `SuspenseBoundary` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1229 |
| `shapeFlag` | `number` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1230 |
| `patchFlag` | `number` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1231 |
| `appContext` | `null` | `AppContext` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1232 |



---
url: /guide/api/vue-lynx/Interface.VueLynxApp.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / VueLynxApp

# Interface: VueLynxApp

A Vue Lynx application instance returned by [createApp](/guide/api/vue-lynx/Function.createApp.md).

## Indexable

\[`key`: `string`]: `unknown`

## Properties

| Property | Type | Description | Defined in |
| ------ | ------ | ------ | ------ |
| `config` | `AppConfig` | The application-level configuration object (same as Vue's `app.config`). | packages/vue-lynx/runtime/src/index.ts:159 |

## Methods

### mount()

```ts
mount(): void
```

Mount the root component onto the Lynx page root.

Unlike Vue on the web, there is no container selector — Lynx has a single
page root and all content is always mounted there.

#### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/index.ts:151

***

### unmount()

```ts
unmount(): void
```

Unmount the application and clean up all components.

#### Returns

`void`

#### Defined in

packages/vue-lynx/runtime/src/index.ts:153

***

### use()

```ts
use(plugin, ...options): VueLynxApp
```

Install a Vue plugin.

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `plugin` | `unknown` |
| ...`options` | `unknown`\[] |

#### Returns

[`VueLynxApp`](/guide/api/vue-lynx/Interface.VueLynxApp.md)

#### Defined in

packages/vue-lynx/runtime/src/index.ts:155

***

### provide()

```ts
provide(key, value): VueLynxApp
```

Provide a value that can be injected by descendant components.

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `key` | `unknown` |
| `value` | `unknown` |

#### Returns

[`VueLynxApp`](/guide/api/vue-lynx/Interface.VueLynxApp.md)

#### Defined in

packages/vue-lynx/runtime/src/index.ts:157



---
url: /guide/api/vue-lynx/Interface.WatchHandle.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / WatchHandle

# Interface: WatchHandle()

## Extends

* [`WatchStopHandle`](/guide/api/vue-lynx/TypeAlias.WatchStopHandle.md)

```ts
interface WatchHandle(): void
```

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:728

## Properties

| Property | Type | Defined in |
| ------ | ------ | ------ |
| `pause` | () => `void` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:730 |
| `resume` | () => `void` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:731 |
| `stop` | () => `void` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:732 |



---
url: /guide/api/vue-lynx/Interface.WatchOptions.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / WatchOptions

# Interface: WatchOptions\<Immediate>

## Extends

* `WatchEffectOptions`

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `Immediate` | `boolean` |

## Properties

| Property | Type | Inherited from | Defined in |
| ------ | ------ | ------ | ------ |
| `onTrack?` | (`event`: `DebuggerEvent`) => `void` | `WatchEffectOptions.onTrack` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:266 |
| `onTrigger?` | (`event`: `DebuggerEvent`) => `void` | `WatchEffectOptions.onTrigger` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:267 |
| `flush?` | `"pre"` | `"post"` | `"sync"` | `WatchEffectOptions.flush` | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1487 |
| `immediate?` | `Immediate` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1490 |
| `deep?` | `number` | `boolean` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1491 |
| `once?` | `boolean` | - | node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1492 |



---
url: /guide/api/vue-lynx/Interface.WritableComputedRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / WritableComputedRef

# Interface: WritableComputedRef\<T, S>

## Extends

* `BaseComputedRef`\<`T`, `S`>

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | - |
| `S` | `T` |

## Properties

| Property | Type | Description | Inherited from | Defined in |
| ------ | ------ | ------ | ------ | ------ |
| `[ComputedRefSymbol]` | `true` | - | `BaseComputedRef.[ComputedRefSymbol]` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:346 |
| ~~`effect`~~ | `ComputedRefImpl`\<`any`> | **Deprecated** computed no longer uses effect | `BaseComputedRef.effect` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:350 |
| `[WritableComputedRefSymbol]` | `true` | - | - | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:356 |
| `[RefSymbol]` | `true` | Type differentiator only. We need this to be in public d.ts but don't want it to show up in IDE autocomplete, so we use a private Symbol instead. | `BaseComputedRef.[RefSymbol]` | node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:424 |

## Accessors

### value

#### Get Signature

```ts
get value(): T
```

##### Returns

`T`

#### Set Signature

```ts
set value(_): void
```

##### Parameters

| Parameter | Type |
| ------ | ------ |
| `_` | `S` |

##### Returns

`void`

#### Inherited from

`BaseComputedRef.value`

#### Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:417



---
url: /guide/api/vue-lynx/TypeAlias.Component.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Component

# Type Alias: Component\<PropsOrInstance, RawBindings, D, C, M, E, S>

```ts
type Component<PropsOrInstance, RawBindings, D, C, M, E, S>: ConcreteComponent<PropsOrInstance, RawBindings, D, C, M, E, S> | ComponentPublicInstanceConstructor<PropsOrInstance>;
```

A type used in public APIs where a component type is expected.
The constructor type is an artificial type returned by defineComponent().

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `PropsOrInstance` | `any` |
| `RawBindings` | `any` |
| `D` | `any` |
| `C` *extends* `ComputedOptions` | `ComputedOptions` |
| `M` *extends* `MethodOptions` | `MethodOptions` |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `Record`\<`string`, `any`\[]> | `object` |
| `S` *extends* `Record`\<`string`, `any`> | `any` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1421



---
url: /guide/api/vue-lynx/TypeAlias.ComponentPublicInstance.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ComponentPublicInstance

# Type Alias: ComponentPublicInstance\<P, B, D, C, M, E, PublicProps, Defaults, MakeDefaultsOptional, Options, I, S, Exposed, TypeRefs, TypeEl>

```ts
type ComponentPublicInstance<P, B, D, C, M, E, PublicProps, Defaults, MakeDefaultsOptional, Options, I, S, Exposed, TypeRefs, TypeEl>: object & ExposedKeys<IfAny<P, P, Readonly<Defaults> & Omit<P, keyof ShallowUnwrapRef<B> | keyof Defaults>> & ShallowUnwrapRef<B> & UnwrapNestedRefs<D> & ExtractComputedReturns<C> & M & ComponentCustomProperties & InjectToObject<I>, Exposed>;
```

## Type declaration

### $

```ts
$: ComponentInternalInstance;
```

### $data

```ts
$data: D;
```

### $props

```ts
$props: MakeDefaultsOptional extends true ? Partial<Defaults> & Omit<Prettify<P> & PublicProps, keyof Defaults> : Prettify<P> & PublicProps;
```

### $attrs

```ts
$attrs: Attrs;
```

### $refs

```ts
$refs: Data & TypeRefs;
```

### $slots

```ts
$slots: UnwrapSlotsType<S>;
```

### $root

```ts
$root: ComponentPublicInstance | null;
```

### $parent

```ts
$parent: ComponentPublicInstance | null;
```

### $host

```ts
$host: Element | null;
```

### $emit

```ts
$emit: EmitFn<E>;
```

### $el

```ts
$el: TypeEl;
```

### $options

```ts
$options: Options & MergedComponentOptionsOverride;
```

### $forceUpdate()

```ts
$forceUpdate: () => void;
```

#### Returns

`void`

### $nextTick

```ts
$nextTick: typeof nextTick;
```

### $watch()

#### Type Parameters

| Type Parameter |
| ------ |
| `T` *extends* `string` | (...`args`) => `any` |

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `source` | `T` |
| `cb` | `T` *extends* (...`args`) => `R` ? (...`args`) => `any` : (...`args`) => `any` |
| `options`? | [`WatchOptions`](/guide/api/vue-lynx/Interface.WatchOptions.md)\<`boolean`> |

#### Returns

[`WatchStopHandle`](/guide/api/vue-lynx/TypeAlias.WatchStopHandle.md)

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `P` | `object` |
| `B` | `object` |
| `D` | `object` |
| `C` *extends* `ComputedOptions` | `object` |
| `M` *extends* `MethodOptions` | `object` |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `PublicProps` | `object` |
| `Defaults` | `object` |
| `MakeDefaultsOptional` *extends* `boolean` | `false` |
| `Options` | `ComponentOptionsBase`\<`any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`, `any`> |
| `I` *extends* `ComponentInjectOptions` | `object` |
| `S` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md) | `object` |
| `Exposed` *extends* `string` | `""` |
| `TypeRefs` *extends* `Data` | `object` |
| `TypeEl` *extends* `Element` | `any` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:485



---
url: /guide/api/vue-lynx/TypeAlias.DeepReadonly.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / DeepReadonly

# Type Alias: DeepReadonly\<T>

```ts
type DeepReadonly<T>: T extends Builtin ? T : T extends Map<infer K, infer V> ? ReadonlyMap<DeepReadonly<K>, DeepReadonly<V>> : T extends ReadonlyMap<infer K, infer V> ? ReadonlyMap<DeepReadonly<K>, DeepReadonly<V>> : T extends WeakMap<infer K, infer V> ? WeakMap<DeepReadonly<K>, DeepReadonly<V>> : T extends Set<infer U> ? ReadonlySet<DeepReadonly<U>> : T extends ReadonlySet<infer U> ? ReadonlySet<DeepReadonly<U>> : T extends WeakSet<infer U> ? WeakSet<DeepReadonly<U>> : T extends Promise<infer U> ? Promise<DeepReadonly<U>> : T extends Ref<infer U, unknown> ? Readonly<Ref<...>> : T extends object ? { readonly [K in (...)]: (...) } : Readonly<...>;
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:82



---
url: /guide/api/vue-lynx/TypeAlias.DefineComponent.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / DefineComponent

# Type Alias: DefineComponent\<PropsOrPropOptions, RawBindings, D, C, M, Mixin, Extends, E, EE, PP, Props, Defaults, S, LC, Directives, Exposed, Provide, MakeDefaultsOptional, TypeRefs, TypeEl>

```ts
type DefineComponent<PropsOrPropOptions, RawBindings, D, C, M, Mixin, Extends, E, EE, PP, Props, Defaults, S, LC, Directives, Exposed, Provide, MakeDefaultsOptional, TypeRefs, TypeEl>: ComponentPublicInstanceConstructor<CreateComponentPublicInstanceWithMixins<Props, RawBindings, D, C, M, Mixin, Extends, E, PP, Defaults, MakeDefaultsOptional, object, S, LC & GlobalComponents, Directives & GlobalDirectives, Exposed, TypeRefs, TypeEl>> & ComponentOptionsBase<Props, RawBindings, D, C, M, Mixin, Extends, E, EE, Defaults, object, string, S, LC & GlobalComponents, Directives & GlobalDirectives, Exposed, Provide> & PP;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `PropsOrPropOptions` | `object` |
| `RawBindings` | `object` |
| `D` | `object` |
| `C` *extends* `ComputedOptions` | `ComputedOptions` |
| `M` *extends* `MethodOptions` | `MethodOptions` |
| `Mixin` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |
| `Extends` *extends* `ComponentOptionsMixin` | `ComponentOptionsMixin` |
| `E` *extends* [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | `object` |
| `EE` *extends* `string` | `string` |
| `PP` | `PublicProps` |
| `Props` | `ResolveProps`\<`PropsOrPropOptions`, `E`> |
| `Defaults` | `ExtractDefaultPropTypes`\<`PropsOrPropOptions`> |
| `S` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md) | `object` |
| `LC` *extends* `Record`\<`string`, [`Component`](/guide/api/vue-lynx/TypeAlias.Component.md)> | `object` |
| `Directives` *extends* `Record`\<`string`, [`Directive`](/guide/api/vue-lynx/TypeAlias.Directive.md)> | `object` |
| `Exposed` *extends* `string` | `string` |
| `Provide` *extends* `ComponentProvideOptions` | `ComponentProvideOptions` |
| `MakeDefaultsOptional` *extends* `boolean` | `true` |
| `TypeRefs` *extends* `Record`\<`string`, `unknown`> | `object` |
| `TypeEl` *extends* `Element` | `any` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:984



---
url: /guide/api/vue-lynx/TypeAlias.Directive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Directive

# Type Alias: Directive\<HostElement, Value, Modifiers, Arg>

```ts
type Directive<HostElement, Value, Modifiers, Arg>: ObjectDirective<HostElement, Value, Modifiers, Arg> | FunctionDirective<HostElement, Value, Modifiers, Arg>;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `HostElement` | `any` |
| `Value` | `any` |
| `Modifiers` *extends* `string` | `string` |
| `Arg` | `any` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:422



---
url: /guide/api/vue-lynx/TypeAlias.EmitsOptions.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / EmitsOptions

# Type Alias: EmitsOptions

```ts
type EmitsOptions: ObjectEmitsOptions | string[];
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:367



---
url: /guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ExtractPropTypes

# Type Alias: ExtractPropTypes\<O>

```ts
type ExtractPropTypes<O>: { [K in keyof Pick<O, RequiredKeys<O>>]: O[K] extends Object ? Exclude<InferPropType<O[K]>, undefined> : InferPropType<O[K]> } & { [K in keyof Pick<O, OptionalKeys<O>>]?: InferPropType<O[K]> };
```

Extract prop types from a runtime props options object.
The extracted types are **internal** - i.e. the resolved props received by
the component.

* Boolean props are always present
* Props with default values are always present

To extract accepted props from the parent, use ExtractPublicPropTypes.

## Type Parameters

| Type Parameter |
| ------ |
| `O` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:132



---
url: /guide/api/vue-lynx/TypeAlias.InjectionKey.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / InjectionKey

# Type Alias: InjectionKey\<T>

```ts
type InjectionKey<T>: symbol & InjectionConstraint<T>;
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:970



---
url: /guide/api/vue-lynx/TypeAlias.MaybeRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / MaybeRef

# Type Alias: MaybeRef\<T>

```ts
type MaybeRef<T>: T | Ref<T> | ShallowRef<T> | WritableComputedRef<T>;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:491



---
url: /guide/api/vue-lynx/TypeAlias.MaybeRefOrGetter.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / MaybeRefOrGetter

# Type Alias: MaybeRefOrGetter\<T>

```ts
type MaybeRefOrGetter<T>: MaybeRef<T> | ComputedRef<T> | () => T;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:492



---
url: /guide/api/vue-lynx/TypeAlias.Plugin.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Plugin

# Type Alias: Plugin\<Options, P>

```ts
type Plugin<Options, P>: FunctionPlugin<P> | ObjectPlugin<P>;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `Options` | `any`\[] |
| `P` *extends* `unknown`\[] | `Options` *extends* `unknown`\[] ? `Options` : \[`Options`] |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1111



---
url: /guide/api/vue-lynx/TypeAlias.PropType.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / PropType

# Type Alias: PropType\<T>

```ts
type PropType<T>: PropConstructor<T> | (PropConstructor<T> | null)[];
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:77



---
url: /guide/api/vue-lynx/TypeAlias.Reactive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Reactive

# Type Alias: Reactive\<T>

```ts
type Reactive<T>: UnwrapNestedRefs<T> & T extends readonly any[] ? ReactiveMarker : object;
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:28



---
url: /guide/api/vue-lynx/TypeAlias.SetupContext.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / SetupContext

# Type Alias: SetupContext\<E, S>

```ts
type SetupContext<E, S>: E extends any ? object : never;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `E` | [`EmitsOptions`](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) |
| `S` *extends* [`SlotsType`](/guide/api/vue-lynx/TypeAlias.SlotsType.md) | `object` |

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1423



---
url: /guide/api/vue-lynx/TypeAlias.ShallowRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / ShallowRef

# Type Alias: ShallowRef\<T, S>

```ts
type ShallowRef<T, S>: Ref<T, S> & object;
```

## Type declaration

### \[ShallowRefMarker]?

```ts
optional [ShallowRefMarker]: true;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` | `any` |
| `S` | `T` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:443



---
url: /guide/api/vue-lynx/TypeAlias.SlotsType.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / SlotsType

# Type Alias: SlotsType\<T>

```ts
type SlotsType<T>: object;
```

## Type Parameters

| Type Parameter | Default type |
| ------ | ------ |
| `T` *extends* `Record`\<`string`, `any`> | `Record`\<`string`, `any`> |

## Type declaration

### \[SlotSymbol]?

```ts
optional [SlotSymbol]: T;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:14



---
url: /guide/api/vue-lynx/TypeAlias.UnwrapNestedRefs.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / UnwrapNestedRefs

# Type Alias: UnwrapNestedRefs\<T>

```ts
type UnwrapNestedRefs<T>: T extends Ref ? T : UnwrapRefSimple<T>;
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:23



---
url: /guide/api/vue-lynx/TypeAlias.UnwrapRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / UnwrapRef

# Type Alias: UnwrapRef\<T>

```ts
type UnwrapRef<T>: T extends ShallowRef<infer V, unknown> ? V : T extends Ref<infer V, unknown> ? UnwrapRefSimple<V> : UnwrapRefSimple<T>;
```

## Type Parameters

| Type Parameter |
| ------ |
| `T` |

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:626



---
url: /guide/api/vue-lynx/TypeAlias.VNodeChild.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / VNodeChild

# Type Alias: VNodeChild

```ts
type VNodeChild: VNodeChildAtom | VNodeArrayChildren;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1205



---
url: /guide/api/vue-lynx/TypeAlias.VNodeRef.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / VNodeRef

# Type Alias: VNodeRef

```ts
type VNodeRef: string | Ref | (ref, refs) => void;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1169



---
url: /guide/api/vue-lynx/TypeAlias.WatchStopHandle.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / WatchStopHandle

# Type Alias: WatchStopHandle()

```ts
type WatchStopHandle: () => void;
```

## Returns

`void`

## Defined in

node\_modules/.pnpm/@vue+reactivity@3.5.30/node\_modules/@vue/reactivity/dist/reactivity.d.ts:728



---
url: /guide/api/vue-lynx/Variable.Comment.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Comment

# Variable: Comment

```ts
const Comment: unique symbol;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1166



---
url: /guide/api/vue-lynx/Variable.Fragment.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Fragment

# Variable: Fragment()

```ts
const Fragment: () => object;
```

## Returns

`object`

### $props

```ts
$props: VNodeProps;
```

## Type declaration

### \_\_isFragment

```ts
__isFragment: true;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1159



---
url: /guide/api/vue-lynx/Variable.KeepAlive.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / KeepAlive

# Variable: KeepAlive()

```ts
const KeepAlive: () => object;
```

## Returns

`object`

### $props

```ts
$props: VNodeProps & KeepAliveProps;
```

### $slots

```ts
$slots: object;
```

### $slots.default()

#### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`>\[]

## Type declaration

### \_\_isKeepAlive

```ts
__isKeepAlive: true;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:715



---
url: /guide/api/vue-lynx/Variable.Page.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Page

# Variable: Page

```ts
const Page: DefineComponent<object, () => undefined | VNode<RendererNode, RendererElement, object>[], object, object, object, ComponentOptionsMixin, ComponentOptionsMixin, object, string, PublicProps, ToResolvedProps<object, object>, object, object, object, object, string, ComponentProvideOptions, true, object, any>;
```

Transparent runtime representation of an explicit `<page>` wrapper.

Lynx creates the native page before Background JS starts. This component
applies the wrapper's attributes to that existing root and renders only its
children, so Vue never asks the Main Thread to create a second page.

Exactly one wrapper owns the root at a time. When the owner unmounts (or is
deactivated by `<KeepAlive>`), ownership is handed to the next waiting
wrapper — this keeps replacement flows working where the incoming page
mounts before the outgoing one unmounts (`<Transition>` without `out-in`,
`<Suspense>`, route swaps).

## Defined in

packages/vue-lynx/runtime/src/Page.ts:78



---
url: /guide/api/vue-lynx/Variable.Suspense.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Suspense

# Variable: Suspense()

```ts
const Suspense: () => object;
```

## Returns

`object`

### $props

```ts
$props: VNodeProps & SuspenseProps;
```

### $slots

```ts
$slots: object;
```

### $slots.default()

#### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`>\[]

### $slots.fallback()

#### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`>\[]

## Type declaration

### \_\_isSuspense

```ts
__isSuspense: true;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:542



---
url: /guide/api/vue-lynx/Variable.Teleport.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Teleport

# Variable: Teleport()

```ts
const Teleport: () => object;
```

## Returns

`object`

### $props

```ts
$props: VNodeProps & TeleportProps;
```

### $slots

```ts
$slots: object;
```

### $slots.default()

#### Returns

[`VNode`](/guide/api/vue-lynx/Interface.VNode.md)\<`RendererNode`, `RendererElement`, `object`>\[]

## Type declaration

### \_\_isTeleport

```ts
__isTeleport: true;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1135



---
url: /guide/api/vue-lynx/Variable.Text.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / Text

# Variable: Text

```ts
const Text: unique symbol;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1165



---
url: /guide/api/vue-lynx/Variable.TransitionGroup.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / TransitionGroup

# Variable: TransitionGroup

```ts
const TransitionGroup: DefineComponent<object, () => VNode<RendererNode, RendererElement, object>, object, object, object, ComponentOptionsMixin, ComponentOptionsMixin, object, string, PublicProps, ToResolvedProps<object, object>, object, object, object, object, string, ComponentProvideOptions, true, object, any>;
```

## Type declaration

### mode?

```ts
optional mode: "default" | "in-out" | "out-in";
```

### appear?

```ts
optional appear: boolean;
```

### persisted?

```ts
optional persisted: boolean;
```

### name?

```ts
optional name: string;
```

### type?

```ts
optional type: "transition" | "animation";
```

### duration?

```ts
optional duration: number | object;
```

### enterFromClass?

```ts
optional enterFromClass: string;
```

### enterActiveClass?

```ts
optional enterActiveClass: string;
```

### enterToClass?

```ts
optional enterToClass: string;
```

### leaveFromClass?

```ts
optional leaveFromClass: string;
```

### leaveActiveClass?

```ts
optional leaveActiveClass: string;
```

### leaveToClass?

```ts
optional leaveToClass: string;
```

### appearFromClass?

```ts
optional appearFromClass: string;
```

### appearActiveClass?

```ts
optional appearActiveClass: string;
```

### appearToClass?

```ts
optional appearToClass: string;
```

### onBeforeEnter()?

```ts
optional onBeforeEnter: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onEnter()?

```ts
optional onEnter: (el, done) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |
| `done` | () => `void` |

#### Returns

`void`

### onAfterEnter()?

```ts
optional onAfterEnter: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onEnterCancelled()?

```ts
optional onEnterCancelled: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onBeforeLeave()?

```ts
optional onBeforeLeave: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onLeave()?

```ts
optional onLeave: (el, done) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |
| `done` | () => `void` |

#### Returns

`void`

### onAfterLeave()?

```ts
optional onAfterLeave: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onLeaveCancelled()?

```ts
optional onLeaveCancelled: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onBeforeAppear()?

```ts
optional onBeforeAppear: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onAppear()?

```ts
optional onAppear: (el, done) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |
| `done` | () => `void` |

#### Returns

`void`

### onAfterAppear()?

```ts
optional onAfterAppear: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### onAppearCancelled()?

```ts
optional onAppearCancelled: (el) => void;
```

#### Parameters

| Parameter | Type |
| ------ | ------ |
| `el` | [`ShadowElement`](/guide/api/vue-lynx/Class.ShadowElement.md) |

#### Returns

`void`

### tag?

```ts
optional tag: string;
```

### moveClass?

```ts
optional moveClass: string;
```

## Defined in

packages/vue-lynx/runtime/src/TransitionGroup.ts:50



---
url: /guide/api/vue-lynx/Variable.mergeModels.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / mergeModels

# Variable: mergeModels

```ts
mergeModels: any;
```



---
url: /guide/api/vue-lynx/Variable.nodeOps.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / nodeOps

# Variable: nodeOps

```ts
const nodeOps: RendererOptions<ShadowElement, ShadowElement>;
```

## Defined in

packages/vue-lynx/runtime/src/node-ops.ts:235



---
url: /guide/api/vue-lynx/Variable.vModelCheckbox.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / vModelCheckbox

# Variable: vModelCheckbox

```ts
const vModelCheckbox: ObjectDirective = vModelUnsupported;
```

## Defined in

packages/vue-lynx/runtime/src/index.ts:1260



---
url: /guide/api/vue-lynx/Variable.vModelRadio.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / vModelRadio

# Variable: vModelRadio

```ts
const vModelRadio: ObjectDirective = vModelUnsupported;
```

## Defined in

packages/vue-lynx/runtime/src/index.ts:1262



---
url: /guide/api/vue-lynx/Variable.vModelSelect.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / vModelSelect

# Variable: vModelSelect

```ts
const vModelSelect: ObjectDirective = vModelUnsupported;
```

## Defined in

packages/vue-lynx/runtime/src/index.ts:1261



---
url: /guide/api/vue-lynx/Variable.vModelText.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / vModelText

# Variable: vModelText

```ts
const vModelText: ObjectDirective<ShadowElement>;
```

## Defined in

packages/vue-lynx/runtime/src/index.ts:1197



---
url: /guide/api/vue-lynx/Variable.vShow.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / vShow

# Variable: vShow

```ts
const vShow: ObjectDirective<ShadowElement, unknown>;
```

Vue Lynx implementation of the `v-show` directive.

Toggles the element's visibility by setting `display: none` on the native
Lynx element's style. Unlike the DOM version, this operates on
[ShadowElement](/guide/api/vue-lynx/Class.ShadowElement.md) and sends style ops to the main thread.

## See

[Vue v-show](https://vuejs.org/api/built-in-directives.html#v-show)

## Defined in

packages/vue-lynx/runtime/src/index.ts:293



---
url: /guide/api/vue-lynx/Variable.version.md
---

[vue-lynx](/guide/api/vue-lynx/index.md) / version

# Variable: version

```ts
const version: string;
```

## Defined in

node\_modules/.pnpm/@vue+runtime-core@3.5.30/node\_modules/@vue/runtime-core/dist/runtime-core.d.ts:1796



---
url: /guide/api/vue-lynx/index.md
---

# vue-lynx

Welcome to the API reference for `vue-lynx`, the package that provides the Vue 3 framework for building Lynx apps. For an introduction, see the [Getting Started](/guide/introduction.md) guide.

## Vue APIs

Vue Lynx uses Vue 3's `@vue/runtime-core` directly — the reactivity system, component model, lifecycle hooks, and Composition API are all standard Vue. You can expect these APIs to behave consistently with the [official Vue 3 documentation](https://vuejs.org/api/) unless otherwise noted below.

This means `ref()`, `reactive()`, `computed()`, `watch()`, `onMounted()`, `defineComponent()`, and all other Vue Composition APIs work exactly as documented on [vuejs.org](https://vuejs.org/api/). The only difference is that you import them from `vue-lynx` instead of `vue`:

```ts
import { ref, computed, onMounted, defineComponent } from 'vue-lynx';
```

## Vue Lynx APIs

The following APIs are specific to Vue Lynx's dual-thread architecture (Background Thread renderer + Main Thread native elements):

| Name | Kind |
| ------ | ------ |
| [MainThreadRef](/guide/api/vue-lynx/Class.MainThreadRef.md) | Class |
| [createApp](/guide/api/vue-lynx/Function.createApp.md) | Function |
| [nextTick](/guide/api/vue-lynx/Function.nextTick.md) | Function |
| [runOnBackground](/guide/api/vue-lynx/Function.runOnBackground.md) | Function |
| [runOnMainThread](/guide/api/vue-lynx/Function.runOnMainThread.md) | Function |
| [transformToWorklet](/guide/api/vue-lynx/Function.transformToWorklet.md) | Function |
| [useMainThreadRef](/guide/api/vue-lynx/Function.useMainThreadRef.md) | Function |
| [VueLynxApp](/guide/api/vue-lynx/Interface.VueLynxApp.md) | Interface |
| [Page](/guide/api/vue-lynx/Variable.Page.md) | Variable |

## Built-in Components

| Component | Status | Notes |
| --------- | ------ | ----- |
| `<Transition>` | Supported | Fully supported: CSS transitions/animations, `appear`, `mode`, JS hooks, with or without `:duration` ([#286](https://github.com/Huxpro/vue-lynx/issues/286)). |
| `<TransitionGroup>` | Supported | Per-child enter/leave animations. Move (FLIP) animations not supported — `getBoundingClientRect()` is unavailable from the background thread. |
| `<Suspense>` | Supported | Re-exported from Vue. Works with `defineAsyncComponent()`. |
| `<KeepAlive>` | Supported | Caches inactive component instances. Supports `include`, `exclude`, and `max` props. |
| `<Teleport>` | Supported | Supports `to="#id"` string selectors only. Direct element refs and non-ID selectors are not yet supported. |

:::info
`<Transition>` is fully supported (with or without `:duration`). The only remaining gap is Move (FLIP) animations in `<TransitionGroup>` — `getBoundingClientRect()` is unavailable from the background thread.
:::

<Go example="transition" defaultFile="src/App.vue" defaultEntryFile="dist/transition.lynx.bundle" />

## Vue Re-exports

Standard Vue 3 APIs re-exported from `vue-lynx`. See [Vue.js API Reference](https://vuejs.org/api/) for full documentation.

| Name | Kind |
| ------ | ------ |
| [computed](/guide/api/vue-lynx/Function.computed.md) | Function |
| [createPageRoot](/guide/api/vue-lynx/Function.createPageRoot.md) | Function |
| [customRef](/guide/api/vue-lynx/Function.customRef.md) | Function |
| [defineAsyncComponent](/guide/api/vue-lynx/Function.defineAsyncComponent.md) | Function |
| [defineComponent](/guide/api/vue-lynx/Function.defineComponent.md) | Function |
| [defineEmits](/guide/api/vue-lynx/Function.defineEmits.md) | Function |
| [defineExpose](/guide/api/vue-lynx/Function.defineExpose.md) | Function |
| [defineModel](/guide/api/vue-lynx/Function.defineModel.md) | Function |
| [defineOptions](/guide/api/vue-lynx/Function.defineOptions.md) | Function |
| [defineProps](/guide/api/vue-lynx/Function.defineProps.md) | Function |
| [defineSlots](/guide/api/vue-lynx/Function.defineSlots.md) | Function |
| [effectScope](/guide/api/vue-lynx/Function.effectScope.md) | Function |
| [getCurrentInstance](/guide/api/vue-lynx/Function.getCurrentInstance.md) | Function |
| [getCurrentScope](/guide/api/vue-lynx/Function.getCurrentScope.md) | Function |
| [guardReactiveProps](/guide/api/vue-lynx/Function.guardReactiveProps.md) | Function |
| [h](/guide/api/vue-lynx/Function.h.md) | Function |
| [hasInjectionContext](/guide/api/vue-lynx/Function.hasInjectionContext.md) | Function |
| [inject](/guide/api/vue-lynx/Function.inject.md) | Function |
| [isIfrMainThread](/guide/api/vue-lynx/Function.isIfrMainThread.md) | Function |
| [isMemoSame](/guide/api/vue-lynx/Function.isMemoSame.md) | Function |
| [isProxy](/guide/api/vue-lynx/Function.isProxy.md) | Function |
| [isReactive](/guide/api/vue-lynx/Function.isReactive.md) | Function |
| [isReadonly](/guide/api/vue-lynx/Function.isReadonly.md) | Function |
| [isRef](/guide/api/vue-lynx/Function.isRef.md) | Function |
| [isShallow](/guide/api/vue-lynx/Function.isShallow.md) | Function |
| [markRaw](/guide/api/vue-lynx/Function.markRaw.md) | Function |
| [mergeProps](/guide/api/vue-lynx/Function.mergeProps.md) | Function |
| [onActivated](/guide/api/vue-lynx/Function.onActivated.md) | Function |
| [onBeforeMount](/guide/api/vue-lynx/Function.onBeforeMount.md) | Function |
| [onBeforeUnmount](/guide/api/vue-lynx/Function.onBeforeUnmount.md) | Function |
| [onBeforeUpdate](/guide/api/vue-lynx/Function.onBeforeUpdate.md) | Function |
| [onDeactivated](/guide/api/vue-lynx/Function.onDeactivated.md) | Function |
| [onErrorCaptured](/guide/api/vue-lynx/Function.onErrorCaptured.md) | Function |
| [onMounted](/guide/api/vue-lynx/Function.onMounted.md) | Function |
| [onRenderTracked](/guide/api/vue-lynx/Function.onRenderTracked.md) | Function |
| [onRenderTriggered](/guide/api/vue-lynx/Function.onRenderTriggered.md) | Function |
| [onScopeDispose](/guide/api/vue-lynx/Function.onScopeDispose.md) | Function |
| [onUnmounted](/guide/api/vue-lynx/Function.onUnmounted.md) | Function |
| [onUpdated](/guide/api/vue-lynx/Function.onUpdated.md) | Function |
| [onWatcherCleanup](/guide/api/vue-lynx/Function.onWatcherCleanup.md) | Function |
| [provide](/guide/api/vue-lynx/Function.provide.md) | Function |
| [reactive](/guide/api/vue-lynx/Function.reactive.md) | Function |
| [readonly](/guide/api/vue-lynx/Function.readonly.md) | Function |
| [ref](/guide/api/vue-lynx/Function.ref.md) | Function |
| [shallowReactive](/guide/api/vue-lynx/Function.shallowReactive.md) | Function |
| [shallowReadonly](/guide/api/vue-lynx/Function.shallowReadonly.md) | Function |
| [shallowRef](/guide/api/vue-lynx/Function.shallowRef.md) | Function |
| [toRaw](/guide/api/vue-lynx/Function.toRaw.md) | Function |
| [toRef](/guide/api/vue-lynx/Function.toRef.md) | Function |
| [toRefs](/guide/api/vue-lynx/Function.toRefs.md) | Function |
| [toValue](/guide/api/vue-lynx/Function.toValue.md) | Function |
| [Transition](/guide/api/vue-lynx/Function.Transition.md) | Function |
| [triggerRef](/guide/api/vue-lynx/Function.triggerRef.md) | Function |
| [unref](/guide/api/vue-lynx/Function.unref.md) | Function |
| [useAttrs](/guide/api/vue-lynx/Function.useAttrs.md) | Function |
| [useGlobalEvent](/guide/api/vue-lynx/Function.useGlobalEvent.md) | Function |
| [useId](/guide/api/vue-lynx/Function.useId.md) | Function |
| [useModel](/guide/api/vue-lynx/Function.useModel.md) | Function |
| [useSlots](/guide/api/vue-lynx/Function.useSlots.md) | Function |
| [useTemplateRef](/guide/api/vue-lynx/Function.useTemplateRef.md) | Function |
| [watch](/guide/api/vue-lynx/Function.watch.md) | Function |
| [watchEffect](/guide/api/vue-lynx/Function.watchEffect.md) | Function |
| [watchPostEffect](/guide/api/vue-lynx/Function.watchPostEffect.md) | Function |
| [watchSyncEffect](/guide/api/vue-lynx/Function.watchSyncEffect.md) | Function |
| [withDefaults](/guide/api/vue-lynx/Function.withDefaults.md) | Function |
| [withModifiers](/guide/api/vue-lynx/Function.withModifiers.md) | Function |
| [App](/guide/api/vue-lynx/Interface.App.md) | Interface |
| [ComponentInternalInstance](/guide/api/vue-lynx/Interface.ComponentInternalInstance.md) | Interface |
| [ComputedRef](/guide/api/vue-lynx/Interface.ComputedRef.md) | Interface |
| [FunctionalComponent](/guide/api/vue-lynx/Interface.FunctionalComponent.md) | Interface |
| [Ref](/guide/api/vue-lynx/Interface.Ref.md) | Interface |
| [VNode](/guide/api/vue-lynx/Interface.VNode.md) | Interface |
| [WatchHandle](/guide/api/vue-lynx/Interface.WatchHandle.md) | Interface |
| [WatchOptions](/guide/api/vue-lynx/Interface.WatchOptions.md) | Interface |
| [WritableComputedRef](/guide/api/vue-lynx/Interface.WritableComputedRef.md) | Interface |
| [Component](/guide/api/vue-lynx/TypeAlias.Component.md) | TypeAlias |
| [ComponentPublicInstance](/guide/api/vue-lynx/TypeAlias.ComponentPublicInstance.md) | TypeAlias |
| [DeepReadonly](/guide/api/vue-lynx/TypeAlias.DeepReadonly.md) | TypeAlias |
| [DefineComponent](/guide/api/vue-lynx/TypeAlias.DefineComponent.md) | TypeAlias |
| [Directive](/guide/api/vue-lynx/TypeAlias.Directive.md) | TypeAlias |
| [EmitsOptions](/guide/api/vue-lynx/TypeAlias.EmitsOptions.md) | TypeAlias |
| [ExtractPropTypes](/guide/api/vue-lynx/TypeAlias.ExtractPropTypes.md) | TypeAlias |
| [InjectionKey](/guide/api/vue-lynx/TypeAlias.InjectionKey.md) | TypeAlias |
| [MaybeRef](/guide/api/vue-lynx/TypeAlias.MaybeRef.md) | TypeAlias |
| [MaybeRefOrGetter](/guide/api/vue-lynx/TypeAlias.MaybeRefOrGetter.md) | TypeAlias |
| [Plugin](/guide/api/vue-lynx/TypeAlias.Plugin.md) | TypeAlias |
| [PropType](/guide/api/vue-lynx/TypeAlias.PropType.md) | TypeAlias |
| [Reactive](/guide/api/vue-lynx/TypeAlias.Reactive.md) | TypeAlias |
| [SetupContext](/guide/api/vue-lynx/TypeAlias.SetupContext.md) | TypeAlias |
| [ShallowRef](/guide/api/vue-lynx/TypeAlias.ShallowRef.md) | TypeAlias |
| [SlotsType](/guide/api/vue-lynx/TypeAlias.SlotsType.md) | TypeAlias |
| [UnwrapNestedRefs](/guide/api/vue-lynx/TypeAlias.UnwrapNestedRefs.md) | TypeAlias |
| [UnwrapRef](/guide/api/vue-lynx/TypeAlias.UnwrapRef.md) | TypeAlias |
| [VNodeChild](/guide/api/vue-lynx/TypeAlias.VNodeChild.md) | TypeAlias |
| [VNodeRef](/guide/api/vue-lynx/TypeAlias.VNodeRef.md) | TypeAlias |
| [WatchStopHandle](/guide/api/vue-lynx/TypeAlias.WatchStopHandle.md) | TypeAlias |
| [Fragment](/guide/api/vue-lynx/Variable.Fragment.md) | Variable |
| [KeepAlive](/guide/api/vue-lynx/Variable.KeepAlive.md) | Variable |
| [mergeModels](/guide/api/vue-lynx/Variable.mergeModels.md) | Variable |
| [Suspense](/guide/api/vue-lynx/Variable.Suspense.md) | Variable |
| [Teleport](/guide/api/vue-lynx/Variable.Teleport.md) | Variable |
| [TransitionGroup](/guide/api/vue-lynx/Variable.TransitionGroup.md) | Variable |
| [version](/guide/api/vue-lynx/Variable.version.md) | Variable |
| [vModelCheckbox](/guide/api/vue-lynx/Variable.vModelCheckbox.md) | Variable |
| [vModelRadio](/guide/api/vue-lynx/Variable.vModelRadio.md) | Variable |
| [vModelSelect](/guide/api/vue-lynx/Variable.vModelSelect.md) | Variable |
| [vModelText](/guide/api/vue-lynx/Variable.vModelText.md) | Variable |



---
url: /guide/data-fetching.md
---

import { PackageManagerTabs } from '@theme';

# Vue Query

Lynx provides the [Fetch API](https://lynxjs.org/next/api/lynx-api/global/fetch) for making network requests. While you can use `fetch()` directly, we recommend [TanStack Query (Vue Query)](https://tanstack.com/query/v5/docs/framework/vue/overview) for managing server state — it handles caching, background refetching, stale data, and mutations out of the box.

See also: [Lynx — Networking](https://lynxjs.org/next/react/data-fetching.html)

<Go example="networking" defaultFile="src/App.vue" defaultEntryName="main" />

## Using Vue Query

### Installation

<PackageManagerTabs command="install @tanstack/vue-query" />

### Setup

Register the Vue Query plugin with your vue-lynx app:

```ts title="src/index.ts"
import { createApp } from 'vue-lynx';
import { VueQueryPlugin } from '@tanstack/vue-query';
import App from './App.vue';

const app = createApp(App);
app.use(VueQueryPlugin);
app.mount();
```

### Fetching Data with `useQuery`

Use [`useQuery`](https://tanstack.com/query/v5/docs/framework/vue/reference/useQuery) to fetch and cache server data. It returns reactive refs for `data`, `isLoading`, `isError`, and `error`:

```vue title="src/App.vue"
<script setup lang="ts">
import { useQuery } from '@tanstack/vue-query'

interface User {
  id: number
  name: string
  email: string
  company: { name: string }
}

const { data: users, isLoading, isError } = useQuery({
  queryKey: ['users'],
  queryFn: async (): Promise<User[]> => {
    const res = await fetch('https://jsonplaceholder.typicode.com/users')
    if (!res.ok) throw new Error('Failed to fetch users')
    return res.json()
  },
})
</script>

<template>
  <view>
    <text v-if="isLoading">Loading...</text>
    <text v-else-if="isError">Something went wrong</text>
    <scroll-view v-else scroll-orientation="vertical">
      <view v-for="user in users" :key="user.id">
        <text>{{ user.name }}</text>
      </view>
    </scroll-view>
  </view>
</template>
```

### Reactive Query Keys

A key advantage of Vue Query over its React counterpart is that query keys can be **reactive**. When a `ref` or `computed` value in the key changes, the query automatically refetches — no manual dependency tracking needed.

The example app uses this for search filtering and dependent queries:

```vue title="src/App.vue"
<script setup lang="ts">
import { ref, computed } from 'vue'
import { useQuery } from '@tanstack/vue-query'

const selectedUserId = ref<number | null>(null)

// This query only runs when a user is selected.
// When `selectedUserId` changes, it refetches automatically.
const { data: posts, isLoading } = useQuery({
  queryKey: computed(() => ['users', selectedUserId.value, 'posts']),
  queryFn: async (): Promise<Post[]> => {
    const res = await fetch(
      `https://jsonplaceholder.typicode.com/users/${selectedUserId.value}/posts`,
    )
    if (!res.ok) throw new Error('Failed to fetch posts')
    return res.json()
  },
  enabled: computed(() => selectedUserId.value !== null),
})
</script>
```

Here `queryKey` and `enabled` are both `computed` refs. Vue Query watches them reactively — when the user taps a different user, `selectedUserId` changes, the key updates, and the posts for the new user are fetched automatically. No watchers or `onMounted` callbacks needed.

### Mutations with Optimistic Updates

Use [`useMutation`](https://tanstack.com/query/v5/docs/framework/vue/reference/useMutation) to modify server data. Optimistic updates let you immediately reflect changes in the UI, rolling back automatically if the request fails:

```vue title="src/App.vue"
<script setup lang="ts">
import { useMutation, useQueryClient } from '@tanstack/vue-query'

const queryClient = useQueryClient()

const deleteMutation = useMutation({
  mutationFn: async (postId: number) => {
    const res = await fetch(
      `https://jsonplaceholder.typicode.com/posts/${postId}`,
      { method: 'DELETE' },
    )
    if (!res.ok) throw new Error('Failed to delete post')
    return postId
  },
  onMutate: async (postId) => {
    const key = ['users', selectedUserId.value, 'posts']
    await queryClient.cancelQueries({ queryKey: key })

    // Snapshot for rollback
    const previous = queryClient.getQueryData<Post[]>(key)

    // Optimistically remove the post
    queryClient.setQueryData(key, (old: Post[] | undefined) =>
      old ? old.filter((p) => p.id !== postId) : [],
    )

    return { previous, key }
  },
  onError: (_err, _postId, context) => {
    // Rollback on failure
    if (context?.previous) {
      queryClient.setQueryData(context.key, context.previous)
    }
  },
})
</script>

<template>
  <view v-for="post in posts" :key="post.id">
    <text>{{ post.title }}</text>
    <text @tap="deleteMutation.mutate(post.id)">✕</text>
  </view>
</template>
```

## Using `fetch()` Directly

For simple one-off requests, you can use the Fetch API directly with Vue's reactivity:

```vue title="src/App.vue"
<script setup lang="ts">
import { ref, onMounted } from 'vue'

const users = ref([])
const loading = ref(true)

onMounted(async () => {
  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/users')
    users.value = await res.json()
  } finally {
    loading.value = false
  }
})
</script>
```

For anything beyond simple reads — caching, background refresh, pagination, mutations — use TanStack Query instead.

See [TanStack Query — Vue Overview](https://tanstack.com/query/v5/docs/framework/vue/overview) for additional resources.



---
url: /guide/element-templates.md
---

# Element Templates

Element Templates are now documented together with Instant First-Frame
Rendering. See [IFR: Element Templates](/guide/ifr.md#element-templates) for the
compiler lowering model, eligibility rules, semantics, configuration, and
benchmarks.



---
url: /guide/elk.md
---

import { Badge } from '@theme';

# Elk — a Mastodon Client

To prove Vue Lynx can carry a real product-grade app, we ported
[Elk](https://github.com/elk-zone/elk) — the beloved Mastodon web client
by Anthony Fu and team — into a **native Mastodon client**. It browses any
public Mastodon instance as a guest (default `mas.to`): timelines, threads,
profiles, search, trends, dark mode and more.

Try it below. The **Web** tab runs the real app on Lynx for Web against a
live instance; the **QR Code** tab runs the same `main.lynx.bundle`
natively — scan it with Lynx Go / Lynx Explorer (see
[Quick Start](/guide/quick-start.md) to install one).

<Go example="elk" defaultFile="src/App.vue" schema="{{{url}}}?fullscreen=true&bar_color=fafafa&bg_color=fafafa" />

### Native viewpager variant <Badge text="newer Lynx engine" type="warning" />

The `elk-viewpager` fork backs the Explore and Notifications tabs with the
native [`<viewpager>`](https://lynxjs.org/guide/ui/elements-components.html#xelement)
element instead of conditionally rendered panes. In
[`TabPager.vue`](https://github.com/huxpro/vue-lynx/blob/main/examples/elk-viewpager/src/components/TabPager.vue)
each pane is a `<viewpager-item>`: panes swipe horizontally with a native
snap animation, keep content and scroll position across swipes, and the tab
bar syncs both ways — a swipe fires the pager's `change` event (→ active
tab), a tab tap calls its `selectTab` method (→ animate to that page). It
feels much closer to a native client.

`<viewpager>` is a Lynx [XElement](https://lynxjs.org/guide/ui/elements-components.html#xelement),
registered under a different tag per platform, so `TabPager.vue` picks the
tag at runtime from `SystemInfo.platform` (highlighted below):
`<x-viewpager-ng>` on Lynx for Web, the extracted `<viewpager>` /
`<viewpager-item>` on native OSS engines.

<Go
  example="elk-viewpager"
  defaultFile="src/components/TabPager.vue"
  schema="{{{url}}}?fullscreen=true&bar_color=fafafa&bg_color=fafafa"
  highlight={{
  'src/components/TabPager.vue': '{12-18,40-56,72-87}',
}}
/>

:::warning Engine version dependency
The extracted `<viewpager>` landed in the OSS engine in lynx-family/lynx
`c1d8d7920` (2026-04) — **newer than any released LynxExplorer**. 3.8.1 and
earlier register neither `<viewpager>` nor `<x-viewpager-ng>`, so the tab
area renders blank (with a `LynxCreateUIException`). Run this variant on a
host built from lynx `develop`; on released Explorers, use the default Elk
example above, whose conditional tabs need no pager element.
:::

#### How much code does the native upgrade take?

Almost none. Moving the whole app onto the native pager touches **three
files**: the new `TabPager.vue` plus the two pages with swipeable tabs
(`ExplorePage.vue`, `NotificationsPage.vue`). The other ~55 source files —
masto.js client, content renderer, router, virtualized `<list>` — are
byte-for-byte identical.

At the call site it's a straight swap. The hand-rolled tab bar and
`v-if` / `v-else-if` panes, where only the active pane exists:

```vue
<!-- elk: one pane rendered at a time -->
<view class="explore-tabs">
  <view class="explore-tab" @tap="tab = 'posts'">…</view>
  <view class="explore-tab" @tap="tab = 'tags'">…</view>
</view>
<list v-if="tab === 'posts'" @scrolltolower="loadNext">…</list>
<list v-else-if="tab === 'tags'" @scrolltolower="loadMoreTags">…</list>
```

…become a component with one named slot per pane:

```vue
<!-- elk-viewpager: all panes live, swipeable -->
<TabPager v-model="tab" :tabs="tabs">
  <template #posts>…</template>
  <template #tags>…</template>
</TabPager>
```

That `v-if` → slot rewrite is the whole UI-side story — tab bar, underline
animation, and pager ↔ tab sync all move into `TabPager`.

One change isn't mechanical, and it captures what "native paging" really
means. With `v-if`, only the visible pane exists, so a single shared
paginator was enough. With the pager, **every pane is mounted at once** and
swipeable — so each tab keeps its own data and scroll position.
Notifications goes from one shared feed to one per tab:

```diff
- let pager = signedIn ? makePaginator() : empty;
- const items = ref([]);          // one active feed, reset on tab switch
+ const feeds = reactive({         // one feed per pane, retained across swipes
+   all:     { items: [], state: 'idle' },
+   mention: { items: [], state: 'idle' },
+ });
```

That's the trade: you give up "render only what's visible," and the panes
stay warm — swipe away and back, and you're exactly where you left off, no
reload.

#### Going further: a collapsing profile

The profile page takes the pattern one step further into "native profile"
territory. [`AccountPage`](https://github.com/huxpro/vue-lynx/blob/main/examples/elk-viewpager/src/pages/AccountPage.vue)
wraps the same viewpager in Lynx's collapsing-header coordinator
([`StickyTabView.vue`](https://github.com/huxpro/vue-lynx/blob/main/examples/elk-viewpager/src/components/StickyTabView.vue)):
scroll down and the banner/bio/stats **header collapses**, the **tab bar
pins** to the top, and the Posts / Replies / Media panes below keep **paging
horizontally**, each with its own feed and scroll position. The coordinator
stacks as header (collapses) + toolbar (sticky tabs) + slot (the viewpager),
and its nested scroll folds the header first, then hands off to the active
pane's list. Like the viewpager it's registered per platform — the legacy
`<x-foldview-ng>` on Lynx for Web, the extracted
[`<scroll-coordinator>`](https://lynxjs.org/guide/ui/elements-components.html#xelement)
on native OSS engines.

## Native feed techniques

A Mastodon client is mostly long lists: home, local, federated, explore,
notifications, search, profile posts, followers. On the web Elk virtualizes
with [`virtua`](https://github.com/inokawa/virtua) and triggers the next page
from a DOM end-anchor's bounding box. Lynx gives you two scroll primitives —
and which one you pick is the whole performance story.

### `<scroll-view>` mounts everything

[`<scroll-view>`](https://lynxjs.org/api/elements/built-in/scroll-view) is the
right tool for **short, heterogeneous** screens: Settings, Compose, a status
thread, a media sheet. Every child stays mounted; you scroll a normal layout
tree. That is also why it is the **wrong** tool for a timeline — once the
federated feed grows past a few dozen statuses, you are paying for every card
above and below the viewport.

### `<list>` recycles and paginates

[`<list>`](https://lynxjs.org/api/elements/built-in/list) is Lynx's recycling
scroller. Off-screen `<list-item>` cells are reused; you only keep a window of
real nodes alive. Infinite scroll is a native event, not a geometry poll:

```vue
<list
  scroll-orientation="vertical"
  :lower-threshold-item-count="4"
  @scrolltolower="loadNext"
>
  <list-item
    v-for="status in items"
    :key="status.id"
    :item-key="status.id"
    :estimated-main-axis-size-px="160"
  >
    <StatusCard :status="status" />
  </list-item>
</list>
```

Three attributes do the heavy lifting:

| Piece | Role |
|-------|------|
| `estimated-main-axis-size-px` | Lets the list lay out the scroll range before each cell measures |
| `lower-threshold-item-count` | How many items from the end before we ask for more |
| `@scrolltolower` | Fires `usePaginator.loadNext()` — Elk's masto.js `Paginator` iteration, unchanged |

[`TimelinePaginator.vue`](https://github.com/huxpro/vue-lynx/blob/main/examples/elk/src/components/TimelinePaginator.vue)
is the shared feed shell: first paint, error/retry, the recycling list, and a
footer spinner / "End of the timeline". Timelines, Explore posts, hashtag
pages, bookmarks/favourites, and profile Posts / Replies / Media all reuse it.
Explore tags/news, notifications, followers, and search wire the same
`<list>` + `scrolltolower` pattern to their own item templates.

`<scroll-view>` still appears where recycling would not help — thread detail,
settings forms, the compose sheet. The rule of thumb the port settled on:
**if it can grow without bound, it is a `<list>`; if it is a finite page, keep
`<scroll-view>`.**

<Go
  example="elk"
  defaultFile="src/components/TimelinePaginator.vue"
  schema="{{{url}}}?fullscreen=true&bar_color=fafafa&bg_color=fafafa"
  highlight={{
  'src/components/TimelinePaginator.vue': '{21-26,39-59}',
}}
/>

## Why Elk is a serious test

Elk is a Nuxt 3 app with ~196 components, 55 pages and 50 composables.
Vue Lynx has no Nuxt (no SSR, file routing, Nitro, auto-imports) and no
DOM — so instead of forking, the port **reuses Elk's framework-agnostic
layers and rebuilds the UI on Lynx elements**:

| Layer | Verdict | Notes |
|-------|---------|-------|
| **masto.js API client** | ✅ reused unpatched | wrapper-injected native `fetch` is synchronized with web `globalThis.fetch`; remaining constructors are targeted through `source.define`, with fill-if-missing native shims |
| **Content pipeline** (`content-parse.ts`) | ✅ ~95% verbatim | ultrahtml sanitize + custom-emoji / markdown / mention-collapse transforms |
| **Content renderer** (`content-render.ts`) | ♻️ retargeted | same AST walk; emits `<text>`/`<image>` runs with tap navigation instead of `<p>`/`<a>`/`RouterLink` |
| **Paginator, timeline filters, status actions, search, cache** | ✅ reused | DOM scroll trigger → native `<list>` `scrolltolower` |
| **Virtual scrolling** | ♻️ replaced | Elk's DOM virtualizer (virtua) → Lynx's native recycling `<list>` — *less* code |
| **Routing** | ♻️ rebuilt | Nuxt file routes → explicit vue-router table on `createMemoryHistory`, same route shapes so content-renderer mention/hashtag rewrites work unchanged |
| **Every template** | ♻️ rebuilt | `<div>`→`<view>`, `<span>`→`<text>`, `@click`→`@tap`, Elk's exact theme palette as Lynx CSS vars |
| **Icons** | ♻️ adapted | Elk's RemixIcon set (`i-ri:*`) rendered as tinted XML through Lynx's built-in `<svg content>` element |
| **Native safe area** | ✅ adapted | fullscreen iOS cards consume Sparkling `topHeight` / `bottomHeight` global props, with Lynx Explorer alias support |

The full feature-parity checklist (including what's deliberately not
ported and why — OAuth redirects, TipTap, PWA, Shiki, blurhash…) lives in
[PRD.md](https://github.com/huxpro/vue-lynx/blob/main/examples/elk/PRD.md),
the architecture map in
[PORTING.md](https://github.com/huxpro/vue-lynx/blob/main/examples/elk/PORTING.md),
and side-by-side screenshot comparisons against the original elk.zone in
[screenshots/](https://github.com/huxpro/vue-lynx/blob/main/examples/elk/screenshots/README.md).

## Highlights

* **The content renderer is the crown jewel**: Mastodon statuses arrive as
  sanitized HTML. Elk parses them into an AST and renders vnodes; the port
  keeps the parse step byte-for-byte and only swaps the vnode targets —
  custom emoji become inline `<image>`, mentions/hashtags become tappable
  `<text>` runs that push vue-router routes.
* **Native virtualized timeline**: feeds use Lynx `<list>` with
  `estimated-main-axis-size-px` and `@scrolltolower` (not `<scroll-view>`);
  masto.js `Paginator` iteration and Elk's reorder/buffer logic drive
  `loadNext()` unchanged across timelines, explore, profiles, and search.
* **Deep links**: pass `globalProps: { initialPath: '/mas.to/tags/caturday' }`
  to the LynxView and the app opens on that route — the same mechanism a
  host app would use for notification taps.
* **Guest + token sessions**: browse anonymously like Elk's guest mode, or
  paste a personal access token in Settings to unlock home timeline,
  notifications, posting, boosts and favourites.



---
url: /guide/hackernews.md
---

# HackerNews

To better test that all ecosystem ingredients can work together, we forked Evan You's classic [Vue HackerNews 2.0](https://github.com/vuejs/vue-hackernews-2.0) as a "real-world" validation benchmark for Vue Lynx. Since Vue Lynx is built on Vue 3, we used the [Vue HackerNews 3.0](https://github.com/raukaute/vue-hackernews-3.0) community port as our reference as well. This port validates four mainstream ecosystem libraries working together: Vue Router, Pinia, TanStack Vue Query, and Tailwind CSS.

### Tailwind CSS Version

In the first iteration, we had AI rewrite the styles using Tailwind CSS (`@lynx-js/tailwind-preset`).

<Go example="hackernews-tailwind" defaultFile="src/App.vue" />

### CSS Version

For this version, we had AI reuse the original SCSS files from the reference implementation as much as possible. Interestingly, the CSS version maintains the `max-width` centered layout from the reference on desktop. Try clicking the "fullscreen" button below to see this in action.

Both HackerNews variants intentionally keep an explicit outermost `<page>`. Vue Lynx forwards that wrapper's classes, styles, and events to the single native page root; it does not create another native element. This lets the examples exercise root-level Tailwind and SCSS styling in LynxExplorer.

<Go example="hackernews-css" defaultFile="src/App.vue" />

## Lynx Engine Compatibility

The regression was bisected across both the frontend bundle and Lynx Engine versions:

| Bundle | Lynx Engine | Observed result |
|---|---|---|
| Tailwind 0.2.1 (implicit page root) | [3.6.0](https://github.com/lynx-family/lynx/releases/tag/3.6.0), [3.7.0](https://github.com/lynx-family/lynx/releases/tag/3.7.0) | Data loaded, but the active route remained invisible |
| Tailwind 0.2.1 (implicit page root) | [3.8.1](https://github.com/lynx-family/lynx/releases/tag/3.8.1), [3.9.0](https://github.com/lynx-family/lynx/releases/tag/3.9.0) | Feed rendered |
| CSS 0.2.1 (explicit page root, before this fix) | 3.6.0, 3.8.1, source-built 4.1 | Exact `990100 page ui not found` error |
| CSS 0.2.6 / pre-fix current bundle | source-built 4.1 | Same `990100` error |

:::warning Minimum inferred engine version
Use **Lynx Engine 3.8.1 or later** for these examples. It is the oldest tested engine that rendered the full Tailwind application. Engines 3.6.0 and 3.7.0 have a separate route-visibility limitation even when the data request succeeds.

The CSS error reproduced unchanged on 3.6.0, 3.8.1, and 4.1, so it was a frontend root-handling regression, not evidence that explicit `<page>` requires Engine 4.1. The fixed bundle has been directly verified on the source-built 4.1 engine; support for 3.8.1 and 3.9.0 is inferred from this bisect and the fix's reuse of the already-existing native page, pending a direct rerun on those Explorer releases.
:::

## Overview of Changes

Most code transferred directly — component logic, Vue Router, Composition API, and even `<Transition>`/`<TransitionGroup>` work identically. The Vue HackerNews 3.0 reference is a Webpack-based SSR app using Vue 3 + Vuex 4 + axios. Here's what we changed when porting to Lynx:

| Aspect | Vue 3 Reference | Vue Lynx |
|--------|-----------------|----------|
| **Template elements** | `<div>`, `<span>`, `<img>`, `<a>` | `<view>`, `<text>`, `<image>`, tap handlers |
| **Event handling** | `@click` | `@tap` |
| **Routing history** | `createWebHistory()` | `createMemoryHistory()` |
| **Scrolling** | Window scroll | `<scroll-view>` component |
| **State management** | Vuex 4 | Pinia |
| **Data fetching** | axios | TanStack Vue Query |
| **Build tool** | Webpack 5 + Express | Rspeedy |
| **SSR** | Full SSR with hydration | None (Lynx doesn't use SSR) |

### Notable adaptations:

* **No `v-html`**: Lynx has no HTML parser, so we use a `stripHtml()` utility to convert HTML comments to plain text
* **`<router-link>`**: Wrapped with Vue Router's `custom` slot API since Lynx has no `<a>` tags



---
url: /guide/ifr-benchmarks.md
---

import { Badge } from '@theme';

# IFR Benchmarks <Badge text="v0.5" type="tip" />

This page collects the measurement campaigns behind [Instant First-Frame
Rendering](/guide/ifr.md) and Element Templates. Each campaign answers one
question:

| campaign | the question it answers |
|---|---|
| [1. Strategy ladder](#1-strategy-ladder) | How much does the synchronous main-thread render **cost**, per design — and what is the ceiling? |
| [2. All-examples sweep](#2-all-examples-sweep) | What does IFR **cost in size and TTI** on real apps, and is it semantically safe? (Also: proof that a single process cannot measure its benefit.) |
| [3. Real threads](#3-real-threads) | What does IFR actually **win**, measured across a genuine thread boundary — with ReactLynx as the control? |
| [3b. Large-app reevaluation](#3b-large-app-reevaluation) | Does the −19% median still hold once TodoMVC / Hacker News / AI Chat / Elk join the matrix? |

**A note on configuration names.** Campaigns 1 and 2 ran before `enableIFR`
defaulted to enabling Element Templates. Columns are labeled with today's
product configurations: what the raw reports call `ifr` is today's **IFR
without ET** (`enableElementTemplates: false` opt-out), and `ifr+et` is
today's **default `enableIFR: true`**. Campaign 3b always sets both flags
explicitly. Full methodology and raw data:
[strategy benchmark](https://github.com/Huxpro/vue-lynx/blob/main/packages/ifr-bench/REPORT.md),
[all-examples sweep](https://github.com/Huxpro/vue-lynx/blob/main/packages/ifr-bench/EXAMPLES-REPORT.md),
[real-browser verification](https://github.com/Huxpro/vue-lynx/blob/main/packages/ifr-bench/VERIFICATION.md),
[large-app reevaluation](https://github.com/Huxpro/vue-lynx/blob/main/packages/ifr-bench/reeval/REEVALUATION.md).

## 1. Strategy ladder

> **Takeaway: Element Templates are the inflection point of render cost.
> Plain IFR replay costs as much JS as a full render (~8–11 ms per 1000
> elements under an interpreter); ET cuts it about 6–15× across reruns; a
> Vapor-style design would buy another 2–3× and sit at the PAPI floor.** This
> is why ET is enabled by default with IFR: it attacks the one real cost IFR
> adds to the main thread — the synchronous first-screen render inside
> `loadTemplate`.

Seven rendering strategies were prototyped and measured against the same
logical first screens through the same Element PAPI surface. All variants
produce byte-identical rendered documents. Scenes are ~1000–1400 elements:
**static-heavy** (99.7% template-static), **content** (card feed, 37%),
**list** (v-for, 12%).

### Warm render time, `--jitless` V8 (interpreter ≈ main-thread engine proxy)

| variant | static-heavy | content | list |
|---|---|---|---|
| bg-baseline (No IFR pipeline) | 11.86 ms | 9.36 ms | 6.87 ms |
| IFR without ET (shipped) | 10.94 ms | 8.40 ms | 6.57 ms |
| ifr-direct (prototype) | 8.17 ms | 6.36 ms | 4.89 ms |
| ifr-static-tpl (prototype) | 1.11 ms | 5.29 ms | 4.00 ms |
| **IFR + ET (shipped, default)** | **0.74 ms** | **1.26 ms** | **1.44 ms** |
| ifr-vapor (prototype upper bound) | 0.53 ms | 0.55 ms | 0.46 ms |
| papi-floor (reference) | 0.54 ms | 0.39 ms | 0.31 ms |

### Cold first run, `--jitless` (models a device's one-shot first frame)

| variant | static-heavy | content | list |
|---|---|---|---|
| IFR without ET | 18.0 ms | 16.4 ms | 11.7 ms |
| **IFR + ET** | **4.2 ms** | **5.3 ms** | **4.9 ms** |
| ifr-vapor | 1.4 ms | 1.2 ms | 0.8 ms |

### Ops payload that would cross the thread boundary

| variant | static-heavy | content | list |
|---|---|---|---|
| without ET | 77.6 KB | 60.4 KB | 45.1 KB |
| **with ET** | **69 B** | **9.2 KB** | **17.1 KB** |

The prototypes are kept for reference: `ifr-direct` was superseded by ET
(handle-based application is implied by template instantiation), and the
Vapor design remains the tracked endgame — its prototype omits
reactive-effect bookkeeping, so read its numbers as an optimistic bound.

## 2. All-examples sweep

> **Takeaway: this campaign measures IFR's *costs* and its *semantic
> safety* — not its benefit. Bundle gzip ×2.26 and a TTI upper bound of
> ×1.36 are the price; 22/23 examples rendering byte-identical documents
> across all configurations is the safety result. The per-example FCP
> columns come out flat (median ×1.04) — which is itself a finding: IFR is
> a dual-thread architecture optimization, and a single-process harness has
> no background boot or IPC to remove. Read the flat FCP as proof that the
> JS work is conserved, then see campaign 3 for the actual win.**

Every example was built in three configurations and executed as real bundle
halves in a PAPI-over-jsdom environment (5 runs each, medians, `--jitless`,
main-thread parse excluded as lepus ships precompiled bytecode).

| example | No IFR | IFR w/o ET | Δ | IFR + ET | TTI No IFR | TTI IFR w/o ET | ΔTTI | nodes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 7guis | 65.6 | 63.1 | −4% | 64.3 | 65.6 | 76.0 | +16% | 169 |
| basic | 32.0 | 34.3 | +7% | 33.7 | 32.0 | 44.0 | +38% | 9 |
| css-features | 43.3 | 50.0 | +15% | 44.2 | 43.3 | 63.3 | +46% | 51 |
| gallery | 66.6 | 65.0 | −2% | 69.5 | 66.6 | 89.4 | +34% | 4 |
| hackernews-css | 40.0 | 35.4 | −11% | 38.9 | 40.0 | 58.8 | +47% | 14 |
| hackernews-tailwind | 55.9 | 53.0 | −5% | 52.2 | 55.9 | 76.1 | +36% | 20 |
| hello-world | 33.5 | 35.6 | +6% | 36.0 | 33.5 | 45.7 | +36% | 16 |
| keep-alive | 47.7 | 44.5 | −7% | 46.5 | 47.7 | 57.0 | +19% | 56 |
| main-thread | 26.7 | 24.3 | −9% | 24.5 | 26.7 | 33.0 | +24% | 3 |
| networking | 24.9 | 30.5 | +23% | 35.1 | 24.9 | 30.5 | +23% | 0 |
| option-api | 53.8 | 57.1 | +6% | 59.7 | 53.8 | 68.8 | +28% | 9 |
| pinia | 40.1 | 38.7 | −4% | 39.4 | 40.1 | 50.0 | +25% | 19 |
| provide-inject | 32.2 | 34.3 | +6% | 37.9 | 32.2 | 43.7 | +36% | 13 |
| reactivity | 33.6 | 36.1 | +7% | 36.0 | 33.6 | 46.1 | +37% | 19 |
| slots | 40.1 | 43.8 | +9% | 39.0 | 40.1 | 54.3 | +35% | 47 |
| suspense | 42.3 | 38.4 | −9% | 38.3 | 42.3 | 51.1 | +21% | 16 |
| swiper | 30.3 | 28.5 | −6% | 29.8 | 30.3 | 41.1 | +36% | 47 |
| tailwindcss | 22.5 | 25.8 | +15% | 20.9 | 22.5 | 36.9 | +64% | 71 |
| todomvc | 17.9 | 21.6 | +21% | 20.7 | 17.9 | 31.4 | +76% | 11 |
| todomvc-day1 | 20.4 | 20.1 | −2% | 15.9 | 20.4 | 29.4 | +44% | 7 |
| transition | 45.9 | 45.2 | −1% | 47.7 | 45.9 | 59.7 | +30% | 56 |
| v-model | 39.1 | 40.9 | +4% | 40.7 | 39.1 | 52.3 | +34% | 26 |
| vue-router | 43.2 | 45.4 | +5% | 45.0 | 43.2 | 60.3 | +40% | 6 |

(FCP/TTI in ms. `networking` renders 0 nodes at first frame — fetch-driven,
the documented "don't enable IFR" profile. `todomvc-codex` was
thread-incompatible at measurement time and has since been fixed at the
example level.)

### Bundle size (gzip, KiB) — the headline cost

| example | No IFR | with IFR | Δ |
| --- | --- | --- | --- |
| hello-world | 34.5 | 76.3 | +121% |
| gallery | 37.2 | 80.0 | +115% |
| hackernews-css | 72.6 | 179.1 | +147% |
| networking | 57.5 | 145.5 | +153% |
| tailwindcss | 36.2 | 79.0 | +118% |
| **median (all examples)** | | | **×2.26** |

The main-thread bundle section grows from ~17 KiB (worklet registrations
only) to 78–195 KiB (Vue runtime + app copy); ET adds ~1% on top. The sweep
also surfaced and fixed three real bugs (`SystemInfo` clobbering,
numeric-style baking bypassing auto-px normalization, CSS Modules crashing
the main-thread bundle) — running every real app shape through the
dual-thread pipeline is worth doing for correctness alone.

## 3. Real threads

> **Takeaway: with a genuine thread boundary, IFR wins on content-first
> screens — FCP about −8% to −26% depending on the example set and host,
> with campaign medians of −19% (ten demos) and −12% (later seven-app mix).
> The win comes from removing background boot + IPC from the critical path.
> On small screens the two IFR configurations (with and without ET) are
> usually within a few percent on web FCP: ET's clearest measured advantages
> remain render cost and ops payload (campaign 1) and native cold starts.**

Setup: Lynx for Web — the background runtime runs in a genuine Web Worker
with real postMessage IPC, in headless Chromium. FCP = `<lynx-view>`
insertion → first painted content, medians of 7 fresh browser contexts.
Both throttle levels below come from one session measured under the
**current** flag semantics (`enableIFR: true` = IFR + ET; explicit opt-out =
IFR without ET). Absolute milliseconds drift with host load between
sessions; within-run ratios are the stable currency.

### The ReactLynx control

ReactLynx has no IFR-off switch, so "off" is emulated faithfully (empty
main-thread first screen, full background render + hydration). First, in the
**same single-process harness as campaign 2**, ReactLynx is just as flat as
Vue Lynx — the reference implementation cannot demonstrate its own headline
feature without a thread boundary either:

| ReactLynx probe (single process, jitless) | FCP | TTI |
|---|---|---|
| IFR on | 25.3 ms | 32.7 ms |
| IFR off (emulated) | 24.3 ms | 24.3 ms |

On real threads both frameworks win, by the same class of margin: the
ReactLynx probe (85 nodes) improves 97.7 → 75.2 ms (**−23%**), squarely
inside the range the Vue examples below span.

### Full matrix — no CPU throttle

| example (nodes) | No IFR | IFR w/o ET | Δ | IFR + ET (default) | Δ |
|---|---|---|---|---|---|
| hello-world (16) | 96.6 | 75.8 | −22% | 75.4 | −22% |
| todomvc-day1 (7) | 92.9 | 78.6 | −15% | 73.4 | −21% |
| swiper (39) | 100.5 | 77.7 | −23% | 79.1 | −21% |
| tailwindcss (68) | 95.7 | 80.9 | −15% | 80.6 | −16% |
| keep-alive (49) | 103.5 | 86.0 | −17% | 84.4 | −18% |
| transition (55) | 104.6 | 93.3 | −11% | 85.1 | −19% |
| 7guis (145) | 104.1 | 90.3 | −13% | 80.6 | −23% |
| gallery (302) | 136.6 | 104.5 | −23% | 109.9 | −20% |
| css-features (50) | 102.0 | 93.9 | −8% | 100.3 | −2% |
| hackernews-css (18) | 115.3 | 131.7 | **+14%** ⚠ | 131.8 | **+14%** ⚠ |

(FCP in ms. Medians: **−19%** default, −15% without ET — the per-example
differences between the two configurations flip between runs and should be
read as noise. The Hacker News row here pre-dates shell IFR; see
[§3b](#3b-large-app-reevaluation).)

### 4× CPU throttle

| example | No IFR | IFR w/o ET | Δ | IFR + ET | Δ |
|---|---|---|---|---|---|
| hello-world | 344.1 | 282.8 | −18% | 289.1 | −16% |
| todomvc-day1 | 313.2 | 281.7 | −10% | 280.6 | −10% |
| swiper | 333.1 | 304.9 | −8% | 298.4 | −10% |
| tailwindcss | 339.9 | 330.7 | −3% | 316.4 | −7% |
| keep-alive | 391.4 | 366.6 | −6% | 370.8 | −5% |
| gallery (302 nodes) | 437.2 | 430.5 | −2% | 434.5 | −1% |
| css-features | 352.0 | 353.6 | +0% | 346.4 | −2% |
| transition | 350.6 | 355.2 | +1% | 367.6 | +5% |
| 7guis | 352.1 | 366.8 | +4% | 355.0 | +1% |
| hackernews-css | 324.0 | 352.9 | **+9%** ⚠ | 360.0 | +11% |
| ReactLynx probe | 331.6 | 308.0 | −7% | — | |

Two readings from this campaign:

1. **Content-first screens keep a win under throttling** on this set
   (hello-world −16…−18%, todomvc-day1 −10%, swiper −10%), while screens
   whose FCP is dominated by CSS processing or big bundles compress toward
   zero — a throttled CPU multiplies the bundle-parse term that the web
   platform pays on the FCP path.
2. **The inversion profile reproduces at both throttle levels** when the
   first paint has little sync chrome. The Hacker News row above paid +14%
   at full speed and +9…11% throttled while the example skipped the IFR
   mount entirely. After shell IFR (always mount; gate fetches), the same
   app flipped to about **−12%** at full speed — see §3b. On native,
   precompiled lepus bytecode shrinks the parse term inversions are made of.

### How far is this from plain single-threaded web?

Vanilla single-threaded baselines (plain Vue via `@vue/runtime-dom`; plain
Preact via ReactLynx's exact fork pointed back at the real DOM) decompose
the remaining gap. On the ReactLynx probe screen, no throttle:

| component | cost | evidence |
|---|---|---|
| render 85 elements + paint (preact on DOM) | ~21 ms | plain-preact, framework pre-parsed |
| + framework fetch+parse on the FCP path | +7 ms | cold − warm |
| + the Lynx-for-Web platform layer | +47 ms | rl-ifr − plain-preact cold |
| + background boot + hydration IPC round-trip | +23 ms | rl-noifr − rl-ifr |

The thread boundary costs ~23 ms and **IFR removes exactly that slice**.
The remaining gap vs plain web is the web-host emulation layer — a per-host
constant that native Lynx, whose platform layer is native code, does not pay.

## 3b. Large-app reevaluation

> **Takeaway: keep the campaign-3 story for small content-first screens, and
> widen the range once product-sized apps join.** A second Lynx-for-Web pass
> (explicit `off` / `et` / `ifr` / `ifr-et` flags; hello-world, TodoMVC,
> gallery, Hacker News, AI Chat, Elk) landed content-first medians around
> **−12%** at full speed — inside the same −8%…−26% band as campaign 3's
> per-example spread, but a lower suite median than −19%. Under 4× throttle,
> Elk / AI Chat regress about **+25% to +44%**; the all-seven median flips
> slightly positive. Bundle gzip stays about **×2.2–2.5** (median ×2.23 here
> vs ×2.26 in campaign 2).

| source | set | IFR + ET FCP vs No IFR (no throttle) | notes |
|---|---|---|---|
| Campaign 3 (Claude Code) | 10 mostly small examples | **−8% to −23%, median −19%** | ReactLynx control −23% |
| Campaign 3b (Cursor) | 7 apps incl. TodoMVC, gallery, HN, AI Chat, Elk | content-first **~−12%** (hello **−26%**); all-seven median **−12%** with HN after shell IFR | absolute ms lower on a different host; compare ratios |
| Campaign 3b @ 4× throttle | same 7 | content-first **~−6%**; all-seven median **~+3%** | Elk +44%, AI Chat +25% |

### Focus matrix — no CPU throttle (campaign 3b)

Four explicit configs. FCP ms, medians of 7. `ifr` = IFR with
`enableElementTemplates: false`.

| example | nodes† | off | et | ifr | ifr+et | ifr+et Δ |
|---|---:|---:|---:|---:|---:|---:|
| hello-world | 16 | 63.6 | 60.0 | 48.6 | **47.0** | **−26%** |
| todomvc-day1 | 7 | 55.4 | 56.9 | 53.1 | **50.3** | **−9%** |
| todomvc | 11 | 63.2 | 71.6 | **49.1** | 55.9 | −12% |
| gallery | 304 | 74.7 | 75.8 | **61.3** | 62.3 | −17% |
| hackernews-css (shell IFR) | 347 | 71.5 | — | 64.1 | **63.0** | **−12%** |
| ai-chat | 104 | 90.4 | 90.3 | **74.9** | **74.9** | **−17%** |
| elk | 956 | 100.3 | 99.6 | 96.8 | 100.2 | **−0%** |

† Settled node count after hydration / fetch. Hacker News remounted with
shell IFR in this pass (earlier campaign-3 row skipped `app.mount()` on the
main thread and inverted). AI Chat / Elk leave IFR off in-tree; numbers are
forced-on for the matrix.

### Same set — 4× CPU throttle

| example | off | ifr | ifr+et | ifr+et Δ |
|---|---:|---:|---:|---:|
| hello-world | 163.6 | 158.1 | **141.1** | **−14%** |
| todomvc-day1 | 157.3 | 160.5 | **147.2** | **−6%** |
| todomvc | 168.4 | 157.9 | 159.0 | −6% |
| gallery | 206.6 | 206.0 | 213.0 | +3% |
| hackernews-css | 172.5 | 183.5 | 186.7 | +8% |
| ai-chat | 200.9 | 239.6 | 251.1 | **+25%** |
| elk | 235.6 | 338.6 | 340.0 | **+44%** |

**Reading across §3 and §3b:** treat **−12% to −19%** as the plausible
content-first median band on Lynx for Web, not a single headline −19%.
ET-only remains roughly free on size (~+1%) and flat on web FCP; keep
defaulting ET with IFR for the strategy-ladder render-cost win (about
**6–15×** across reruns), not because it moves small-screen web FCP.

Raw JSON and write-up:
[packages/ifr-bench/reeval/](https://github.com/Huxpro/vue-lynx/tree/main/packages/ifr-bench/reeval).

## 4. Native engine observations

The full example suite was validated on a native simulator (LynxExplorer,
Lynx SDK 1.4 / PrimJS): 24/25 examples pass with **zero hydration
mismatches**, and No-IFR vs IFR+ET screens are visually identical (SSIM ≥
0.9977; scoped CSS, baked inline styles, and auto-px semantics all correct
on the native engine). Single-sample cold-start recordings show first
content ~0.3 s earlier (gallery) up to ~1.2 s earlier (7guis) with IFR —
directional confirmation of the mechanism, not a stable benchmark.

## Reproduce

```bash
# strategy ladder + correctness oracle
pnpm --filter vue-lynx-ifr-bench run check
pnpm --filter vue-lynx-ifr-bench run bench

# all-examples sweep
node packages/ifr-bench/examples-sweep/orchestrate.mjs <dir>
node packages/ifr-bench/examples-sweep/sweep.mjs <dir>

# real-browser (Lynx for Web) measurement, with plain-web baselines
node packages/ifr-bench/web-harness/run-browser.mjs <bundlesDir> [runs] [throttle]

# focused 4-config rebuild (incl. ai-chat / elk) used for §3b
node packages/ifr-bench/reeval/orchestrate-focused.mjs <dir>
```



---
url: /guide/ifr.md
---

import { Badge } from '@theme';

# Instant First-Frame Rendering (IFR) <Badge text="v0.5" type="tip" />

Instant First-Frame Rendering (IFR) displays real content during
`loadTemplate`, before the background thread starts. Vue Lynx pairs IFR with
Element Templates, which reduce the work required to create static-structure
subtrees. Together they remove the blank-frame wait and make the synchronous
main-thread render substantially cheaper.

## Configuration

Enable IFR in `lynx.config.ts`:

```ts title="lynx.config.ts"
import { defineConfig } from '@lynx-js/rspeedy'
import { pluginVueLynx } from 'vue-lynx/plugin'

export default defineConfig({
  plugins: [
    pluginVueLynx({
      enableIFR: true,
    }),
  ],
})
```

Element Templates are enabled automatically when IFR is enabled. No app-code
changes are required for a typical component tree.

| configuration | `enableIFR` | `enableElementTemplates` | purpose |
| --- | ---: | ---: | --- |
| No IFR | `false` | `false` | Default background-thread rendering |
| IFR + ET | `true` | omitted or `true` | Recommended IFR path |
| IFR without ET | `true` | `false` | Compatibility, debugging, and measurement opt-out |

To isolate an Element Templates issue while keeping IFR active, opt out
explicitly:

```ts title="lynx.config.ts"
pluginVueLynx({
  enableIFR: true,
  enableElementTemplates: false,
})
```

Element Templates can also be enabled independently for ordinary background
rendering with `enableElementTemplates: true`. This is an advanced composition,
not the recommended IFR setup.

## Why IFR removes the blank frame

Without IFR, visible content waits for the background thread to boot, evaluate
the application, render Vue's tree, and send an ops batch back to the main
thread:

```text
Main Thread:       empty page ─────────────────────────▶ apply ops ─▶ paint
Background Thread:             boot ─▶ render ─▶ IPC ──┘
```

With IFR, the main-thread bundle carries the Vue runtime and application code.
Vue renders synchronously inside `loadTemplate`, while the background thread
starts in parallel:

```text
Main Thread:       loadTemplate ─▶ render ─▶ paint
Background Thread:              boot ─▶ render ─▶ hydrate
```

The first screen therefore appears before any background JavaScript has run.
After hydration, the background thread owns the tree and all later updates use
the normal ops pipeline.

## Hydration

Both threads execute the same application with the same initial data. The
main-thread render records every ops batch it applies. The background thread's
initial batches are reconciled against that recording:

* Identical batches are skipped because their result is already on screen.
* Text, style, and attribute differences are patched in place.
* Structural differences remove the first-screen tree and rebuild it from the
  background ops.

Correctness does not depend on both renders matching. A structural mismatch
only loses the IFR performance benefit and produces an
`[vue-lynx] IFR hydration mismatch` warning in development.

Event signs and element IDs are deterministic across both renders. Once the
background handler registry is ready, events from first-frame elements route to
the normal Vue handlers without rebinding.

<span id="element-templates" />

## Element Templates

IFR changes **when** the first frame is rendered. Element Templates reduce
**how much work** that render performs.

In the ordinary path, each static element still creates a vnode and shadow
node, emits several ops frames, crosses the thread boundary, and reaches the
main-thread ops interpreter. The compiler can collapse an eligible subtree:

```text
Without ET: vnode → ShadowElement → per-node ops → interpreter → PAPI
With ET:    one vnode → INSTANTIATE_TEMPLATE → straight-line PAPI create()
```

The static skeleton becomes a compiler-generated JavaScript `create()`
function. Vue sends one `INSTANTIATE_TEMPLATE` op for the subtree; dynamic text,
classes, styles, and attributes are holes updated through the ordinary
`SET_*` ops.

### What gets lowered

A subtree is eligible when its structure is known at compile time: every node
is a plain Lynx element and only property values or text content are dynamic.

```vue
<view class="card">                       <!-- one lowered subtree -->
  <image class="icon" src="a.png" />     <!-- baked skeleton      -->
  <text class="title">{{ title }}</text> <!-- dynamic text hole   -->
  <view :class="badgeClass">...</view>   <!-- dynamic class hole  -->
</view>
```

Structural features stay on the normal vnode path:

* components, slots, and `v-if` / `v-for` hosts; their plain-element bodies can
  still be lowered
* runtime directives, refs, keys, IDs, and vnode hooks on interior nodes
* `<list>` and `<list-item>`, which have dedicated main-thread behavior
* comments and mixed dynamic text runs

The template root retains its normal vnode props and directives. Scoped CSS is
supported: the compiler bakes the component CSS scope ID into each lowered
element. Static inline styles are baked only when their semantics are known to
match the ordinary style path.

### Framework templates, not binary engine templates

Vue Lynx does not currently use Lynx's binary `elementTemplates` bundle section,
`__ElementFromBinary`, or `__GetTemplateParts`. Its Element Templates are a
framework-level optimization built from ordinary typed Element PAPI calls.

This removes vnode, per-node ops, serialization, and interpreter dispatch while
preserving the existing renderer and hydration protocol. A binary-template
backend could consume the same static-skeleton and hole metadata in the future,
but it is not part of this implementation.

### Semantics guarantee

Lowering is an optimization, not a rendering mode. Ineligible structures fall
back automatically, and lowered and unlowered trees must produce the same
rendered document and updates. Interior nodes do not carry Vue's selector
bookkeeping attributes, but any element with a `ref`, ID, or other identity
requirement is kept out of the anonymous interior path.

## Writing IFR-friendly first screens

The initial render executes once per thread, so it should behave like a pure
function of its inputs:

* Keep first-screen output deterministic. Avoid `Math.random()`, `Date.now()`,
  or thread-dependent branching in render paths.
* Put data fetching, timers, subscriptions, and other side effects in
  Composition API lifecycle hooks. These hooks are suppressed during the
  main-thread render and run on the background thread.
* Options API `mounted()` is not yet suppressed on the main thread. Prefer
  Composition API hooks for first-screen components that use IFR.
* IFR paints only synchronously available data. A fetch-driven screen should
  still **mount** and render a useful shell or skeleton on the main thread —
  gate the network work (for example `useQuery({ enabled: !isIfrMainThread() })`),
  do not skip `app.mount()` entirely. Skipping the mount keeps the larger IFR
  bundle with none of the first-paint benefit.
* Regular events can be dropped in the short interval before the background
  registry is ready. [Main Thread Script](/guide/main-thread-script.md) handlers
  remain interactive because they already live on the main thread.

## Trade-offs

* IFR places the Vue runtime and application in both thread bundles. Across the
  example suite, `main.lynx.bundle` gzip size grows by about 2.26x at the median.
* The application evaluates on both threads. The all-examples serial-work TTI
  proxy grows by about 35–36%; on a device, main-thread rendering overlaps with
  background startup.
* IFR cannot accelerate content that does not exist until an asynchronous
  request completes.
* CSS Modules class names can be un-hashed on the first frame and patched to
  their final names during hydration.

Measure bundle-sensitive and fetch-driven screens before enabling IFR. For
content-first screens with synchronous initial data, IFR + ET is the recommended
configuration.

## Benchmarks

The table keeps the three product configurations separate. FCP is hello-world
on Lynx for Web with a real Web Worker (no CPU throttle). Render cost is the
warm median for a roughly 1,000-element dynamic-content scene under V8
`--jitless`. TTI and gzip are medians from the all-examples sweep, normalized
to No IFR. These are separate campaigns; the columns should not be read as one
end-to-end trace.

| configuration | flags | FCP (hello-world) | render cost | TTI proxy | bundle gzip |
| --- | --- | ---: | ---: | ---: | ---: |
| No IFR | `IFR=false, ET=false` | 96.6 ms | 9.4 ms | 1.00x | 1.00x |
| **IFR + ET** | `IFR=true, ET=default` | **75.4 ms (−22%)** | **1.3 ms** | 1.35x | ~2.26x |
| IFR without ET | `IFR=true, ET=false` | 75.8 ms (−22%) | 8.4 ms | 1.36x | ~2.26x |

Across campaigns, the **content-first** Lynx-for-Web FCP win for default
IFR + ET sits roughly in **−12% to −26%** (medians −19% on a ten-example
demo suite; −12% on a later seven-app set that adds TodoMVC / gallery and
larger apps). Absolute milliseconds drift by host; ratios are the stable
currency. See [IFR Benchmarks](/guide/ifr-benchmarks.md) for both runs.

### What the data says

1. **IFR's win is real and structural on content-first screens.** With a
   genuine thread boundary (Lynx for Web), IFR removes background-thread boot
   * IPC from the critical path — which is also why a single-process
     benchmark cannot see it. One campaign (ten mostly small examples) saw
     **−8% to −23%, median −19%**; a later reevaluation including TodoMVC,
     gallery, Hacker News (shell IFR), AI Chat, and Elk saw content-first
     medians around **−12%** at full speed (hello-world alone about −22% to
     −26% depending on host). ReactLynx's control on the first harness was
     −23%, the same class of win.
2. **Element Templates attack the one cost IFR adds.** The synchronous
   main-thread render gets about **6–15×** cheaper across strategy-ladder
   reruns, and the ops payload shrinks 3–1,000× (a 1,400-element static
   screen ships 69 bytes instead of 78 KB). On web FCP for small screens
   this often does not show — the two IFR configurations are usually within
   a few percent — but the render-cost term grows with screen size and
   shrinks with CPU speed, which is why ET defaults on with IFR.
3. **The price is bundle size, and large / fetch-heavy apps can invert.**
   `main.lynx.bundle` gzip grows about **×2.2–2.5** (suite median ~×2.26).
   On the web, bundle parse sits on the FCP path: under 4× CPU throttle,
   big apps (Elk, AI Chat) have measured **+25% to +44%** FCP with IFR, while
   small content-first screens still keep a thinner win. Paint a real shell
   under IFR; do not skip `app.mount()` just because data is async
   (Hacker News recovered from about **+38% to −12%** at full speed after
   switching to shell IFR).

### Recommendations

| your first screen | do this |
| --- | --- |
| content-first, renders from synchronous data | **enable `enableIFR: true`** (brings ET) — typical web FCP win about **−12% to −26%** on content-first sets |
| data-driven with a sync shell / skeleton | enable; gate fetches off the IFR main-thread pass |
| fetch-driven with **nothing** useful to paint before a response | don't enable; or add a real shell first, then enable |
| large bundle on web + slow CPU | measure — throttle can erase or reverse the win |
| bundle-size-critical | measure first — gzip roughly doubles |

And regardless of profile: keep the first screen deterministic and put side
effects in Composition API lifecycle hooks (see
[Writing IFR-friendly first screens](#writing-ifr-friendly-first-screens));
reach for `enableElementTemplates: false` only to bisect a suspected
ET issue — not as a performance setting.

The full measurement campaigns — the seven-variant strategy ladder,
per-example FCP/TTI/size across the whole example suite, the real-browser
dual-thread comparison against ReactLynx, a later large-app reevaluation,
and the single-threaded plain-web decomposition — are on the dedicated
[IFR Benchmarks](/guide/ifr-benchmarks.md) page.



---
url: /guide/introduction.md
---

# What is Vue Lynx?

**Vue Lynx** is a Vue 3 custom renderer for [Lynx](https://lynxjs.org), enabling you to build native Lynx applications using Vue's familiar Composition API, single-file components, and reactive data model.

If you know Vue 3 and are familiar with Lynx, you already know how to use Vue Lynx.

## Main Features

* **Familiar Vue 3 API** — Use `ref()`, `computed()`, `v-for`, `v-if`, SFC `<script setup>`, and everything you love about Vue.
* **Cross-Platform Native Rendering** — Lynx provides a high-performance native rendering engine on mobile and desktop, as well as first-class Web rendering.
* **Dual-Thread Architecture** — Vue runs on the background thread; the main thread handles native rendering. This separation keeps your app responsive. For latency-sensitive interactions (drag, scroll), [Main Thread Script](/guide/main-thread-script.md) lets you mark functions with `'main thread'` to run directly on the main thread with zero cross-thread delay.

## For Vue Web Developers

If you're coming from Vue on the web, most of what you know carries over. Here are the key differences.

### Change your `import`

Vue Lynx re-exports the Vue API, so you can replace `vue` with `vue-lynx`:

```diff
- import { ref, computed, onMounted } from 'vue';
+ import { ref, computed, onMounted } from 'vue-lynx';
```

### Different elements

Lynx provides native elements instead of HTML. Use `<view>`, `<text>`, `<image>`, etc. in place of `<div>`, `<span>`, `<img>`:

```diff
- <div class="card">
-   <span>{{ message }}</span>
- </div>
+ <view class="card">
+   <text>{{ message }}</text>
+ </view>
```

:::info
Text content must be wrapped in `<text>` — Lynx does not support bare text nodes inside `<view>`.
:::

### Different events

Lynx uses its own event system. Unlike the DOM, where an event is identified by its name alone, every Lynx event is registered with a **type** that controls propagation and threading: `bind` (propagates), `catch` (stops propagation), `global-bind` (app-global events from [GlobalEventEmitter](https://lynxjs.org/api/lynx-api/lynx/lynx-get-js-module.html)), and `main-thread` variants (Main Thread Script handlers that run on the main thread). Vue Lynx keeps Lynx's own attribute naming for all of them, so any event from the Lynx docs works verbatim as an attribute binding:

```vue
<view
  :bindtap="onTap"
  :catchtap="onTapAndStop"
  :global-bindkeyboardstatuschanged="onKeyboard"
  :main-thread-bindtap="onMainThreadTap"
/>
```

For the common `bind` type, Vue's familiar `@` syntax works as sugar. `@tap` is equivalent to `:bindtap`, and the `.stop` modifier upgrades the registration to a native `catch` (`@tap.stop` ≙ `:catchtap`):

```diff
- <div @click="handleClick" @touchstart="onTouch">
+ <view @tap="handleClick" @touchstart="onTouch">
```

`global-bind*` and `main-thread-*` have no `@` form: they encode registration semantics that Vue's `v-on` cannot express. In particular, a `main-thread` handler is a [Main Thread Script](/guide/main-thread-script.md) function rather than a regular one, and bypasses the `v-on` pipeline entirely.

See the [Lynx event handling guide](https://lynxjs.org/guide/interaction/event-handling.html) for more details.

### No `document` or `window`

Lynx does not provide browser globals. Libraries that depend on `document` or `window` need adaptation to work. Instead, Lynx provides its own [APIs](https://lynxjs.org/next/api/lynx-api/lynx) via the [`lynx`](https://lynxjs.org/next/api/lynx-api/lynx.html) global object:

* [Global APIs](https://lynxjs.org/next/api/lynx-api/global.html) like `setTimeout()` and `console.log()` are available on both threads, same as the web.
* DOM-like queries (e.g. `querySelector`, `getBoundingClientRect`) are available as [async background-thread APIs](https://lynxjs.org/next/api/lynx-api/nodes-ref.html) or [synchronous Main Thread APIs](https://lynxjs.org/next/api/lynx-api/main-thread.html) depending on which thread you need them on.
* Platform-native capabilities are available via [NativeModules](https://lynxjs.org/guide/use-native-modules.html) and [Custom Elements](https://lynxjs.org/guide/custom-native-component.html).

## Understanding the Dual-Thread Model

You should expect your Vue code to just work on Lynx. Vue Lynx reuses `@vue/runtime-core` directly, so the Vue API behaves the same as on the web — see [Vue Compatibility](/guide/vue-compatibility.md) for the full feature-by-feature breakdown.

The main thing that differs is the threading model. If you've worked with Web Workers, Lynx's architecture will feel familiar. Vue runs on a **background thread** while native rendering happens on the **main thread** — just like offloading work to a Web Worker so the UI thread stays responsive. The difference is that in Lynx, this is the *default* — Vue reconciliation never blocks the main thread. (See [Use the Main Thread Responsibly for Interactivity](https://lynxjs.org/next/blog/lynx-unlock-native-for-more#use-the-main-thread-responsibly-for-interactivity) for the design rationale.)

Under the hood, Vue Lynx uses a [custom renderer](https://vuejs.org/api/custom-renderer) that builds a **ShadowElement** tree on the background thread. Changes are batched as **ops** and flushed to the main thread. User interactions flow back as **events**. This forms a cycle analogous to the browser event loop:

```
        ┌────────────────────────────────────────────────────────────┐
        │                     Background Thread                      │
        │  Vue 3 runtime · reactivity · lifecycle · your code        │
        └──────────────┬──────────────────────▲──────────────────────┘
                  ops  │                      │  events
                       ▼                      │
        ┌─────────────────────────────────────┴──────────────────────┐
        │                        Main Thread                         │
        │  Native elements · layout · rendering · Main Thread Script │
        └────────────────────────────────────────────────────────────┘
```

One full cycle — ops down, events back up — is one **tick**. Vue Lynx's `nextTick` resolves after a complete cycle, so by the time your callback fires, native elements are fully materialized. This is the same mental model as Vue's `nextTick` on the web (wait for DOM update), just extended across threads.

### What this means in practice

In day-to-day development, the dual-thread model is largely transparent. There are only two things to keep in mind:

#### Lifecycle runs on the background thread — use `nextTick` to wait for the main thread

Just like on the web, `onMounted` means "the component tree is built." The difference is that native elements are created asynchronously on the main thread. If you need to interact with native elements after mount, wait one tick:

```vue
<script setup lang="ts">
import { onMounted, nextTick } from 'vue-lynx'

onMounted(() => {
  nextTick(() => {
    // Native elements are now ready
    lynx.createSelectorQuery().select('.my-list').invoke(...)
  })
})
</script>
```

If your `onMounted` only sets up reactive state, timers, or data fetching, no `nextTick` is needed — those don't depend on native elements.

#### Main Thread Script for zero-latency interactions (advanced)

From the background thread, native element access is always asynchronous. For most use cases this is fine. Template `ref` returns a `ShadowElement` (a background-thread reference to the native element), and layout queries like `getBoundingClientRect()` are available via an [async API](https://lynxjs.org/next/api/lynx-api/nodes-ref.html):

```vue
<script setup lang="ts">
import { onMounted, nextTick } from 'vue-lynx'

onMounted(() => {
  nextTick(() => {
    lynx.createSelectorQuery()
      .select('.target')
      .invoke({
        method: 'boundingClientRect',
        success: (res) => console.log(res),
      })
      .exec()
  })
})
</script>
```

When you need synchronous access — smooth animations, gesture handling, layout measurement — use [Main Thread Script](/guide/main-thread-script.md). Functions marked `'main thread'` run directly on the main thread and can call [Main Thread APIs](https://lynxjs.org/next/api/lynx-api/main-thread.html) like [`getComputedStyleProperty()`](https://lynxjs.org/next/api/lynx-api/main-thread/element-get-computed-style.html), listen to `main-thread-bindlayoutchange`, and access native elements via `useMainThreadRef()`:

```vue
<script setup lang="ts">
import { ref, useMainThreadRef } from 'vue-lynx'

const divRef = ref(null)               // ShadowElement (background thread)
const mtRef = useMainThreadRef(null)    // Native element (Main Thread Script only)
</script>

<template>
  <view ref="divRef" :main-thread-ref="mtRef" />
</template>
```

See [Vue Features Compatibility](/guide/vue-compatibility.md) for feature-specific caveats and unsupported features.

## Next Steps

* [Vue Compatibility](/guide/vue-compatibility.md) — Feature-by-feature breakdown of what works and what differs
* [Main Thread Script](/guide/main-thread-script.md) — Run performance-critical logic on the main thread
* [Tutorial: Product Gallery](/guide/tutorial-gallery.md) — Build a waterfall gallery with tap-to-like, auto-scroll, and a Main Thread Script scrollbar
* [Tutorial: Product Detail](/guide/tutorial-swiper.md) — Build a touch-swipeable image carousel with snap animation



---
url: /guide/main-thread-script.md
---

# Main Thread Script

The Main Thread Script is a JS script that can be executed on the main thread. The most common use cases are smooth animations and gesture handling. It addresses the response delay inherent in Lynx's multi-threaded architecture, aiming to achieve a near-native interactive experience.

## Event Response Delay in Lynx

Here is a simple animation: a small square that moves in sync with a `scroll-view`. In the component, we listen to the scroll event, retrieve the current scroll position from the event parameters, and update the square's position immediately:

<Go example="main-thread" defaultEntryFile="dist/background-draggable.lynx.bundle" defaultFile="src/background-draggable/App.vue" entry="src/background-draggable" />

You can try scrolling the scroll-view on the left side of the example. The blue square on the right will follow the scroll-view's movement. However, you might notice that its movement has an unpredictable delay, especially on devices with lower performance. This delay also increases as the complexity of the page increases.

This is because in Lynx's architecture, events are triggered on the main thread, while regular JS event handlers (Vue's `@scroll`, etc.) can only be executed on background threads. Therefore, using regular events to trigger animations introduces multiple thread crossings, resulting in untimely responses and animations lagging behind gestures.

```
  Without Main Thread Script:

  ┌────────────────┐      ┌────────────────────┐      ┌────────────────┐
  │  Main Thread   │      │ Background Thread   │      │  Main Thread   │
  │  (event fires) │ ──▶  │ (Vue handler runs)  │ ──▶  │  (render)      │
  └────────────────┘      └────────────────────┘      └────────────────┘
          ▲                                                    │
          └─────────────── 2 thread crossings ─────────────────┘
```

The main thread script provides the capability to handle events synchronously on the main thread, ensuring synchronous event responses.

```
  With Main Thread Script:

  ┌────────────────────────────────────────────────────────────┐
  │                       Main Thread                          │
  │   event fires  ──▶  handler runs  ──▶  render              │
  └────────────────────────────────────────────────────────────┘
                      0 thread crossings
```

## Use Main Thread Functions to Eliminate Event Response Delay

### Implementing Animations with Main Thread Script

Synchronizing events using main thread script is very simple. Here we try to modify the previous example.

First, we inform the framework that we want to handle this event on the main thread by using the `main-thread-bindscroll` attribute instead of `@scroll`:

```vue
<scroll-view :main-thread-bindscroll="onScroll" />
```

Since `onScroll` is now a main thread event handler, we also need to declare it as a main thread function. This is done by adding a `'main thread'` directive as the first line inside the function body:

```ts
const onScroll = (event) => {
  'main thread'
  // ...
}
```

After declaring it as a main thread function, we can no longer call it from the background thread.

Finally, we can now directly manipulate the element's properties on the main thread, so there's no need to use a reactive `ref` to change the position. When using a main thread function as an event handler, we can obtain a reference to the target element using `useMainThreadRef()` and access it via `.current` inside the main thread function. This object allows you to synchronously get and set node properties, such as using `setStyleProperty()` in the example:

```vue
<script setup lang="ts">
import { useMainThreadRef } from 'vue-lynx'

const mtDraggableRef = useMainThreadRef(null)

const onScroll = (event: { detail?: { scrollTop?: number } }) => {
  'main thread'
  const scrollTop = event.detail?.scrollTop ?? 0
  const el = (mtDraggableRef as unknown as {
    current?: { setStyleProperty?(k: string, v: string): void }
  }).current
  if (el?.setStyleProperty) {
    el.setStyleProperty('transform', `translate(0px, ${500 - scrollTop}px)`)
  }
}
</script>

<template>
  <scroll-view :main-thread-bindscroll="onScroll">
    <!-- ... -->
  </scroll-view>
  <view :main-thread-ref="mtDraggableRef">
    <!-- ... -->
  </view>
</template>
```

That's all the changes needed. The example below places the components before and after the modification side by side for comparison. You may notice that the animation delay has disappeared!

<Go example="main-thread" defaultEntryFile="dist/main-thread-draggable.lynx.bundle" defaultFile="src/main-thread-draggable/App.vue" entry="src/main-thread-draggable" />

## Retrieving Data from the Background Thread

You may have noticed that designating a function as a main thread function isolates it from its surrounding context, making it feel like an "island." Its runtime environment is different from other functions, meaning it cannot freely communicate with the background thread.

However, obtaining data from the background thread inside a main thread function is straightforward: just use it directly, as if it were a normal function.

```vue
<script setup lang="ts">
const red = 'red'

const addBackgroundColor = (event: MainThread.ITouchEvent) => {
  'main thread'
  event.currentTarget.setStyleProperty('background-color', red)
}
</script>

<template>
  <view :main-thread-bindtap="addBackgroundColor">
    <text>Hello World!</text>
  </view>
</template>
```

When the main thread function is defined, it automatically captures external variables from the background thread, such as the `red` variable in the example above. However, you cannot directly modify the values in the background thread.

The values captured by the main thread function are not updated in real time. Instead, they are synchronized from the background thread to the main thread only after the component containing the main thread function re-renders. Additionally, the synchronization requires that the captured values be serializable using `JSON.stringify()`.

To summarize the precautions:

* Main thread functions can and must only run on the main thread. Main thread functions can call each other.
* Captured variables need to be passed between threads using `JSON.stringify()`, so they must be serializable to JSON.
* Main thread functions do not support nested definitions.
* You cannot modify variables captured from the external scope within a main thread function.

## Using `main-thread-ref` to Obtain Node Objects

In the example above, clicking on the view would change its background color. If we want to change the color of only a specific child element, it is not easy to achieve with just `event.target` and `event.currentTarget`. In this case, you can use `main-thread-ref` to obtain a node object usable on the main thread.

Create a `MainThreadRef` using the `useMainThreadRef()` composable, and then assign it to the target node's `main-thread-ref` attribute:

```vue
<script setup lang="ts">
import { useMainThreadRef } from 'vue-lynx'

const red = 'red'
const textRef = useMainThreadRef(null)

const addBackgroundColor = (event: MainThread.ITouchEvent) => {
  'main thread'
  const el = (textRef as unknown as {
    current?: { setStyleProperty?(k: string, v: string): void }
  }).current
  el?.setStyleProperty?.('background-color', red)
}
</script>

<template>
  <view :main-thread-bindtap="addBackgroundColor">
    <text :main-thread-ref="textRef">Hello World!</text>
    <text>Hello World!</text>
  </view>
</template>
```

Note that the `current` property of `MainThreadRef` can only be accessed within a main thread function.

## Maintaining State in Main Thread Functions

Main thread functions cannot modify captured variables. Therefore, if you need to maintain state between main thread functions, you should use `MainThreadRef`:

```vue
<script setup lang="ts">
import { useMainThreadRef } from 'vue-lynx'

const countRef = useMainThreadRef(0)

const handleTap = (event: MainThread.ITouchEvent) => {
  'main thread'
  event.currentTarget.setStyleProperty(
    'background-color',
    ++countRef.current % 2 ? 'blue' : 'green'
  )
}
</script>

<template>
  <view :main-thread-bindtap="handleTap">
    <text>Tap me!</text>
  </view>
</template>
```

## Cross-Thread Function Calls

The examples so far use `'main thread'` functions as event handlers. But what if you need to call a main thread function from the background thread, or vice versa? Vue Lynx provides `runOnMainThread()` and `runOnBackground()` for bidirectional async communication.

<Go example="main-thread" defaultEntryFile="dist/cross-thread-calls.lynx.bundle" defaultFile="src/cross-thread-calls/App.vue" entry="src/cross-thread-calls" />

In this example, tapping the box triggers a round trip:

1. **Main Thread** `onTap` fires, calls `runOnBackground(incrementCount)()` to update reactive state
2. **Background Thread** `watch(count)` fires, calls `runOnMainThread(applyColor)(nextColor)` to change the box color

### Asynchronously Invoking Main Thread Functions from the Background Thread

Use `runOnMainThread()` in the background thread to asynchronously execute a main thread function on the main thread:

```vue
<script setup lang="ts">
import { useMainThreadRef, runOnMainThread } from 'vue-lynx'

const countRef = useMainThreadRef(0)

const addCount = (value: number) => {
  'main thread'
  countRef.current += value
  return countRef.current
}

async function increaseMainThreadCount() {
  const result = await runOnMainThread(addCount)(1)
  console.log(result)
}
</script>
```

### Asynchronously Invoking Non-Main Thread Functions from the Main Thread

Use `runOnBackground()` on the main thread to asynchronously execute a regular function on the background thread:

```vue
<script setup lang="ts">
import { ref } from 'vue'
import { runOnBackground } from 'vue-lynx'

const current = ref(0)

const syncIndexToBackground = runOnBackground((nextIndex: number) => {
  current.value = nextIndex
  return `Current index updated to ${nextIndex}`
})

const onScrollMainThread = async (event: { detail: { scrollTop: number } }) => {
  'main thread'
  const index = Math.round(event.detail.scrollTop / 300)
  const result = await syncIndexToBackground(index)
  console.log(result)
}
</script>

<template>
  <view>
    <scroll-view :main-thread-bindscroll="onScrollMainThread" />
    <text>Current index: {{ current }}</text>
  </view>
</template>
```

## Cross-Thread Shared Modules

By default, main thread functions cannot directly call plain functions that do not have the `'main thread'` directive. This makes code reuse difficult.
To address this limitation, Vue Lynx supports the `shared-module` mechanism, allowing you to explicitly declare certain modules as shareable between the main thread and the background thread.

Add `with { runtime: 'shared' }` after the `import` statement, and the exported variables (including functions, classes, objects, etc.) in that module can be directly called in main thread functions:

```ts
import { func } from './utils' with { runtime: 'shared' }

const onTap = () => {
  'main thread'
  func() // ✅ Allows calling plain functions in a main thread function
}
```

> \[!NOTE]
> Functions in modules imported with `with { runtime: 'shared' }` can be called by main thread functions, but they are not automatically treated as main thread functions. If they use main-thread-specific capabilities like `MainThreadRef`, they must still be manually marked with `'main thread'`.

The shared module is a regular TypeScript/JavaScript file — it does **not** need a `'main thread'` directive. It must contain only plain functions and constants (no Vue reactivity, no DOM access, no side effects that depend on a specific thread).

```ts
// color-utils.ts — shared between both threads
const COLORS = ['#4FC3F7', '#81C784', '#FFB74D', '#E57373', '#BA68C8']

export function getNextColor(index: number): string {
  return COLORS[index % COLORS.length]!
}
```

Once imported with `{ runtime: 'shared' }`, the exported functions can be called both inside `'main thread'` functions and in regular background thread code:

```vue
<script setup lang="ts">
import { ref, computed } from 'vue'
import { useMainThreadRef } from 'vue-lynx'
import { getNextColor } from './color-utils' with { runtime: 'shared' }

// Background Thread: use shared function in computed/watch
const count = ref(0)
const currentColor = computed(() => getNextColor(count.value))

// Main Thread: use the same shared function in a tap handler
const boxRef = useMainThreadRef(null)
const onTap = () => {
  'main thread'
  const color = getNextColor(1)
  const el = (boxRef as unknown as {
    current?: { setStyleProperty?(k: string, v: string): void }
  }).current
  el?.setStyleProperty?.('background-color', color)
}
</script>
```

<Go example="main-thread" defaultEntryFile="dist/shared-module.lynx.bundle" defaultFile="src/shared-module/App.vue" entry="src/shared-module" />

### Referencing Third-Party Libraries

Usually, third-party libraries (e.g., `motion-dom`) contain plain JavaScript functions. If called directly in a main thread function, they will report an error due to the missing `'main thread'` directive.

We can use `with { runtime: 'shared' }` to import them as shared modules:

```ts
// Import and use directly
import { animate } from 'motion-dom' with { runtime: 'shared' }

const onScroll = () => {
  'main thread'
  // Can be called directly in a main thread function
  animate(element, { opacity: 0 })
}
```

To facilitate reuse or avoid the [limitations](#limitations) below (e.g., losing the shared characteristic after assignment), we recommend **wrapping** the import in a main thread function:

```ts
// src/utils/motion.ts
// 1. Import the original function as shared
import { animate as _animate } from 'motion-dom' with { runtime: 'shared' }

// 2. Export a new main thread function for encapsulation
export function animate(...args) {
  'main thread'
  return _animate(...args)
}
```

In this way, `animate` becomes a standard main thread function that can be freely used in any main thread function, no longer restricted by static analysis:

```vue
<script setup lang="ts">
import { animate } from './utils/motion'

const onTap = () => {
  'main thread'
  // Standard main thread function — can be assigned or passed freely
  const myAnimate = animate
  myAnimate(element, { x: 100 })
}
</script>
```

### Limitations

Only identifiers directly imported via `import` are recognized as "shared". Assigning to a new variable will cause it to lose the shared characteristic:

```ts
import { func } from './utils' with { runtime: 'shared' }
const anotherFunc = func // [!code error]

const onTap = () => {
  'main thread'
  anotherFunc() // ❌ Cannot be analyzed at compile time, call fails
}
```

### State Isolation

**Variables and state in a shared module are completely isolated between the two threads, each possessing independent instances.**

This means that if you modify a variable in a shared module on the main thread, the background thread cannot perceive it, and vice versa. Shared modules solve the "code sharing" problem, not the "state sharing" problem.



---
url: /guide/pinia.md
---

# Using Pinia

[Pinia](https://pinia.vuejs.org/) is the official state management library for Vue. It provides a type-safe, extensible, and modular store with an intuitive API built on the Composition API.

See also: [Vue.js — State Management](https://vuejs.org/guide/scaling-up/state-management.html#pinia)

<Go example="pinia" defaultFile="src/App.vue" defaultEntryName="main" />

## Installation

```bash
npm install pinia
```

## Setup

Register Pinia with your vue-lynx app:

```ts title="src/index.ts"
import { createApp } from 'vue-lynx';
import { createPinia } from 'pinia';
import App from './App.vue';

const app = createApp(App);
app.use(createPinia());
app.mount();
```

## Defining a Store

Use `defineStore` with the [setup syntax](https://pinia.vuejs.org/core-concepts/#setup-stores) to create a store:

```ts title="src/stores/counter.ts"
import { ref, computed } from 'vue';
import { defineStore } from 'pinia';

export const useCounterStore = defineStore('counter', () => {
  const count = ref(0);
  const doubleCount = computed(() => count.value * 2);

  function increment() {
    count.value++;
  }

  return { count, doubleCount, increment };
});
```

## Using the Store in a Component

```vue title="src/CounterSection.vue"
<script setup lang="ts">
import { useCounterStore } from './stores/counter';

const counter = useCounterStore();
</script>

<template>
  <view>
    <text>Count: {{ counter.count }}</text>
    <text>Double: {{ counter.doubleCount }}</text>
    <text @tap="counter.increment">+1</text>
  </view>
</template>
```

See [Pinia — Core Concepts](https://pinia.vuejs.org/core-concepts/) for additional resources.



---
url: /guide/quick-start.md
---

import { PackageManagerTabs, Steps } from '@theme';

# Quick Start

Welcome to Vue Lynx! Let's create a Vue Lynx project and start developing.

## System Requirements

* [Node.js 18](https://nodejs.org/en) or later.
  * Requires Node.js 18.19 when using TypeScript as configuration.

## Start Developing

The quickest way to get started with Vue Lynx is to set up only the frontend project and preview with **Lynx Explorer** (for native) or **Lynx for Web** (for browser).

<Steps>
  ### Create a new Vue Lynx project

  We use [`create-vue-lynx`](https://npmjs.org/package/create-vue-lynx) to scaffold a new project:

  <PackageManagerTabs command="create vue-lynx@latest" />

  After completing the prompts, `create-vue-lynx` will create a folder with your project name containing a starter app.

  ### Run the dev server

  1. Navigate to the created project:

  ```bash
  cd <project-name>
  ```

  2. Install dependencies:

  <PackageManagerTabs command="install" />

  3. Start the development server:

  <PackageManagerTabs command="run dev" />

  You should see output like this:

  ```
  Rspeedy v0.13.5

  ➜  Web         http://localhost:3000/main.web.bundle
  ➜  Web Preview http://localhost:3000/__web_preview?casename=main.web.bundle
  ➜  Lynx        http://localhost:3000/main.lynx.bundle
  ```

  The dev server produces three URLs:

  * **Web Preview** — Open this in your browser for a quick preview of your app.
  * **Lynx** — The bundle URL for native rendering via Lynx Explorer (see next step).
  * **Web** — The raw web bundle (useful for integration into web containers).

  ### Preview on the Web

  Open the **Web Preview** URL in your browser. You'll see a live preview of your app rendered on the Web, updating automatically as you edit code.

  <Go example="hello-world" defaultFile="src/App.vue" defaultEntryFile="dist/main.lynx.bundle" />

  ### Preview on a native device

  To see your app rendered natively, use **Lynx Explorer**. Scan the QR code shown in the terminal, or copy the **Lynx** bundle URL and paste it into "Enter Card URL" in Lynx Explorer.

  #### iOS Simulator

  1. **Install Xcode** from the [Mac App Store](https://apps.apple.com/us/app/xcode/id497799835).

  2. **Download LynxExplorer**

     For Apple Silicon (M1/M2/M3), download [`LynxExplorer-arm64.app.tar.gz`](https://github.com/lynx-family/lynx/releases/latest/download/LynxExplorer-arm64.app.tar.gz), then extract:

     ```bash
     mkdir -p LynxExplorer-arm64.app/
     tar -zxf LynxExplorer-arm64.app.tar.gz -C LynxExplorer-arm64.app/
     ```

     For Intel Mac, download [`LynxExplorer-x86_64.app.tar.gz`](https://github.com/lynx-family/lynx/releases/latest/download/LynxExplorer-x86_64.app.tar.gz), then extract:

     ```bash
     mkdir -p LynxExplorer-x86_64.app/
     tar -zxf LynxExplorer-x86_64.app.tar.gz -C LynxExplorer-x86_64.app/
     ```

  3. **Install on Simulator** — Open Xcode, choose **Open Developer Tool** > **Simulator**, then drag the `.app` folder into it.

  #### Android

  Download the pre-built APK from [GitHub Releases](https://github.com/lynx-family/lynx/releases/latest/download/LynxExplorer-noasan-release.apk) and install on your device.

  :::info Community downloads

  Lynx Explorer is also available on the [App Store](https://apps.apple.com/us/app/lynx-go-dev-explorer/id6743227790) and [Play Store](https://play.google.com/store/apps/details?id=com.funcs.io.lynx.go), published by community contributors. These versions are not maintained by the Lynx team.

  :::

  :::details Build from source

  If the pre-built binaries don't work for your environment, you can build Lynx Explorer from source:

  * [Build for iOS](https://github.com/lynx-family/lynx/tree/develop/explorer/darwin/ios)
  * [Build for Android](https://github.com/lynx-family/lynx/tree/develop/explorer/android)

  :::

  ### Debugging

  Download the [Lynx DevTool](https://github.com/lynx-family/lynx-devtool/releases) desktop application. Connect your device via USB and start debugging. See the [Lynx debugging guide](https://lynxjs.org/guide/devtool/panels) to learn more.
</Steps>

## Going to Production

The Vue Lynx project you created is a **frontend** project — it produces JavaScript bundles that a Lynx-enabled native app loads and renders. Lynx Explorer is a pre-built native app for development, but for production you'll need your own native app.

### Start with Sparkling (Experimental)

[Sparkling](https://tiktok.github.io/sparkling) is TikTok's open-source infrastructure for building apps with Lynx. It provides CLI tools to scaffold a native app project with scheme-driven navigation in minutes. Currently **experimental** and supports **iOS and Android** only.

### Integrate into an existing app

For the most flexibility, you can integrate Lynx directly into your existing app. This approach supports **iOS, Android, Harmony, Desktop, and Web**, giving you full control over how Lynx is embedded within your application.

Follow the [Lynx integration guide](https://lynxjs.org/guide/start/integrate-with-existing-apps) to get started.

## Next Steps

* [What is Vue Lynx?](/guide/introduction.md) — Understand the architecture and key differences from Vue for Web
* [Tutorial: Product Gallery](/guide/tutorial-gallery.md) — Build a waterfall gallery with interactivity
* [Tutorial: Product Detail](/guide/tutorial-swiper.md) — Build a touch-swipeable image carousel



---
url: /guide/routing.md
---

import { PackageManagerTabs } from '@theme';

# Using Vue Router

Vue Lynx applications can use [Vue Router](https://router.vuejs.org/), the official routing library for Vue, to manage navigation between views. However, since Lynx has no browser `window.location` or History API, you must use [`createMemoryHistory()`](https://router.vuejs.org/api/index.html#creatememoryhistory) instead of `createWebHistory()` — similar to how React Router provides a `MemoryRouter` or TanStack Router provides a memory history for non-browser environments.

<Go example="vue-router" defaultFile="src/App.vue" defaultEntryName="main" />

## Installing Dependencies

<PackageManagerTabs command="install vue-router" />

## Creating the Router

Use `createMemoryHistory()` to create a history instance that keeps routing state entirely in-process, with no dependency on browser APIs:

```ts title="src/router.ts"
import { createRouter, createMemoryHistory } from 'vue-router';
import Home from './views/Home.vue';
import About from './views/About.vue';

const router = createRouter({
  history: createMemoryHistory(),
  routes: [
    { path: '/', name: 'home', component: Home },
    { path: '/about', name: 'about', component: About },
    { path: '/users', name: 'users', component: UserList },
    { path: '/users/:id', name: 'user-detail', component: UserDetail },
  ],
});

export default router;
```

Then install the router plugin and mount the app:

```ts title="src/index.ts"
import { createApp } from 'vue-lynx';
import router from './router';
import App from './App.vue';

const app = createApp(App);
app.use(router);
app.mount();
```

## Using `<RouterView>`

[`<RouterView>`](https://router.vuejs.org/api/index.html#RouterView) renders the component matched by the current route. It works in Lynx without any modifications:

```vue title="src/App.vue"
<script setup lang="ts">
import { RouterView } from 'vue-router';
</script>

<template>
  <view>
    <RouterView />
  </view>
</template>
```

## Navigating Without `<a>` Tags

In a browser, [`<RouterLink>`](https://router.vuejs.org/api/index.html#RouterLink) renders an `<a>` tag by default. Since Lynx has no `<a>` element, you have two options:

### Option 1: RouterLink with `custom` Slot

Use RouterLink's [`custom`](https://router.vuejs.org/api/index.html#RouterLink-Props) prop with the scoped slot API to render Lynx-native elements while retaining `isActive` state:

```vue title="src/NavLink.vue"
<script setup lang="ts">
import { RouterLink } from 'vue-router';

defineProps<{
  to: string;
  label: string;
}>();
</script>

<template>
  <RouterLink :to="to" custom v-slot="{ navigate, isActive }">
    <text
      @tap="navigate"
      :style="{
        color: isActive ? '#fff' : '#333',
        backgroundColor: isActive ? '#1a73e8' : '#e8e8e8',
        padding: '8px 12px',
        borderRadius: 16,
      }"
    >
      {{ label }}
    </text>
  </RouterLink>
</template>
```

### Option 2: Programmatic Navigation

Use the [`useRouter()`](https://router.vuejs.org/api/index.html#useRouter) composable for programmatic navigation:

```vue title="src/views/UserList.vue"
<script setup lang="ts">
import { useRouter } from 'vue-router';

const router = useRouter();

function goToUser(id: number) {
  router.push(`/users/${id}`);
}
</script>

<template>
  <view v-for="user in users" :key="user.id" @tap="goToUser(user.id)">
    <text>{{ user.name }}</text>
  </view>
</template>
```

You can also use `router.back()` and `router.replace()` as you normally would.

## Dynamic Route Params

Access dynamic route parameters via [`useRoute()`](https://router.vuejs.org/api/index.html#useRoute):

```vue title="src/views/UserDetail.vue"
<script setup lang="ts">
import { computed } from 'vue';
import { useRoute } from 'vue-router';

const route = useRoute();
const userId = computed(() => route.params.id as string);
</script>

<template>
  <view>
    <text>User ID: {{ userId }}</text>
  </view>
</template>
```

## Why Memory History?

| History mode | Requires browser APIs | Works in Lynx |
| --- | --- | --- |
| `createWebHistory()` | Yes (`window.location`, History API) | No |
| `createWebHashHistory()` | Yes (`window.location`) | No |
| `createMemoryHistory()` | No | **Yes** |

`createMemoryHistory()` is designed for environments without a browser — SSR, testing, and native runtimes like Lynx. The routing state is stored in a simple in-memory array, so features like `router.push()`, `router.back()`, and dynamic params all work as expected.



---
url: /guide/scroll-view-vs-list.md
---

# scroll-view vs list

Lynx does not scroll arbitrary nodes the way the Web does. When content overflows a viewport you pick an explicit scroll container — almost always [`<scroll-view>`](https://lynxjs.org/api/elements/built-in/scroll-view) or [`<list>`](https://lynxjs.org/api/elements/built-in/list). This guide explains how Lynx documents the difference, how that differs from Web Vue, and the Vue Lynx patterns that fall out of those choices.

For the platform reference, see [Managing Scrolling](https://lynxjs.org/guide/ui/scrolling) on lynxjs.org.

## Lynx vs Web

On the Web, almost any element can become a scrollport:

```html
<div style="overflow: auto; height: 100vh">
  <!-- anything -->
</div>
```

On Lynx, a plain `<view>` **does not** gain scrolling from `overflow: scroll` / `overflow: auto`. Only dedicated containers such as `<scroll-view>` and `<list>` scroll. That is the first design shift when you move a Vue app from DOM to Lynx: scrolling becomes a **structural** decision in the template, not a CSS property you sprinkle later.

| | Web (Vue) | Lynx (Vue Lynx) |
|---|---|---|
| How scrolling starts | `overflow` on any node | Dedicated `<scroll-view>` / `<list>` |
| Virtualization | Optional library (`vue-virtual-scroller`, Virtua, …) | Built into `<list>` |
| Large feeds | You own windowing + recycled DOM | Native recycling + lazy create |
| Complex grids | CSS Grid / masonry libs | `<list list-type="flow\|waterfall">` |

Vue Lynx keeps Composition API, `v-for`, and SFCs — but your scroll trees look different from a typical Nuxt / Vite SPA.

## What lynxjs.org says

Lynx's scrolling guide draws a clean line between the two containers:

1. **`<scroll-view>` for basic scrolling** — a fixed viewport; when children exceed it, set `scroll-orientation` to `vertical` or `horizontal`.
2. **`<list>` for large / infinite data** — on-demand creation of visible items only.
3. **`<list>` for complex layouts** — `scroll-view` is linear only; `list` adds `single`, `flow`, and `waterfall`.

The [`<scroll-view>` API](https://lynxjs.org/api/elements/built-in/scroll-view) also warns:

* Every child is created up front (can hurt first paint).
* There is **no reuse**; too much content can exhaust memory.
* Prefer `<list>` once content exceeds roughly **three screens**, or fake recycling with exposure events.

Think of `<scroll-view>` as “a short page that happens to scroll,” and `<list>` as “a recycling feed.”

## Choose with a table

| Question | Prefer `<scroll-view>` | Prefer `<list>` |
|---|---|---|
| How much content? | A few screens or less | Many screens / unbounded |
| Layout | Linear stack | Single / grid (`flow`) / waterfall |
| Item shape | Mixed sections, sticky chrome | Homogeneous (or mostly) cells |
| Memory | Eager, all children live | Recycled + lazy |
| Infinite load | Possible, but risky | Native `@scrolltolower` |

Rule of thumb from Lynx: **under ~3 screens → `scroll-view`; beyond that → `list`.**

## `<scroll-view>` in Vue

Use ordinary Vue children — `v-for`, nested SFCs, sticky siblings. Nothing special is required beyond wrapping them in `<scroll-view>`.

<Go example="scrolling" defaultFile="src/ScrollViewBasic/App.vue" entry="src/ScrollViewBasic" defaultEntryName="ScrollViewBasic" />

```vue
<scroll-view scroll-orientation="vertical">
  <view class="header">…</view>
  <view v-for="card in cards" :key="card.id" class="card">
    <text>{{ card.title }}</text>
  </view>
</scroll-view>
```

Good fits: settings screens, forms, article bodies, short result pages (see also the [Vue Query](/guide/data-fetching.md) and [TodoMVC](/guide/todomvc.md) examples).

:::tip Nested layout tip
Direct children of `<scroll-view>` only support linear / sticky layout. For richer CSS inside the scrollport, wrap content in a single child `<view>` and style that subtree — as recommended in the [scroll-view docs](https://lynxjs.org/api/elements/built-in/scroll-view).
:::

## `<list>` in Vue

`<list>` expects **`<list-item>` children**. Each item needs:

* Vue's `:key` — reconciliation identity for the VNode tree
* Lynx's `:item-key` — identity for the native recycler (keep them equal)

Missing or colliding keys is a common cause of blank / wrong cells.

<Go example="scrolling" defaultFile="src/ListBasic/App.vue" entry="src/ListBasic" defaultEntryName="ListBasic" />

```vue
<list list-type="single" scroll-orientation="vertical">
  <list-item
    v-for="card in cards"
    :key="card.id"
    :item-key="card.id"
    :estimated-main-axis-size-px="96"
  >
    <view class="card">…</view>
  </list-item>
</list>
```

`estimated-main-axis-size-px` helps the engine size the scrollbar and jump before a cell has been measured — the [gallery tutorial](/guide/tutorial-gallery.md) relies on the same hint for waterfall images.

### Waterfall / flow layouts

This is the other half of the lynxjs.org distinction: `scroll-view` cannot do multi-column masonry; `list` can.

<Go example="scrolling" defaultFile="src/ListWaterfall/App.vue" entry="src/ListWaterfall" defaultEntryName="ListWaterfall" />

```vue
<list list-type="waterfall" :span-count="2" scroll-orientation="vertical">
  <list-item
    v-for="tile in tiles"
    :key="tile.id"
    :item-key="tile.id"
    :estimated-main-axis-size-px="tile.height"
  >
    <view class="tile" :style="{ height: `${tile.height}px` }" />
  </list-item>
</list>
```

Each `list-item` can host a full Vue SFC — the gallery tutorial's `LikeImageCard` is the same pattern at product scale.

## Vue design patterns that fall out of this

Moving from Web Vue to Vue Lynx does not change reactivity — it changes **where** you put scrolling and **who** owns recycling.

### 1. Explicit containers in the template

Stop reaching for `overflow: auto` on a root `<view>`. Decide up front:

```vue
<!-- short, mixed page -->
<scroll-view scroll-orientation="vertical">…</scroll-view>

<!-- long homogeneous feed -->
<list list-type="single" scroll-orientation="vertical">…</list>
```

That structural choice is the Lynx equivalent of picking a layout library on the Web.

### 2. Dual identity: `:key` + `:item-key`

Web `v-for` only needs `:key`. Lynx lists need both. Treat them as one stable business id:

```vue
<list-item
  v-for="status in items"
  :key="status.id"
  :item-key="status.id"
/>
```

The [Elk](/guide/elk.md) port follows exactly this contract for Mastodon statuses.

### 3. Composable owns pages; `<list>` owns recycling

On the Web, infinite feeds usually mean:

`useInfiniteQuery` / custom composable **+** a virtualizer **+** an intersection sentinel.

On Lynx, drop the virtualizer. A composable appends to a `ref` array; `@scrolltolower` (and `lower-threshold-item-count`) asks for the next page. Native recycling keeps memory flat.

<Go example="scrolling" defaultFile="src/ListInfinite/App.vue" entry="src/ListInfinite" defaultEntryName="ListInfinite" />

```ts
// shared/useInfiniteFeed.ts
export function useInfiniteFeed(pageSize = 20) {
  const items = ref(makeCards(pageSize))
  const loading = ref(false)
  // loadMore() appends another page…
  return { items, loading, loadMore }
}
```

```vue
<list
  :lower-threshold-item-count="3"
  @scrolltolower="loadMore"
>
  <list-item
    v-for="item in items"
    :key="item.id"
    :item-key="item.id"
  >
    …
  </list-item>
</list>
```

This is the same shape as Elk's `TimelinePaginator`: masto.js pagination in a composable, `<list>` for the viewport.

:::tip List diffs
Vue Lynx's Main Thread list adapter flushes `insertAction` / `removeAction` / `updateAction` by diffing the last-flushed snapshot against the live `listItems` array (LIS move detection, same idea as ReactLynx's remove+insert moves). Covers append, prepend, mid-list insert, remove, same-list reorder, and platform-info updates. Still open: framework-side cell recycling and refreshing `__UpdateListCallbacks` each flush — [#302](https://github.com/Huxpro/vue-lynx/issues/302), [#303](https://github.com/Huxpro/vue-lynx/issues/303).
:::

### 4. Prefer `list` over third-party virtual scrollers

Libraries that measure DOM nodes (`getBoundingClientRect`, absolute positioning of windows) do not map cleanly onto Lynx's dual-thread + native elements model. Prefer the built-in recycler unless you have a rare layout `<list>` cannot express.

### 5. Keep cells as Vue components

Recycling is a **native** concern; composition stays a **Vue** concern. Put presentational SFCs inside `list-item` — do not flatten everything into one mega-template just because the parent is a list.

```vue
<list-item :key="pic.id" :item-key="pic.id">
  <LikeImageCard :picture="pic" />
</list-item>
```

## Mutation demos

| Entry | Mutation | Status |
|---|---|---|
| `ListPrepend` | unshift vs append | Fixed — INSERT respects anchor |
| `ListReorder` | Yellow→top / reverse | Fixed — same-list move = detach + insert |
| `ListRemove` | splice + Reset same keys | Fixed — `removeAction` (was 2202) |
| `ListFilter` | even-only toggle | OK |

### Prepend

Tap **Prepend** once. The TOP list cell must turn red (`NEW …`). **Append** lands at the bottom.

<Go example="scrolling" defaultFile="src/ListPrepend/App.vue" entry="src/ListPrepend" defaultEntryName="ListPrepend" />

### Reorder

Four full-bleed colors. The top strip is plain `<view>`s (Vue truth). The `<list>` below must show the **same order** after **Yellow → top** or **Reverse**.

<Go example="scrolling" defaultFile="src/ListReorder/App.vue" entry="src/ListReorder" defaultEntryName="ListReorder" />

### Remove + filter

**Remove**: delete rows, then **Reset same keys** — must not toast duplicated item-key (2202). Filter toggle is a lighter regression tap.

<Go example="scrolling" defaultFile="src/ListRemove/App.vue" entry="src/ListRemove" defaultEntryName="ListRemove" />

<Go example="scrolling" defaultFile="src/ListFilter/App.vue" entry="src/ListFilter" defaultEntryName="ListFilter" />

### Still open

* Framework-side cell recycling (`enqueueComponent` / recycle pool) — [#302](https://github.com/Huxpro/vue-lynx/issues/302)
* Refreshing `__UpdateListCallbacks` on every list flush — [#303](https://github.com/Huxpro/vue-lynx/issues/303)

Automated coverage: `packages/testing-library` → **native list element · mutations**.

## Decision checklist

1. Is the page mostly one linear document under ~3 screens? → **`<scroll-view>`**
2. Are you rendering dozens / hundreds of similar rows? → **`<list>`**
3. Do you need waterfall or multi-column flow? → **`<list list-type="…">`**
4. Will the dataset grow without bound? → **`<list>` + composable + `@scrolltolower`**
5. Did you set matching `:key` / `:item-key`? → required for correct recycling
6. Prepend / reorder / remove? → supported via `update-list-info` diffs

## See also

* [Managing Scrolling (Lynx)](https://lynxjs.org/guide/ui/scrolling)
* [`<scroll-view>` API](https://lynxjs.org/api/elements/built-in/scroll-view)
* [`<list>` API](https://lynxjs.org/api/elements/built-in/list)
* [Tutorial: Product Gallery](/guide/tutorial-gallery.md) — waterfall `<list>` in a full app
* [Elk (Mastodon Client)](/guide/elk.md) — replacing Virtua with native `<list>`
* [Main Thread Script](/guide/main-thread-script.md) — scroll-linked worklets on `<scroll-view>` / `<list>`



---
url: /guide/showcase-scale.md
---

# Showcase scale compare

Internal check: does live web at `fit` @ 360×804 match the density of the
original homepage showcase videos (1080×2412 = 360×804 CSS-px @3×)?

Left = recording (`object-fit: cover`). Right = `<Go mode="preview"
webPreviewMode="fit">` into the same bezel. Typography / card sizes should
line up; if the live side looks much larger, the design canvas is too small
(or we fell back to responsive layout at bezel CSS pixels).

<ScaleCompare />



---
url: /guide/tailwindcss.md
---

# Using Tailwind CSS

[Tailwind CSS](https://tailwindcss.com/) is a utility-first CSS framework. Combined with Vue Lynx, it lets you build native Lynx UIs using the same utility classes you already know from the web.

This guide walks through integrating Tailwind CSS with Vue Lynx, from basic setup to a design-token system with runtime theme switching — inspired by [shadcn/ui](https://ui.shadcn.com/).

<Go example="tailwindcss" defaultFile="src/App.vue" />

## Setup

### 1. Install dependencies

```bash
pnpm add -D tailwindcss@3 @lynx-js/tailwind-preset rsbuild-plugin-tailwindcss
```

:::tip Tailwind v3 Required
`@lynx-js/tailwind-preset` and `rsbuild-plugin-tailwindcss` require **Tailwind CSS v3**. Tailwind v4 uses a completely different architecture and is not yet supported. Make sure you do **not** have `@tailwindcss/postcss` or `@tailwindcss/vite` installed — those are v4-only packages that conflict with the v3 setup.
:::

* **`@lynx-js/tailwind-preset`** — A Tailwind preset that replaces core plugins with Lynx-compatible equivalents. See the [official Rspeedy docs](https://lynxjs.org/rspeedy/styling.html#using-tailwind-css) for details.
* **`rsbuild-plugin-tailwindcss`** — Rsbuild integration for Tailwind CSS.

### 2. Configure Tailwind

```ts title="tailwind.config.ts"
import type { Config } from 'tailwindcss';
import preset from '@lynx-js/tailwind-preset';

const config: Config = {
  content: ['./src/**/*.{vue,js,ts}'],
  presets: [preset],
};

export default config;
```

### 3. Configure PostCSS

```js title="postcss.config.js"
export default {
  plugins: {
    tailwindcss: {},
  },
};
```

### 4. Add the Rsbuild plugin

```ts title="lynx.config.ts"
import { defineConfig } from '@lynx-js/rspeedy';
import { pluginTailwindCSS } from 'rsbuild-plugin-tailwindcss';
import { pluginVueLynx } from 'vue-lynx/plugin';

export default defineConfig({
  plugins: [
    pluginVueLynx(),
    pluginTailwindCSS({
      config: 'tailwind.config.ts',
      exclude: [/[\\/]node_modules[\\/]/],
    }),
  ],
});
```

### 5. Import Tailwind in your CSS

```css title="src/App.css"
@tailwind base;
@tailwind utilities;
```

That's it! You can now use Tailwind utility classes on Lynx elements:

```vue title="src/App.vue"
<template>
  <view class="p-4 flex flex-col gap-2">
    <text class="text-blue-500 text-lg font-bold">Hello, Tailwind!</text>
    <view class="bg-gray-800 rounded-lg p-3">
      <text class="text-white text-sm">A card with utility classes.</text>
    </view>
  </view>
</template>
```

## Design Tokens with CSS Variables

A common pattern in modern component libraries (shadcn/ui, Radix Themes, Nuxt UI) is to define a **design language** as CSS custom properties, then reference them from Tailwind. This gives you a single source of truth for colors that can be swapped at runtime.

### Define your tokens

```css title="src/App.css"
@tailwind base;
@tailwind utilities;

:root {
  --color-background: rgba(9, 9, 11, 1);
  --color-card: rgba(24, 24, 27, 1);
  --color-card-foreground: rgba(250, 250, 250, 1);
  --color-primary: rgba(255, 100, 72, 1);
  --color-primary-foreground: rgba(255, 255, 255, 1);
  --color-border: rgba(63, 63, 70, 1);
}
```

### Wire them into Tailwind

```ts title="tailwind.config.ts"
const config: Config = {
  // ...
  theme: {
    extend: {
      colors: {
        background: 'var(--color-background)',
        card: {
          DEFAULT: 'var(--color-card)',
          foreground: 'var(--color-card-foreground)',
        },
        primary: {
          DEFAULT: 'var(--color-primary)',
          foreground: 'var(--color-primary-foreground)',
        },
        border: 'var(--color-border)',
      },
    },
  },
};
```

Now `bg-primary`, `text-card-foreground`, `border-border` all resolve through your CSS variables. The `:root` values act as the default theme.

### Required Lynx flags

For CSS variables to work on Lynx Native, two engine flags must be enabled:

* **`enableCSSInheritance`** — Enables CSS cascade from parent elements to children, so variables defined on a parent (or `:root`) are visible to descendants. See the [Lynx CSS Variable docs](https://lynxjs.org/api/css/properties/css-variable.html).
* **`enableCSSInlineVariables`** — Enables `--*` properties in inline styles, so `:style` bindings can set CSS variables at runtime.

```ts title="lynx.config.ts"
pluginVueLynx({
  enableCSSInheritance: true,
  enableCSSInlineVariables: true,
})
```

> These flags are **only needed when using CSS variables**. If your Tailwind config uses static color values (e.g. `primary: '#3b82f6'`), no additional flags are required.

## Runtime Theme Switching

With design tokens wired through CSS variables, switching themes is just a matter of overriding the variable values.

### Approach A: Inline style (recommended)

The most web-familiar approach — set CSS variables via Vue's `:style` binding on a root element. This is how shadcn/ui and Radix Themes handle theming on the web.

Requires both `enableCSSInheritance` and `enableCSSInlineVariables`.

```vue
<script setup>
import { ref, computed } from 'vue-lynx'

const themes = {
  dark: {
    '--color-background': 'rgba(9, 9, 11, 1)',
    '--color-primary': 'rgba(255, 100, 72, 1)',
    // ...
  },
  light: {
    '--color-background': 'rgba(255, 255, 255, 1)',
    '--color-primary': 'rgba(234, 88, 12, 1)',
    // ...
  },
}

const currentTheme = ref('dark')
const themeStyle = computed(() => themes[currentTheme.value])
</script>

<template>
  <scroll-view :style="themeStyle" class="bg-background">
    <text class="text-primary">Themed text</text>
    <view @tap="currentTheme = 'light'">
      <text>Switch to Light</text>
    </view>
  </scroll-view>
</template>
```

### Approach B: Element `setProperty` API

A Lynx-native alternative that updates CSS variables directly on an element. Does **not** require `enableCSSInlineVariables` — only `enableCSSInheritance`.

```vue
<script setup>
import { ref } from 'vue-lynx'

const root = ref(null)

function switchTheme(name) {
  const vars = themes[name]
  root.value?.setProperty(vars)
}
</script>

<template>
  <scroll-view ref="root" class="bg-background">
    <text class="text-primary">Themed text</text>
    <view @tap="switchTheme('light')">
      <text>Switch to Light</text>
    </view>
  </scroll-view>
</template>
```

See the [Lynx CSS Variable API](https://lynxjs.org/api/css/properties/css-variable.html) for full details on `setProperty`.

## Troubleshooting

### New Tailwind classes don't appear on HMR

**Symptom:** You change e.g. `bg-slate-800` to `bg-red-500`, save, but the emulator doesn't update. Switching *back* to a previously-used class works, but new classes don't show up until you restart the dev server.

**Cause:** Tailwind v3's JIT compiler generates CSS only for the utility classes it finds in your source files. When a file changes, JIT must re-scan it and generate any newly-referenced classes. If the PostCSS pipeline is misconfigured, this re-scan doesn't trigger on HMR, so only classes that were already in the initial bundle work.

The most common cause is **mixing Tailwind v3 and v4 packages**:

| Package | Version | What it is |
|---------|---------|------------|
| `tailwindcss` | 3.x | Tailwind v3 core (also the PostCSS plugin) |
| `@tailwindcss/postcss` | 4.x | Tailwind **v4** PostCSS plugin -- **incompatible with v3** |

These two cannot coexist. The Lynx ecosystem (`@lynx-js/tailwind-preset`, `rsbuild-plugin-tailwindcss`) requires **Tailwind v3**.

**Fix:** Remove the v4 package and any extra PostCSS dependencies:

```bash
pnpm remove @tailwindcss/postcss autoprefixer
```

Then follow the [setup steps above](#1-install-dependencies). Make sure your `postcss.config.js` uses `tailwindcss` (the v3 plugin), **not** `@tailwindcss/postcss`.

### `content` path doesn't match your source files

If Tailwind classes work in some files but not others, check that the `content` array in `tailwind.config.ts` includes all relevant paths:

```ts
content: ['./src/**/*.{vue,js,ts}'],
```

Adjust the glob if your source files live elsewhere (e.g. `pages/`, `components/`).



---
url: /guide/testing-library.md
---

import { PackageManagerTabs } from '@theme';

# VueLynx Testing Library

The `vue-lynx-testing-library` package offers APIs like `render`, `fireEvent`, and `getByText` for testing Vue Lynx components, similar to [Vue Test Utils](https://test-utils.vuejs.org/) and [React Testing Library](https://testing-library.com/), with the dual-threaded architecture abstracted through [`@lynx-js/testing-environment`](https://www.npmjs.com/package/@lynx-js/testing-environment).

## Setup

### From create-vue-lynx

Using `create-vue-lynx` sets up VueLynx Testing Library automatically, providing pre-configured testing support.

### Adding to an existing project

Install the required dependencies:

<PackageManagerTabs command="add -D vitest jsdom @lynx-js/testing-environment @testing-library/dom @testing-library/jest-dom" />

For Vitest configuration, create a `vitest.config.ts` that aliases `vue-lynx` subpaths and registers the setup file:

```ts title="vitest.config.ts"
import { defineConfig } from 'vitest/config';
import path from 'node:path';

export default defineConfig({
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: [path.resolve(__dirname, 'test/setup.ts')],
    include: ['test/**/*.test.ts'],
    alias: [
      {
        find: 'vue-lynx/entry-background',
        replacement: path.resolve(
          __dirname,
          'node_modules/vue-lynx/runtime/dist/entry-background.js',
        ),
      },
      {
        find: 'vue-lynx/main-thread',
        replacement: path.resolve(
          __dirname,
          'node_modules/vue-lynx/main-thread/dist/entry-main.js',
        ),
      },
      {
        find: 'vue-lynx/internal/ops',
        replacement: path.resolve(
          __dirname,
          'node_modules/vue-lynx/internal/dist/ops.js',
        ),
      },
      {
        find: /^vue-lynx$/,
        replacement: path.resolve(
          __dirname,
          'node_modules/vue-lynx/runtime/dist/index.js',
        ),
      },
    ],
  },
});
```

Create a setup file that initializes the dual-thread testing environment. This runs before any test module is imported, so all Lynx globals are in place when Vue's runtime loads:

```ts title="test/setup.ts"
import { JSDOM } from 'jsdom';
import { LynxTestingEnv } from '@lynx-js/testing-environment';

// Create the testing environment
const jsdom = new JSDOM('<!DOCTYPE html><html><body></body></html>');
const lynxTestingEnv = new LynxTestingEnv(jsdom);
(globalThis as any).lynxTestingEnv = lynxTestingEnv;

// Wire Main Thread globals
lynxTestingEnv.switchToMainThread();
if (typeof (globalThis as any).registerWorkletInternal === 'undefined') {
  (globalThis as any).registerWorkletInternal = () => {};
}
await import('vue-lynx/main-thread');

const mainThreadFns = {
  renderPage: (globalThis as any).renderPage,
  vuePatchUpdate: (globalThis as any).vuePatchUpdate,
  processData: (globalThis as any).processData,
  updatePage: (globalThis as any).updatePage,
  updateGlobalProps: (globalThis as any).updateGlobalProps,
};
const mtGlobal = lynxTestingEnv.mainThread.globalThis as any;
Object.assign(mtGlobal, mainThreadFns);

// Wire Background Thread globals
lynxTestingEnv.switchToBackgroundThread();
await import('vue-lynx/entry-background');

const publishEventFn = (globalThis as any).publishEvent;
const bgGlobal = lynxTestingEnv.backgroundThread.globalThis as any;
bgGlobal.publishEvent = publishEventFn;

// Re-wire globals after env resets between tests
(globalThis as any).onSwitchedToMainThread = () => {
  Object.assign(globalThis, mainThreadFns);
};
(globalThis as any).onSwitchedToBackgroundThread = () => {
  if ((globalThis as any).lynxCoreInject?.tt) {
    (globalThis as any).lynxCoreInject.tt.publishEvent = publishEventFn;
  }
  (globalThis as any).publishEvent = publishEventFn;
};
```

## Examples

### Quick Start

Follow the **Arrange-Act-Assert** pattern: prepare test data, perform operations, then assert results:

```ts
import { expect, it, vi } from 'vitest';
import { h, defineComponent } from 'vue-lynx';
import { render, fireEvent } from 'vue-lynx-testing-library';

it('basic', async () => {
  const onClick = vi.fn();

  const Button = defineComponent({
    props: { onClick: Function },
    setup(props, { slots }) {
      return () => h('view', { bindtap: props.onClick }, slots.default?.());
    },
  });

  // ARRANGE
  const { container } = render(
    defineComponent({
      setup() {
        return () =>
          h(Button, { onClick }, () => [
            h('text', null, 'Click me'),
          ]);
      },
    }),
  );

  expect(onClick).not.toHaveBeenCalled();

  // ACT
  fireEvent.tap(container.querySelector('view')!);

  // ASSERT
  expect(onClick).toBeCalledTimes(1);
  expect(container.querySelector('text')!.textContent).toBe('Click me');
});
```

VueLynx Testing Library uses JSDOM to implement [Element PAPI](https://lynxjs.org/guide/spec.html), so you can query rendered elements with `container.querySelector()` and assert their `textContent`.

:::tip
When passing slot content to a component with `h()`, wrap children in a function: `h(Comp, props, () => [children])`. This follows Vue 3's recommended function slot pattern.
:::

### Basic rendering

The `render` method returns a `RenderResult` object with a `container` field containing the rendered result:

```ts
import { expect, it } from 'vitest';
import { h, defineComponent } from 'vue-lynx';
import { render } from 'vue-lynx-testing-library';

it('basic render', () => {
  const Comp = defineComponent({
    render() {
      return h('view', { id: 'inner', style: { backgroundColor: 'yellow' } });
    },
  });

  const { container } = render(Comp);
  expect(container.querySelector('#inner')).not.toBeNull();
  expect(container.querySelector('view')).not.toBeNull();
});
```

You can also use the `@testing-library/dom` queries bound to the container:

```ts
const { getByText } = render(Comp);
expect(getByText('Hello')).not.toBeNull();
```

### Firing events

When using `fireEvent`, the event type is determined by the handler property name on the element. The format follows `eventType:eventName` (e.g., `catchEvent:tap` triggers a catch-type tap event). Event handler properties determine the event type:

| Event Type | `eventType` | Binding Example | Triggering Example |
|---|---|---|---|
| `bind` | `bindEvent` | `bindtap` | `fireEvent.tap(el)` |
| `catch` | `catchEvent` | `catchtap` | `fireEvent.tap(el, { eventType: 'catchEvent' })` |
| `capture-bind` | `capture-bind` | `capture-bindtap` | `fireEvent.tap(el, { eventType: 'capture-bind' })` |
| `capture-catch` | `capture-catch` | `capture-catchtap` | `fireEvent.tap(el, { eventType: 'capture-catch' })` |

You can construct Event objects directly or use the named helpers for automatic construction:

```ts
import { h, defineComponent } from 'vue-lynx';
import { render, fireEvent } from 'vue-lynx-testing-library';
import { vi, expect, it } from 'vitest';

it('fireEvent', async () => {
  const handler = vi.fn();

  const Comp = defineComponent({
    setup() {
      return () => h('view', null, [h('text', { catchtap: handler })]);
    },
  });

  const { container } = render(Comp);
  const textEl = container.querySelector('text')!;

  expect(handler).toHaveBeenCalledTimes(0);

  // Method 1: Use the named helper
  fireEvent.tap(textEl, {
    eventType: 'catchEvent',
    key: 'value',
  });

  expect(handler).toHaveBeenCalledTimes(1);

  // Method 2: Construct the Event object yourself
  const event = new Event('catchEvent:tap');
  Object.assign(event, {
    eventType: 'catchEvent',
    eventName: 'tap',
    key: 'value2',
  });
  fireEvent(textEl, event);

  expect(handler).toHaveBeenCalledTimes(2);
});
```

The following event helpers are available:

| Helper | Event Name |
|---|---|
| `fireEvent.tap(el)` | `tap` |
| `fireEvent.longtap(el)` | `longtap` |
| `fireEvent.longpress(el)` | `longpress` |
| `fireEvent.touchstart(el)` | `touchstart` |
| `fireEvent.touchmove(el)` | `touchmove` |
| `fireEvent.touchend(el)` | `touchend` |
| `fireEvent.touchcancel(el)` | `touchcancel` |
| `fireEvent.scroll(el)` | `scroll` |
| `fireEvent.scrollend(el)` | `scrollend` |
| `fireEvent.focus(el)` | `focus` |
| `fireEvent.blur(el)` | `blur` |
| `fireEvent.layoutchange(el)` | `layoutchange` |
| `fireEvent.transitionend(el)` | `transitionend` |
| `fireEvent.animationend(el)` | `animationend` |

### Testing reactivity

After changing reactive state, use `await nextTick(); await nextTick()` to wait for Vue's scheduler to flush and for the ops to be applied on the main thread. The convenience helper `waitForUpdate()` wraps both calls:

```ts
import { h, defineComponent, ref } from 'vue-lynx';
import { render, waitForUpdate } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('updates text when ref changes', async () => {
  const count = ref(0);

  const Comp = defineComponent({
    setup() {
      return () => h('text', null, `Count: ${count.value}`);
    },
  });

  const { container } = render(Comp);
  expect(container.querySelector('text')!.textContent).toBe('Count: 0');

  count.value = 42;
  await waitForUpdate();

  expect(container.querySelector('text')!.textContent).toBe('Count: 42');
});
```

### Testing template refs

Vue Lynx sets a `vue-ref-{id}` attribute on elements, which can be used to verify ref assignment. The `ShadowElement` (background thread representation) provides `NodesRef` methods like `invoke`, `setNativeProps`, and `animate`:

```ts
import { h, defineComponent, ShadowElement } from 'vue-lynx';
import { render } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('element ref', () => {
  const Comp = defineComponent({
    render() {
      return h('view', null, [h('text', null, 'hello')]);
    },
  });

  const { container } = render(Comp);
  const view = container.querySelector('view')!;

  // Vue Lynx sets vue-ref-{id} attribute for elements
  expect(view.hasAttribute('vue-ref-2')).toBe(true);
});

it('ShadowElement has NodesRef methods', () => {
  const el = new ShadowElement('view');
  expect(typeof el.invoke).toBe('function');
  expect(typeof el.setNativeProps).toBe('function');
  expect(typeof el.animate).toBe('function');
});
```

### Querying page elements

The `render` method returns `@testing-library/dom` query methods bound to the container, such as `getByText`:

```ts
import { h, defineComponent, ref } from 'vue-lynx';
import { render, waitForUpdate } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('queries rendered elements', async () => {
  const loaded = ref(false);

  const Comp = defineComponent({
    setup() {
      return () =>
        loaded.value
          ? h('text', { id: 'message' }, 'Hello World')
          : h('text', null, 'Loading...');
    },
  });

  const { container, getByText } = render(Comp);
  expect(getByText('Loading...')).not.toBeNull();

  loaded.value = true;
  await waitForUpdate();

  expect(container.querySelector('#message')!.textContent).toBe('Hello World');
});
```

### Rerendering

The `render` method returns an object with a `rerender` method for testing different component states:

```ts
import { h, defineComponent } from 'vue-lynx';
import { render } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('rerender will re-render your component', () => {
  const Greeting = defineComponent({
    props: { message: String },
    render() {
      return h('text', null, this.message);
    },
  });

  const { container, rerender } = render(Greeting, { message: 'hi' });
  expect(container.querySelector('text')!.textContent).toBe('hi');

  {
    const { container } = rerender(Greeting, { message: 'hey' });
    expect(container.querySelector('text')!.textContent).toBe('hey');
  }
});
```

### Testing list

The `list` element renders `list-item` children. Items are described declaratively and the native list handles lazy loading:

```ts
import { h, defineComponent, ref } from 'vue-lynx';
import { render, waitForUpdate } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('list', async () => {
  const items = ref([0, 1, 2]);

  const Comp = defineComponent({
    setup() {
      return () =>
        h(
          'list',
          null,
          items.value.map((item) =>
            h('list-item', { key: item, 'item-key': item }, [
              h('text', null, `${item}`),
            ]),
          ),
        );
    },
  });

  const { container } = render(Comp);
  const list = container.querySelector('list');
  expect(list).not.toBeNull();

  // Add items reactively
  items.value = [0, 1, 2, 3];
  await waitForUpdate();

  expect(container.querySelector('list')).not.toBeNull();
});
```

### Testing Main Thread Script

Main Thread Script testing requires no special configuration. Note that background thread methods cannot be called directly from main thread scripts; place callback functions on `globalThis` for assertion:

```ts
import { h, defineComponent } from 'vue-lynx';
import { render } from 'vue-lynx-testing-library';
import { expect, it } from 'vitest';

it('main thread script', () => {
  const Comp = defineComponent({
    setup() {
      return () =>
        h('view', {
          'main-thread-bindtap': {
            _wkltId: 1,
            _closure: {},
          },
        }, [
          h('text', null, 'Hello Main Thread Script'),
        ]);
    },
  });

  const { container } = render(Comp);
  expect(container.querySelector('text')!.textContent).toBe('Hello Main Thread Script');
});
```

:::info
In production, `'main thread'` directive functions are transformed by the build plugin into worklet context objects (*worklet* is the Lynx engine's internal term for a compiled Main Thread Script function). In tests, you can pass the worklet context directly as shown above, or use the SWC transform if your Vitest config includes the worklet loader.
:::

### More usage

For additional examples, see the test cases in the [vue-lynx testing-library source code](https://github.com/Huxpro/vue-lynx/tree/main/packages/testing-library/src/__tests__).

## API Reference

See the full [vue-lynx/testing-library API Reference](/guide/api/testing-library/index.md) for details on `render`, `fireEvent`, `cleanup`, `waitForUpdate`, and other exports.



---
url: /guide/todomvc.md
---

# TodoMVC

[TodoMVC](https://github.com/tastejs/todomvc/tree/gh-pages/examples/vue) is the canonical benchmark for comparing JavaScript frameworks. We ported it as our first validation target to verify whether we can fully reuse the Vue 3 core and implement a dual-thread rendering pipeline on top of the Custom Renderer API to connect with Lynx's native engine.

<Go example="todomvc" defaultFile="src/TodoApp.vue" />

## Overview of Changes

Most business logic transferred directly — Composition API (`ref`, `computed`, `watch`), component patterns, and template directives work identically. Here's what we changed:

| Aspect | Original (Web) | Vue Lynx |
|--------|----------------|----------|
| **Template elements** | `<div>`, `<li>`, `<button>`, `<label>` | `<view>`, `<text>`, `<input>`, `<scroll-view>` |
| **Events** | `@click`, `@keyup.enter` | `@tap`, `@confirm` |
| **Checkbox** | `<input type="checkbox">` | `<view>` + `@tap` (no native checkbox in Lynx) |
| **Vue Router** | 3 filter routes | `ref('all')` (not needed) |
| **CSS** | `todomvc-app-css` package | Custom `todomvc.css` (no pseudo-elements in Lynx) |

## How Much of Vue Do We Reuse?

The table below reflects our initial prototype — the minimum custom code needed to get TodoMVC running on Lynx. The actual codebase has grown since then, but the reuse ratio remains similar: the vast majority of Vue's runtime is used as-is.

| Layer | Source | Reuse |
|-------|--------|-------|
| **Reactivity** | `@vue/reactivity` | 100% official |
| **Component system** | `@vue/runtime-core` | 100% official |
| **Template compiler** | `@vue/compiler-dom` + `@rsbuild/plugin-vue` | 100% official |
| **Dual-threaded renderer** | `vue-lynx/runtime`, `vue-lynx/main-thread` | Custom (~900 LOC) |
| **Bundler Plugin** | `vue-lynx/plugin` | Custom (~360 LOC) |

With just over **1,000 lines of code**, we were able to run TodoMVC. This validated that building a dual-thread rendering pipeline on top of the Vue 3 Custom Renderer API to connect with Lynx's native engine is a viable approach.



---
url: /guide/touch-fx.md
---

# Playground: Touch FX

A black stage, a glowing green orb, and your finger. Poke it, drag it, flick it — it reacts like a cat toy:

* **The orb chases your finger** with a damped spring, squashing & stretching along its velocity vector. Let go and it wobbles to a stop right where you left it.
* **Water ripples** pulse continuously under your finger for the *entire* drag — a fresh ring every ~150 ms, endlessly re-triggerable.
* **Firework sparks** burst on touch-down and release, and an ember trail follows every move. Multi-touch works too: each extra finger splashes on its own.

<Go example="touch-fx" defaultFile="src/App.vue" />

:::details There is a switch hidden on this page
The hint line under the orb is a button. Press it and the orb starts springing back to the centre when you let go, instead of staying where you dropped it — and the label changes from `TOUCH·DRAG·DROP` to `TOUCH·DRAG·FLICK`. Press it again to put it back.

It needs no gesture recognition and no timers, which is the point: the label carries its own `main-thread-bindtouchstart/end`, and those run *before* the stage's handlers because touch events bubble. The label raises a flag, the stage sees it and stands down for the rest of the gesture — so pressing the switch never grabs the orb, never splashes, never fires the goodbye firework.

Both labels are rendered once by the Background Thread and stacked in the same spot; flipping the mode just crossfades their `opacity` from the Main Thread. Changing what the UI *says* costs two style writes and never crosses a thread boundary.
:::

:::tip Test it on your phone
This demo is all about touch latency, so it feels best on a real device. Switch the preview above to the **QR code** tab and scan it with [LynxExplorer](https://lynxjs.org/guide/start/quick-start.html) — the native `main.lynx.bundle` is served right from this site. On desktop, the Web preview responds to touch only; enable touch emulation in your browser devtools (or open this page on your phone's browser).
:::

## Why it feels instant

Every animated thing on this page — the spring physics, the ripple rings, the two particle pools (10 ripples / 64 sparks) — runs **on the Main Thread**, driven by [`'main thread'` worklets](/guide/main-thread-script.md) and a single `requestAnimationFrame` loop:

* Touch handlers (`main-thread-bindtouchstart/move/end`) run on the Main Thread, so there is **zero cross-thread round-trip** between your finger and the pixels.
* Element pools are pre-rendered once by the Background Thread; each pooled element is bound to a [`MainThreadRef`](/guide/api/vue-lynx/Function.useMainThreadRef.md), and the engine recycles them with direct `setStyleProperty` writes (only `transform` and `opacity` — cheap to composite).
* The engine state lives in a value-only `MainThreadRef`; the rAF loop **parks itself** when the orb settles and every particle has died, and wakes on the next touch.
* Even the UI state — which release mode is active, which label is showing — stays on the Main Thread. Nothing here round-trips to the Background Thread after the first render.

The continuous ripple feed is the part to steal for your own apps: on every frame while a finger is down, the loop spawns trail sparks and re-arms a ripple every 9 frames — which is why the effects never stop mid-drag, no matter how long or fast you scribble.

## Verify it headlessly

The example ships with a Lynx-for-Web harness (`examples/touch-fx/harness/`) that drives **real CDP touch events** through headless Chromium and pixel-checks the frames — including a continuity assertion that effect pixels track the finger at *every* sample of a 4-second drag:

```bash
cd examples/touch-fx
pnpm build
pnpm web:verify   # 10/10 checks: boot, splash, continuity, energy, firework,
                  # settle-where-dropped, stress, and the switch both ways
```



---
url: /guide/tutorial-gallery.md
---

# Tutorial: Product Gallery

We will build a product gallery page together during this tutorial using Vue 3 and Lynx. This tutorial does not assume any existing Lynx knowledge. The techniques you'll learn in the tutorial are fundamental to building any Lynx pages and applications.

:::note

This tutorial is designed for people who prefer to learn by doing and want to quickly try making something tangible. If you prefer learning each concept step by step, start with [Describing the UI](https://lynxjs.org/next/guide/ui/elements-components).

:::

## What are we building?

A furniture gallery with a beautiful waterfall layout, tap-to-like interactions, auto-scrolling, and a custom scrollbar — driven by Main Thread Script for buttery-smooth performance. Each section builds incrementally on the previous one.

<Go example="gallery" defaultFile="src/GalleryComplete/Gallery.vue" entry="src/GalleryComplete" defaultEntryName="GalleryComplete" />

## Setup for the tutorial

Check out the detailed [quick start](/guide/quick-start.md) doc that will guide you through creating a new Lynx project. We recommend TypeScript for a better development experience, provided by static type checking and better editor IntelliSense.

You'll see lots of beautiful images throughout this guide. We've put together a package of sample images you can download [here](https://lf-lynx.tiktok-cdns.com/obj/lynx-artifacts-oss-sg/lynx-website/download/Pictures.tar.gz) to use in your projects.

Your `lynx.config.ts` should look like this:

```ts title="lynx.config.ts"
import { defineConfig } from '@lynx-js/rspeedy';
import { pluginVueLynx } from 'vue-lynx/plugin';

export default defineConfig({
  source: {
    entry: {
      // We'll add entries here as we go
      ImageCard: './src/gallery/ImageCard/index.ts',
    },
  },
  plugins: [
    pluginVueLynx({
      optionsApi: false,
      enableCSSSelector: true,
    }),
  ],
});
```

## Adding Styles

Since the focus of this tutorial is not on how to style your UI, you may just save some time and directly copy the below `gallery.css` file:

:::details gallery.css

```css title="gallery.css"
.gallery-wrapper {
  height: 100%;
  background-color: black;
}

.single-card {
  display: flex;
  align-items: center;
  justify-content: center;
}

.scrollbar {
  position: absolute;
  right: 7px;
  z-index: 1000;
  width: 4px;
  background: linear-gradient(to bottom, #ff6448, #ccddff, #3deae7);
  border-radius: 5px;
  overflow: hidden;
  box-shadow:
    0px 0px 4px 1px rgba(12, 205, 223, 0.4),
    0px 0px 16px 5px rgba(12, 205, 223, 0.5);
}

.scrollbar-effect {
  width: 100%;
  height: 80%;
}

.glow {
  background-color: #333;
  border-radius: 4px;
  background: linear-gradient(
    45deg,
    rgba(255, 255, 255, 0) 20%,
    rgba(255, 255, 255, 0.8) 50%,
    rgba(255, 255, 255, 0) 80%
  );
  animation: flow 3s linear infinite;
}

@keyframes flow {
  0% {
    transform: translateY(-100%);
  }
  100% {
    transform: translateY(100%);
  }
}

.list {
  width: 100%;
  padding-bottom: 20px;
  padding-left: 20px;
  padding-right: 20px;
  height: 100%;
  list-main-axis-gap: 10px;
  list-cross-axis-gap: 10px;
}

.picture-wrapper {
  border-radius: 10px;
  overflow: hidden;
  width: 100%;
}

.like-icon {
  position: absolute;
  display: grid;
  justify-items: center;
  align-items: center;
  top: 0px;
  right: 0px;
  width: 48px;
  height: 48px;
}

.heart-love {
  width: 16px;
  height: 16px;
}

.circle {
  position: absolute;
  top: calc(50% - 8px);
  left: calc(50% - 8px);
  height: 16px;
  width: 16px;
  border: 2px solid red;
  border-radius: 50%;
  transform: scale(0);
  opacity: 1;
  animation: ripple 1s 1 ease-out;
}

.circleAfter {
  animation-delay: 0.5s;
}

@keyframes ripple {
  0% {
    transform: scale(1);
    opacity: 1;
  }
  100% {
    transform: scale(2);
    opacity: 0;
  }
}
```

:::

and import it in your entry file:

```ts
import '../gallery.css';
```

This makes sure your UI looks great when you are following this tutorial.

:::info Styling variations in Lynx
Lynx supports a wide variety of styling features, including global styles, CSS Modules, inline styles, Sass, CSS variables, and more! Please refer to [Rspeedy - Styling](https://lynxjs.org/next/rspeedy/styling) for how to pick your best styling configurations.
:::

## Your First Component: An Image Card

Now, let's start by creating the first image card, which will be the main part of this page.

<Go example="gallery" defaultFile="src/ImageCard/ImageCard.vue" entry="src/ImageCard" defaultEntryName="ImageCard" />

Great, you can now see the image card displayed. Here, we use the [`<image>`](https://lynxjs.org/next/api/elements/built-in/image) element to display your image. You only need to give it a width and height (or specify the `aspectRatio` property as shown here), and it will automatically resize to fit the specified dimensions. This component can receive a `picture` property via `defineProps`, allowing you to change the image it displays.

:::details The src Attribute of Images
The Lynx `<image>` element can accept a local relative path as the `src` attribute to render an image. All images in this page are sourced locally, and these paths need to be imported before use. However, if your images are stored online, you can easily replace them with web image addresses.
:::

:::info Vue Lynx Entry Point
Like standard Vue, Vue Lynx uses `createApp(Component).mount()`. The difference is that there is no DOM element to mount to — `mount()` is called with no arguments and attaches to the Lynx page root automatically.
:::

## Adding interactivity: Like an Image Card

We can add a small white heart in the upper right corner and make it the like button for the image card. Here, we implement a small component called `LikeIcon`:

<Go example="gallery" defaultFile="src/Components/LikeIcon.vue" entry={["src/Components", "src/LikeCard"]} defaultEntryName="LikeCard" />

We want each card to know whether it has been liked, so we added `isLiked`, which is its internal data. It can use this internal data to save your changes.

```vue title="LikeIcon.vue" {2}
<script setup lang="ts">
const isLiked = ref(false);
</script>
```

`ref(false)` creates a reactive variable. When `isLiked.value` changes, Vue's reactivity system automatically re-renders the component.

Then we add the `@tap` event to the wrapper `<view>`, so that when the user clicks the heart, it triggers this event and changes the state of `isLiked`:

```vue title="LikeIcon.vue" {2,5}
<script setup lang="ts">
function onTap() {
  isLiked.value = true;
}
</script>

<template>
  <view class="like-icon" @tap="onTap">
    ...
  </view>
</template>
```

:::details What is "@tap"?
Vue Lynx uses the same `@eventName` syntax you know from Vue on the web, but Lynx has its own set of events — `@tap` instead of `@click`, `@scroll` instead of native scroll, etc. Learn more on the [Event Handling](https://lynxjs.org/next/guide/interaction/event-handling) page.
:::

Finally, we use `isLiked` to control the like effect. Because `isLiked` is reactive, `LikeIcon` will respond to its changes, turning into a red heart icon. The `<view>` elements used to render the ripple animation are conditionally rendered with `v-if`:

```vue title="LikeIcon.vue"
<template>
  <view class="like-icon" @tap="onTap">
    <view v-if="isLiked" class="circle" />
    <view v-if="isLiked" class="circle circleAfter" />
    <image :src="isLiked ? redHeart : whiteHeart" class="heart-love" />
  </view>
</template>
```

We then compose `LikeIcon` with `ImageCard` into a `LikeImageCard` component (see the code in the viewer above).

To give the like a better visual interaction effect, we added CSS animations in `gallery.css`. You can also learn more about animations in the [Animation](https://lynxjs.org/next/guide/styling/animation) section and replace them with your preferred style!

## Displaying More Images with `<list>`

To show all your beautiful images, you may need help from `<list>`. This way, you will get a scrollable page that displays a large number of similar images:

<Go example="gallery" defaultFile="src/GalleryList/Gallery.vue" entry="src/GalleryList" defaultEntryName="GalleryList" />

:::details Special child elements of list
Each child of `<list>` needs to be `<list-item>`, and you must specify a unique and non-repeating `:key` and `:item-key` attribute, otherwise it may not render correctly.
:::

We use a waterfall layout as the child node layout option. `<list>` also accepts other layout types, which you can refer to in the [`<list>` documentation](https://lynxjs.org/next/api/elements/built-in/list).

:::info
You can refer to the [Scrolling](https://lynxjs.org/next/guide/ui/scrolling) documentation to learn more about scrolling and scrolling elements.
:::

## Auto-Scrolling via Element Methods

If you want to create a desktop photo wall, you need to add an auto-scroll feature to this page. Your images will be slowly and automatically scrolled, allowing you to easily see more images:

<Go example="gallery" defaultFile="src/GalleryAutoScroll/Gallery.vue" entry="src/GalleryAutoScroll" defaultEntryName="GalleryAutoScroll" />

```vue title="GalleryAutoScroll/Gallery.vue" {3-12}
<script setup lang="ts">
import { onMounted, nextTick } from 'vue-lynx';

onMounted(() => {
  nextTick(() => {
    lynx
      .createSelectorQuery()
      .select('[custom-list-name="list-container"]')
      .invoke({
        method: 'autoScroll',
        params: { rate: '60', start: 'true' },
      })
      .exec();
  });
});
</script>
```

We use `onMounted` combined with `nextTick` to call the [`autoScroll`](https://lynxjs.org/next/api/elements/built-in/list.html#autoscroll) method after the list is rendered. We use `lynx.createSelectorQuery()` to select the list element by its `custom-list-name` attribute and invoke the native method.

:::details What is "invoke"?
In Lynx, all native elements have a set of "methods" that can be called. Unlike on the web, this call is asynchronous, similar to message passing. You need to use `invoke` with the method name and parameters to call them.
:::

:::details onMounted + nextTick
`onMounted` runs once when the component is mounted. We call `nextTick` inside it to wait for the main thread to finish creating the native elements. In Vue Lynx, `nextTick` is enhanced to wait for the cross-thread ops flush — not just Vue's internal scheduler — so elements are guaranteed to exist when the callback fires.
:::

## How about a Custom Scrollbar?

Like most apps, we can add a scrollbar to this page to indicate how many images are left to be displayed. But we can do more! For example, we can replace the default progress bar of `<list>` with our preferred style:

<Go example="gallery" defaultFile="src/GalleryScrollbar/NiceScrollbar.vue" entry="src/GalleryScrollbar" defaultEntryName="GalleryScrollbar" />

The `NiceScrollbar` component exposes an `adjustScrollbar` method via `defineExpose`, which lets the parent component call methods on the child. Similar to the `@tap` event used to add the like functionality, we add the [`@scroll`](https://lynxjs.org/next/api/elements/built-in/list.html#scroll) event to `<list>`, which will be triggered when the `<list>` element scrolls. To make the scrollbar respond faster to scroll events, we set [`scroll-event-throttle`](https://lynxjs.org/next/api/elements/built-in/list.html#scroll-event-throttle) to 0.

:::details list-item's estimated-main-axis-size-px
You may have noticed this attribute on `<list-item>`. It estimates the size of elements on the main axis when they are not yet rendered in `<list>`. This is very useful when we add a scrollbar, as we need to know how long the scrollbar needs to be to cover all elements.

We provide a utility method to estimate the size based on the current layout and image dimensions:

```ts title="utils.ts"
export const calculateEstimatedSize = (
  pictureWidth: number,
  pictureHeight: number,
): number => {
  const galleryPadding = 20;
  const galleryMainAxisGap = 10;
  const gallerySpanCount = 2;
  const galleryWidth = SystemInfo.pixelWidth / SystemInfo.pixelRatio;
  const itemWidth = (galleryWidth - galleryPadding * 2 - galleryMainAxisGap)
    / gallerySpanCount;
  return (itemWidth / pictureWidth) * pictureHeight;
};
```

:::

At this point, we have a complete page! But you may have noticed that the scrollbar we added still lags a bit during scrolling, not as responsive as it could be. This is because our adjustments are still happening on the background thread, not the main thread that responds to touch scrolling.

:::details What are the background thread and main thread?
The biggest feature of Lynx is its dual-thread architecture. You can find a more detailed introduction in [JavaScript Runtime](https://lynxjs.org/next/guide/scripting-runtime/index.html#javascript).
:::

## A More Responsive Scrollbar

To optimize the performance of the scrollbar, we need to introduce [Main Thread Script](/guide/main-thread-script.md) to [handle events on the main thread](https://lynxjs.org/next/guide/interaction/event-handling.html#main-thread-event-processing), migrating the adjustments we made in the previous step for the scrollbar's height and position from the background thread to the main thread.

To let you see the comparison more clearly, we keep both scrollbars:

<Go example="gallery" defaultFile="src/GalleryScrollbarCompare/Gallery.vue" entry="src/GalleryScrollbarCompare" defaultEntryName="GalleryScrollbarCompare" />

The Main Thread Script scrollbar uses `:main-thread-ref` to bind a `MainThreadRef` to the element, allowing the Main Thread to directly manipulate it without any background thread round-trips.

Now you should be able to see that the scrollbar on the left (darkkhaki), controlled with main thread scripting, is smoother and more responsive compared to the scrollbar on the right that we implemented earlier. If you encounter issues in other UIs where updates need to happen immediately, try this method.

Key Vue concepts for Main Thread Script:

* `useMainThreadRef(null)` — Creates a ref that can be resolved on the Main Thread
* `:main-thread-bindscroll="ctx"` — Binds a Main Thread Script handler to the scroll event (runs on Main Thread, zero thread crossings)
* `.toJSON()` — Serializes the ref for cross-thread transfer (includes the internal `_wvid` identifier)

## Wrapping Up

We remove the redundant scrollbar used for comparison, and our Gallery is now complete! Let's take a look at the final result:

<Go example="gallery" defaultFile="src/GalleryComplete/Gallery.vue" entry="src/GalleryComplete" defaultEntryName="GalleryComplete" />

Congratulations! You have successfully created a product gallery page! Throughout this tutorial, you've covered the basics of writing interactive UIs on the Lynx platform with Vue 3.

## React vs Vue Quick Reference

| Concept          | React Lynx                           | Vue Lynx                           |
| ---------------- | ------------------------------------ | ---------------------------------- |
| Create app       | `root.render(<App />)`               | `createApp(App).mount()`           |
| State            | `const [x, setX] = useState(val)`    | `const x = ref(val)`               |
| Update state     | `setX(newVal)`                       | `x.value = newVal`                 |
| Template ref     | `const ref = useRef(null)`           | `const el = ref(null)`             |
| Lifecycle        | `useEffect(() => ..., [])`           | `onMounted(() => ...)`             |
| Class name       | `className="foo"`                    | `class="foo"`                      |
| Conditional      | `{cond && <el />}`                   | `<el v-if="cond" />`               |
| List             | `{arr.map(x => <el key={x} />)}`     | `<el v-for="x in arr" :key="x" />` |
| Tap event        | `bindtap={handler}`                  | `@tap="handler"`                   |
| Scroll event     | `bindscroll={handler}`               | `@scroll="handler"`                |
| Main Thread Script scroll | `main-thread:bindscroll={fn}`        | `:main-thread-bindscroll="ctx"`    |
| Main Thread Script ref    | `main-thread:ref={ref}`              | `:main-thread-ref="ref"`           |
| MT ref hook      | `useMainThreadRef(null)`             | `useMainThreadRef(null)`           |
| Expose to parent | `forwardRef` + `useImperativeHandle` | `defineExpose({ method })`         |
| Props            | `function Comp(props: { x: T })`     | `defineProps<{ x: T }>()`          |

## Running the Examples

```bash
# Install dependencies
pnpm install

# Build Vue runtime packages
cd packages/vue/runtime && pnpm build
cd packages/vue/main-thread && pnpm build

# Start the dev server
cd packages/vue/e2e-lynx && pnpm dev
```

Then open each bundle in LynxExplorer:

| Entry                       | Bundle                                  | What it shows                    |
| --------------------------- | --------------------------------------- | -------------------------------- |
| `ImageCard`        | `ImageCard.lynx.bundle`        | Single image card                |
| `LikeCard`         | `LikeCard.lynx.bundle`         | Card with tap-to-like            |
| `GalleryList`              | `GalleryList.lynx.bundle`              | Waterfall grid                   |
| `GalleryAutoScroll`        | `GalleryAutoScroll.lynx.bundle`        | Auto-scrolling gallery           |
| `GalleryScrollbar`         | `GalleryScrollbar.lynx.bundle`         | Gallery + BG Thread scrollbar    |
| `GalleryScrollbarCompare` | `GalleryScrollbarCompare.lynx.bundle` | BG vs MT scrollbar comparison    |
| `GalleryComplete`          | `GalleryComplete.lynx.bundle`          | Final gallery with Main Thread Script scrollbar |



---
url: /guide/tutorial-swiper.md
---

# Tutorial: Product Detail

export const swipeDemo = {
  // The web preview is driven by a mouse and this carousel by touch, so without
  // help it looks like a still image to a desktop reader. These synthesized
  // touches replay the swipe — seven to reach the last of the eight images,
  // then seven back — with the contact point drawn the way a device simulator
  // does it. The first real touch or pointer hands the example back.
  loop: true,
  startDelayMs: 1400,
  steps: [
    {
      path: [
        { x: 0.98, y: 0.3 },
        { x: -0.02, y: 0.3 },
      ],
      iterations: 7,
      durationMs: 520,
      restMs: 2600,
    },
    {
      path: [
        { x: 0.02, y: 0.3 },
        { x: 1.02, y: 0.3 },
      ],
      iterations: 7,
      durationMs: 520,
      restMs: 2600,
    },
  ],
};

This tutorial walks you through building a high-performance product detail page with **Vue 3** and **Lynx**, centered around a touch-swipeable image carousel.

You will learn:

* [**Building a Static Layout**](#building-a-static-layout): Using `v-for` and Lynx's `display: linear` to create a horizontal scroll structure
* [**Listening to Touch Events**](#listening-to-touch-events): Handling touch events on the background thread and updating node styles
* [**Using Main Thread Script to Reduce Latency**](#using-main-thread-script-to-reduce-latency): Eliminating cross-thread round-trip delay with the `'main thread'` directive
* [**Organizing Code with Composables**](#organizing-code-with-composables): Extracting touch logic and style updates into reusable composables
* [**Adding Snap-to-Page Animation**](#adding-snap-to-page-animation): Main-thread `requestAnimationFrame`-based animation
* [**Communication Between Main Thread and Background Thread**](#communication-between-main-thread-and-background-thread): Cross-thread function calls with `runOnBackground` and `runOnMainThread`
* [**Values Across Main Thread and Background Thread**](#values-across-main-thread-and-background-thread): Passing numeric values and main-thread functions between threads

## What Are We Building?

The end result is a product detail page. At the top is a full-width image carousel that supports:

* **Zero-latency** finger-drag scrolling through images
* Automatic **snap-to-nearest-page** with easing animation on release
* A bottom **indicator** that highlights the current page in real time
* **Tap an indicator dot** to jump to that page

The carousel responds to touch, so the web preview below demonstrates it for you: the swipes are simulated, and the circle marks where a finger would be. Touch or click the preview at any time and it hands control straight back to you.

<Go example="swiper" defaultFile="src/Swiper/Swiper.vue" autoGesture={swipeDemo} entry="src/Swiper" defaultEntryName="Swiper" />

## Setup for the Tutorial

This tutorial assumes you have completed the environment setup in the [Quick Start](/guide/quick-start.md) guide and have the LynxExplorer app installed.

All source code lives under `examples/swiper/src/`, organized into three progressive entry points:

| Entry         | Description                                                      | Tutorial Section                                                        |
| ------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `SwiperEmpty` | Static layout, no interaction                                    | [Building a Static Layout](#building-a-static-layout)                   |
| `SwiperMTS`   | Main-thread touch handling, no animation/indicator               | [Using Main Thread Script](#using-main-thread-script-to-reduce-latency) |
| `Swiper`      | Full version: animation + indicator + cross-thread communication | [Adding Animation](#adding-snap-to-page-animation) and beyond           |

TypeScript is recommended for better editor hints and type checking.

## Building a Static Layout

Let's start with the simplest version — a non-interactive static image list.

The demonstration swipes this one too, and nothing moves — that is the point. Nothing here listens for the gesture yet.

<Go example="swiper" defaultFile="src/SwiperEmpty/Swiper.vue" autoGesture={swipeDemo} entry="src/SwiperEmpty" defaultEntryName="SwiperEmpty" />

Each image is wrapped in a `SwiperItem` component. The `Swiper` component renders them with `v-for`. The key CSS uses `display: linear` — a Lynx-specific layout mode, similar to flexbox but more performant:

```css title="swiper.css"
.swiper-wrapper {
  flex: 1;
  width: 100%;
}
.swiper-container {
  display: linear;
  linear-orientation: horizontal;
  height: 100%;
}
```

::: info Lynx's display: linear
Lynx supports a `display: linear` layout mode where `linear-orientation: horizontal` arranges children horizontally. Compared to `display: flex`, `linear` layout has better performance in Lynx's native rendering engine.
:::

Open LynxExplorer and preview `SwiperEmpty` — you'll see a row of images laid out horizontally, but you can't swipe them. Let's add touch interaction next.

## Listening to Touch Events

To make the images swipeable, we need to:

1. Listen to `touchstart` / `touchmove` / `touchend` events
2. Calculate the finger's displacement
3. Apply the displacement to the container's `transform` style

### The Background Thread Approach

In Vue Lynx, event handlers run on the **background thread** by default. We can use regular Vue `ref`s to track touch state:

```vue title="Swiper.vue (background thread approach)" {3,6-8,11-13,16-19,22-23}
<script setup lang="ts">
import { ref } from 'vue';
import SwiperItem from '../Components/SwiperItem.vue';

// Touch state
const touchStartX = ref(0);
const currentOffset = ref(0);
const touchStartOffset = ref(0);

function handleTouchStart(
  e: { detail: { touches: Array<{ clientX: number }> } },
) {
  touchStartX.value = e.detail.touches[0].clientX;
  touchStartOffset.value = currentOffset.value;
}

function handleTouchMove(
  e: { detail: { touches: Array<{ clientX: number }> } },
) {
  const delta = e.detail.touches[0].clientX - touchStartX.value;
  currentOffset.value = touchStartOffset.value + delta;
  // Need to update the style... how?
}
</script>

<template>
  <view class="swiper-wrapper">
    <view
      class="swiper-container"
      @touchstart="handleTouchStart"
      @touchmove="handleTouchMove"
    >
      <!-- ... -->
    </view>
  </view>
</template>
```

But there's a problem — on the background thread, we have **no direct access to DOM nodes**. To update the container's `transform` style, we'd need to make an async **cross-thread round-trip** via an API like `lynx.createSelectorQuery()`.

::: details Why not use reactive state to update position?
You might think: just bind `:style="{ transform: 'translateX(' + currentOffset + 'px)' }"` and let Vue handle it?

This **works**, but every `touchmove` (fired 60–120 times per second) would trigger Vue's reactive update → diff → ops generation → cross-thread send → main-thread apply. This full update pipeline introduces noticeable latency, especially on low-end devices.

For high-frequency touch events, we need a more direct way to update styles.
:::

### The Latency Problem

In Lynx's dual-thread architecture, the default touch event handling flow is:

```
┌──────────────┐    Touch event    ┌──────────────┐    Update style    ┌──────────────┐
│   Native     │ ────────────────▶ │  Background   │ ────────────────▶ │  Main Thread │
│ (touch fires)│                   │   Thread      │  cross-thread     │ (apply style)│
│              │                   │ (handle event)│     call          │              │
└──────────────┘                   └──────────────┘                    └──────────────┘
```

Every touch move requires a full **main thread → background thread → main thread** round-trip, which causes perceivable **swipe lag** on low-end devices.

The solution? **Run the event handler directly on the main thread.**

## Using Main Thread Script to Reduce Latency

[Main Thread Script](/guide/main-thread-script.md) lets us mark functions to run on the main thread, completely eliminating cross-thread round-trip delay.

### Three Key Changes

Converting from the background thread approach to main thread requires just three steps:

**1. Replace `ref` with `useMainThreadRef`**

Main-thread functions cannot access background-thread `ref()`s. Use `useMainThreadRef` instead — it creates references that are readable and writable on the main thread:

```ts {1,4-7}
import { useMainThreadRef } from 'vue-lynx';

// Before: const touchStartX = ref(0);
const containerRef = useMainThreadRef<unknown>(null);
const currentOffsetRef = useMainThreadRef<number>(0);
const touchStartXRef = useMainThreadRef<number>(0);
const touchStartOffsetRef = useMainThreadRef<number>(0);
```

::: info How to access useMainThreadRef
`useMainThreadRef` returns a reference accessed via the `.current` property on the main thread — not Vue's `.value`. This is because `useMainThreadRef` lives in the main-thread runtime, which has its own access protocol separate from Vue's reactivity system.

```ts
// Background thread: Vue ref
const count = ref(0);
count.value = 1;

// Main thread: MainThreadRef
const countRef = useMainThreadRef<number>(0);
// Inside a 'main thread' function:
countRef.current = 1;
```

:::

**2. Add the `'main thread'` directive to functions**

Add the string literal `'main thread'` as the first line of a function body. The SWC compiler will automatically extract this function into the main-thread bundle:

```ts {2,8,14}
const handleTouchStart = (e: { touches: Array<{ clientX: number }> }) => {
  'main thread';
  touchStartXRef.current = e.touches[0].clientX;
  touchStartOffsetRef.current = currentOffsetRef.current;
};

const handleTouchMove = (e: { touches: Array<{ clientX: number }> }) => {
  'main thread';
  const delta = e.touches[0].clientX - touchStartXRef.current;
  const offset = touchStartOffsetRef.current + delta;
  currentOffsetRef.current = offset;
  // Directly manipulate the main-thread node's style
  (containerRef as any).current?.setStyleProperties?.({
    transform: `translateX(${offset}px)`,
  });
};

const handleTouchEnd = () => {
  'main thread';
  touchStartXRef.current = 0;
  touchStartOffsetRef.current = 0;
};
```

**3. Use the `main-thread-` prefix in templates**

Vue Lynx uses the `main-thread-` prefix to route event bindings and refs to the main thread:

```vue {3-6}
<template>
  <view
    class="swiper-container"
    :main-thread-ref="containerRef"
    :main-thread-bindtouchstart="handleTouchStart"
    :main-thread-bindtouchmove="handleTouchMove"
    :main-thread-bindtouchend="handleTouchEnd"
  >
    <!-- ... -->
  </view>
</template>
```

::: details The main-thread- prefix in Vue templates
Vue templates use the `main-thread-` hyphenated prefix with `v-bind` (`:`) to route event bindings and refs to the main thread:

```vue
<view :main-thread-ref="containerRef" :main-thread-bindtouchstart="fn" />
```

This is needed because Vue template attribute names don't support colons.
:::

### Putting It Together

<Go example="swiper" defaultFile="src/SwiperMTS/Swiper.vue" autoGesture={swipeDemo} entry="src/SwiperMTS" defaultEntryName="SwiperMTS" />

Open LynxExplorer and preview `SwiperMTS` — drag the images and you'll find the swipe responds **instantly** with zero lag. See the complete code in the viewer above.

::: details Use Main Thread Script Sparingly
Only use main thread script when you encounter **latency issues with high-frequency events**. Overuse increases the main thread's burden and can cause jank.

Good use cases:

* High-frequency events like `touchmove` and `scroll`
* Drag interactions requiring immediate response
* Animation frame updates

Not recommended for:

* Simple `tap` click handlers
* Infrequent UI updates
* Logic requiring complex data processing
  :::

## Organizing Code with Composables

Currently all logic lives in a single component. As we add features (animation, indicator), the code will become hard to maintain. Vue 3's [Composables](https://vuejs.org/guide/reusability/composables.html) help us organize code into reusable modules.

### useUpdateSwiperStyle — Container Ref and Style Updates

`useUpdateSwiperStyle` wraps the `containerRef` and a `'main thread'` function that calls `setStyleProperties` — the same logic from the previous section, now reusable.

### useOffset — Touch Handling and Offset Tracking

`useOffset` extracts touch logic, accepting an `onOffsetUpdate` callback for decoupling:

```ts title="Swiper/useOffset.ts" {2,11-12}
export function useOffset({
  onOffsetUpdate,
  itemWidth,
}: {
  onOffsetUpdate: (offset: number) => void;
  itemWidth: number;
}) {
  // Same touch state refs and handlers as before...

  function updateOffset(offset: number) {
    'main thread';
    currentOffsetRef.current = offset;
    onOffsetUpdate(offset); // Callback replaces direct style update
  }
  // ...
}
```

### The Simplified Swiper.vue

The component becomes a thin assembly layer that wires the composables together:

```vue title="Swiper/Swiper.vue"
<script setup lang="ts">
const { containerRef, updateSwiperStyle } = useUpdateSwiperStyle();
const { handleTouchStart, handleTouchMove, handleTouchEnd } = useOffset({
  itemWidth: props.itemWidth,
  onOffsetUpdate: updateSwiperStyle,
});
</script>
```

::: info Composables with Main Thread Script
Vue composables work naturally with main-thread functions — functions marked with `'main thread'` capture `useMainThreadRef` references via closures, just like ordinary functions. No special rules apply.
:::

Currently, releasing a drag leaves the image at an arbitrary position. Let's add snap-to-page animation next.

## Adding Snap-to-Page Animation

On release, the swiper should automatically slide to the nearest full page. This requires a `requestAnimationFrame`-based animation running on the main thread.

### useAnimate — RAF Animation Composable

`useAnimate` provides an `animate(options)` function that runs a `requestAnimationFrame` loop on the main thread, interpolating from one value to another with easing. Key points:

* Both `animateInner` and easing functions need the `'main thread'` directive since they run inside the RAF loop
* `useAnimate` tracks the current animation via a `useMainThreadRef` so it can be cancelled (e.g., when the user touches during an animation)

:::details Full useAnimate.ts source

```ts title="utils/useAnimate.ts"
import { useMainThreadRef } from 'vue-lynx';

export interface AnimationOptions {
  from: number;
  to: number;
  duration?: number;
  delay?: number;
  easing?: (t: number) => number;
  onUpdate?: (value: number) => void;
  onComplete?: () => void;
}

export const easings = {
  easeInOutQuad: (t: number) => {
    'main thread';
    return t < 0.5 ? 2 * t * t : 1 - Math.pow(-2 * t + 2, 2) / 2;
  },
};

function animateInner(options: AnimationOptions) {
  'main thread';
  const { from, to, duration = 5000, delay = 0,
    easing = easings.easeInOutQuad, onUpdate, onComplete } = options;
  let startTs = 0;
  let rafId = 0;

  function tick(ts: number) {
    const progress = Math.max(Math.min(
      ((ts - startTs - delay) * 100) / duration, 100), 0) / 100;
    onUpdate?.(from + (to - from) * easing(progress));
  }

  function step(ts: number) {
    if (!startTs) startTs = Number(ts);
    if (ts - startTs <= duration + 100) {
      tick(ts);
      rafId = requestAnimationFrame(step);
    } else {
      onComplete?.();
    }
  }

  rafId = requestAnimationFrame(step);
  return { cancel: () => cancelAnimationFrame(rafId) };
}

export function useAnimate() {
  const lastCancelRef = useMainThreadRef<(() => void) | null>(null);

  function cancel() {
    'main thread';
    lastCancelRef.current?.();
  }

  function animate(options: AnimationOptions) {
    'main thread';
    cancel();
    const { cancel: innerCancel } = animateInner(options);
    lastCancelRef.current = innerCancel;
  }

  return { cancel, animate };
}
```

:::

### Updating useOffset — Adding Snap Logic

In `handleTouchEnd`, calculate the nearest page position and start the animation:

```ts title="Swiper/useOffset.ts (new parts highlighted)" {1,7-10,14-16,20-30}
const { animate, cancel: cancelAnimate } = useAnimate();

function calcNearestPage(offset: number) {
  'main thread';
  return Math.round(offset / itemWidth) * itemWidth;
}

function updateOffset(offset: number) {
  'main thread';
  // Clamp to bounds
  const upperBound = -(dataLength - 1) * itemWidth;
  const realOffset = Math.min(0, Math.max(upperBound, offset));
  currentOffsetRef.current = realOffset;
  onOffsetUpdate(realOffset);
}

function handleTouchStart(e: { touches: Array<{ clientX: number }> }) {
  'main thread';
  // ...
  cancelAnimate(); // Cancel ongoing animation on touch
}

function handleTouchEnd() {
  'main thread';
  // ...
  animate({
    from: currentOffsetRef.current,
    to: calcNearestPage(currentOffsetRef.current),
    onUpdate: (offset: number) => {
      'main thread';
      updateOffset(offset);
    },
  });
}
```

Now releasing a drag smoothly snaps to the nearest page with easing.

But we still don't have a page indicator — the user doesn't know which page they're on. Adding an indicator requires a key capability: **notifying the background thread from the main thread**.

## Communication Between Main Thread and Background Thread

The Indicator component is an ordinary Vue component running on the background thread, driven by a reactive `ref`. But the current page index changes inside `handleTouchMove` on the main thread.

We need a way to **call a background-thread function from a main-thread function**.

::: info Main thread and background thread functions cannot call each other directly
Main thread script and background thread script run in **completely separate runtime environments**. A function in one runtime cannot directly call a function in the other — they need dedicated bridging APIs to communicate:

* `runOnBackground(fn)` — called from a main-thread function; asynchronously executes background-thread `fn`
* `runOnMainThread(fn)` — called from the background thread; asynchronously executes main-thread function `fn`
  :::

### Main Thread Calling Background Thread — `runOnBackground`

When the user drags images, `updateOffset` on the main thread calculates the current page index. We need to sync this index to the background thread's indicator state:

```ts title="Swiper/useOffset.ts" {1,8,10,23-27}
import { runOnBackground, useMainThreadRef } from 'vue-lynx';

export function useOffset({
  onOffsetUpdate,
  onIndexUpdate, // New: background-thread index update callback
  itemWidth,
  dataLength,
}: {
  onOffsetUpdate: (offset: number) => void;
  onIndexUpdate: (index: number) => void;
  itemWidth: number;
  dataLength: number;
}) {
  // ...
  const currentIndexRef = useMainThreadRef<number>(0);

  function updateOffset(offset: number) {
    'main thread';
    // ...(bounds clamping and style update unchanged)
    const index = Math.round(-realOffset / itemWidth);
    if (currentIndexRef.current !== index) {
      currentIndexRef.current = index;
      runOnBackground(onIndexUpdate)(index); // MT -> BG
    }
  }
  // ...
}
```

`runOnBackground(onIndexUpdate)(index)` means: **on the background thread**, asynchronously call `onIndexUpdate` with `index` as the argument.

::: details Why not call onIndexUpdate(index) directly?
If you try to call `onIndexUpdate(index)` directly inside a `'main thread'` function, the SWC compiler will produce an error. `onIndexUpdate` (i.e., the callback that updates `currentIndex.value`) is a background-thread function — it **doesn't exist** in the main-thread runtime.

```ts
function updateOffset(offset: number) {
  'main thread';
  // Wrong: onIndexUpdate is a background-thread function
  onIndexUpdate(index);

  // Correct: bridge via runOnBackground
  runOnBackground(onIndexUpdate)(index);
}
```

:::

### Background Thread Calling Main Thread — `runOnMainThread`

Tapping an indicator dot should jump to the corresponding page. The tap handler runs on the background thread, but the slide animation runs on the main thread. This requires **the background thread to call the main thread**:

```ts title="Swiper/useOffset.ts" {1-2,5-8}
import {
  runOnBackground,
  runOnMainThread,
  useMainThreadRef,
} from 'vue-lynx';

// New: background-thread function, called by Indicator's tap callback
function updateIndex(index: number) {
  const offset = -index * itemWidth;
  runOnMainThread(updateOffset)(offset); // BG -> MT
}
```

`runOnMainThread(updateOffset)(offset)` means: **on the main thread**, asynchronously call `updateOffset` with `offset` as the argument. This triggers the main-thread style update from the background thread.

### Adding the Indicator Component

The `Indicator` component is straightforward — it renders a row of dots using `v-for`, highlights the active one via `:class`, and emits `item-click` on `@tap`. See `Components/Indicator.vue` in the viewer below.

### Assembling in Swiper

The Swiper component wires everything together — `onIndexUpdate` bridges from the main thread to update the reactive `currentIndex`, and `handleItemClick` bridges the other direction:

```vue title="Swiper/Swiper.vue" {1,4-6,10-11}
<script setup lang="ts">
const currentIndex = ref(0);

const { handleTouchStart, handleTouchMove, handleTouchEnd, updateIndex } =
  useOffset({
    // ...
    onIndexUpdate: (index: number) => {
      currentIndex.value = index; // Update reactive state on BG thread
    },
  });

function handleItemClick(index: number) {
  currentIndex.value = index;
  updateIndex(index); // BG -> MT jump animation
}
</script>
```

Now the indicator tracks swipe progress in real time, and tapping a dot jumps to that page. Here's the data flow:

```
Drag swipe (MT):
  handleTouchMove -> updateOffset -> runOnBackground(onIndexUpdate) -> currentIndex.value
                                                                              |
                                                                       Indicator updates

Tap to jump (BG -> MT):
  handleItemClick -> updateIndex -> runOnMainThread(updateOffset) -> animated slide
```

## Values Across Main Thread and Background Thread

Currently the animation duration and easing curve are hardcoded. We want to pass them in as component props. But this involves a subtle question: **How can main-thread functions use background-thread values?**

### Main Thread Functions Using Background Thread Values

`duration` (animation length) is an ordinary number value defined in background-thread props. The main-thread `handleTouchEnd` function needs to use it.

Good news: **main-thread functions can automatically capture background-thread values**. When `useOffset` receives a `duration` parameter and the function's closure references it, the SWC compiler automatically serializes and passes these values to the main thread at render time:

```ts title="Swiper/useOffset.ts" {5,14}
export function useOffset({
  onOffsetUpdate,
  onIndexUpdate,
  itemWidth,
  dataLength,
  duration, // background-thread value
}: {
  // ...
  duration?: number;
}) {
  // ...
  function handleTouchEnd() {
    'main thread';
    animate({
      // ...
      duration, // Automatically passed from BG to MT
    });
  }
}
```

::: info Limitations of automatic value passing
Background-thread values captured by main-thread functions must be **serializable** (number, string, boolean, plain object, array). Functions and Promises cannot be passed directly.

Also, value passing happens at **render time**, and subsequent updates are not automatically synced. For immutable config values like `duration`, this is perfectly fine.
:::

### Background Thread Passing Main Thread Functions

The easing curve is a **function** that needs to be called inside the main-thread RAF loop. Ordinary functions can't cross the thread boundary — but functions marked with `'main thread'` can.

Define the easing function with the `'main thread'` directive:

```ts title="Swiper/index.ts" {2,9}
import { easings } from '../utils/useAnimate.js';

const App = defineComponent({
  setup() {
    return () =>
      h(Swiper, {
        data: picsArr,
        duration: 300,
        'main-thread-easing': easings.easeInOutQuad,
      });
  },
});
```

In `Swiper.vue`, receive the prop and forward it to `useOffset`:

```vue title="Swiper/Swiper.vue" {4}
<script setup lang="ts">
const props = defineProps<{
  // ...
  duration?: number;
  'main-thread-easing'?: (t: number) => number;
}>();

const { ... } = useOffset({
  // ...
  duration: props.duration,
  MTEasing: props['main-thread-easing'],
});
</script>
```

In `useOffset`, the main-thread `handleTouchEnd` simply references `duration` and `MTEasing` — the compiler handles the rest:

```ts title="Swiper/useOffset.ts" {6-7}
function handleTouchEnd() {
  'main thread';
  animate({
    from: currentOffsetRef.current,
    to: calcNearestPage(currentOffsetRef.current),
    duration, // BG value -> automatically passed to MT
    easing: MTEasing, // MT function -> passed to MT
    onUpdate: (offset: number) => {
      'main thread';
      updateOffset(offset);
    },
  });
}
```

::: details Why use the main-thread-easing prefix?
When a prop's value is a **main-thread function**, it needs the `main-thread-` prefix in the name. This tells the SWC compiler that this value needs to be resolved on the main-thread side.

Without the prefix, the compiler treats it as an ordinary background-thread value and tries to serialize a function — which is not serializable, resulting in a runtime error.
:::

<Go
  example="swiper"
  defaultFile="src/Swiper/Swiper.vue"
  autoGesture={swipeDemo}
  entry="src/Swiper"
  defaultEntryName="Swiper"
  highlight={{
  'src/Swiper/Swiper.vue': '{22-33,35-38,57-61}',
  'src/Swiper/useOffset.ts': '{2,28,30-33,41-54,71-85}',
  'src/Swiper/useUpdateSwiperStyle.ts': '{6-7}',
  'src/Components/Indicator.vue': '{2-9,17}',
}}
/>

## Summary

Congratulations! You've built a high-performance product detail page with an image carousel. Let's review the core concepts learned:

* **Lynx layout**: `display: linear` + `linear-orientation: horizontal` for high-performance horizontal layout
* **Main Thread Script** (`'main thread'`): Run touch event handlers directly on the main thread, eliminating cross-thread latency
* **`useMainThreadRef`**: Create main-thread-readable/writable references, replacing background-thread `ref()`, accessed via `.current`
* **Vue composables**: Extract Main Thread Script logic into reusable modules like `useOffset`, `useUpdateSwiperStyle`, `useAnimate`
* **`runOnBackground`**: Main thread -> background thread function call bridge (indicator state sync)
* **`runOnMainThread`**: Background thread -> main thread function call bridge (tap-to-jump animation)
* **Cross-thread value passing**: Serializable background-thread values are automatically passed to main-thread functions; main-thread functions are passed via `main-thread-` prefixed props

The complete source code is in `examples/swiper/src/`, with three progressive versions for reference.

::: info Main Thread Script Function Bodies Are Framework-Agnostic
All `'main thread'`-marked function bodies (`handleTouchStart`, `updateOffset`, `animate`, etc.) are compiled by the SWC compiler into a standalone main-thread bundle, independent of the component framework. The `'main thread'` directive works the same way regardless of whether the outer component uses Vue SFCs or JSX.
:::



---
url: /guide/typescript.md
---

# TypeScript

Vue Lynx supports TypeScript out of the box. Since Vue Lynx is built on the standard Vue 3 runtime, all of Vue's TypeScript features work as documented in the [Vue TypeScript guide](https://vuejs.org/guide/typescript/overview) -- `<script lang="ts">`, `defineComponent()`, template type checking, and so on.

This page covers what's specific to Vue Lynx: type declarations for Lynx built-in elements and a Volar plugin for correct IDE resolution.

:::tip Prerequisite: Rspeedy TypeScript setup
Before configuring Vue Lynx types, make sure your project has the base Rspeedy TypeScript setup in place -- `rspeedy-env.d.ts`, path aliases, `isolatedModules`, etc. See the [Rspeedy TypeScript guide](https://lynxjs.org/rspeedy/typescript.html) for details.
:::

## Lynx Element Types

By default, Volar resolves tags like `<view>` and `<text>` as SVG elements, since they exist in the SVG spec. Vue Lynx provides type declarations that override this with Lynx-specific types, and a Volar plugin that tells the language server to treat them as custom components.

Add the following to your source-level `tsconfig.json` (typically `src/tsconfig.json`):

```json title="src/tsconfig.json"
{
  "compilerOptions": {
    "types": ["vue-lynx/types"]
  },
  "vueCompilerOptions": {
    "plugins": ["vue-lynx/types/volar-plugin"]
  }
}
```

:::tip
If you created your project with `create-vue-lynx` (TypeScript template), this is already configured.
:::

**What each option does:**

* `"types": ["vue-lynx/types"]` augments Vue's `GlobalComponents` interface with all Lynx built-in elements (`view`, `text`, `image`, `scroll-view`, `list`, etc.) and their typed props and events.
* `"plugins": ["vue-lynx/types/volar-plugin"]` configures Volar's `isNativeTag` so that Lynx elements are resolved through the `GlobalComponents` augmentation instead of falling back to SVG definitions.

With this setup, your IDE will provide prop autocomplete, event autocomplete, and type errors for all Lynx elements.

### Example

Here's a typical component using typed props with Lynx elements:

```vue title="src/Greeting.vue"
<script setup lang="ts">
defineProps<{
  name: string
  avatarUrl: string
}>()
</script>

<template>
  <view style="{ flexDirection: 'row', alignItems: 'center' }">
    <image :src="avatarUrl" style="{ width: 40, height: 40 }" />
    <text @tap="() => console.log('tapped')">Hello, {{ name }}</text>
  </view>
</template>
```

In this example, `<view>`, `<image>`, and `<text>` all have full IntelliSense -- `src` on `<image>` is typed as a string, `@tap` on `<text>` is recognized as a valid event, and misspelled props like `<view srcc="...">` would produce a type error.

## Event Types

Lynx uses the `bind*` convention for events (e.g., `bindtap`, `bindtouchstart`). The Vue Lynx type declarations automatically map these to Vue's `on*` convention:

| Lynx | Vue template | Vue JSX |
|------|-------------|---------|
| `bindtap` | `@tap` | `onTap` |
| `bindtouchstart` | `@touchstart` | `onTouchstart` |
| `bindlayoutchange` | `@layoutchange` | `onLayoutchange` |

The mapping uses TypeScript's `Capitalize` utility type on the suffix after `bind`, so `bindtouchstart` becomes `onTouchstart` (not `onTouchStart`). All event handler types are preserved through the transformation, so you get full type checking on event callback parameters.

## Type Checking

Following the same approach as standard Vue projects (see [Vue docs on type checking](https://vuejs.org/guide/typescript/overview#project-setup)), use [`vue-tsc`](https://github.com/vuejs/language-tools/tree/master/packages/tsc) for command-line type checking:

```bash
npx vue-tsc --noEmit
```

This validates your Lynx element usage, props, and events against the type declarations, including inside `.vue` single-file components.



---
url: /guide/vue-compatibility.md
---

# Vue Features Compatibility

Vue Lynx is built on the official Vue 3 runtime core (`@vue/runtime-core`), so you should expect your Vue code to just work. The core rendering path — Composition API, SFCs, reactivity, template directives — works the same way you'd expect from standard Vue, with no Lynx-specific adaptation required.

Below is a feature-by-feature breakdown of the Vue features we've verified on Lynx. Where Lynx-specific caveats exist, they are called out inline. For details on how the dual-thread architecture works under the hood, see [Understanding the Dual-Thread Model](/guide/introduction.md#understanding-the-dual-thread-model).

## Reactivity + Composables

Vue Lynx reuses 100% of Vue's reactivity core (`@vue/reactivity`). Every reactivity API works identically to standard Vue, with no Lynx-specific caveats or adaptations.

The example below demonstrates [`reactive()`](https://vuejs.org/api/reactivity-core.html#reactive) + [`toRefs()`](https://vuejs.org/api/reactivity-utilities.html#torefs), and a `useStopwatch()` composable that encapsulates reactive state:

<Go example="reactivity" defaultFile="src/App.vue" />

## SFC CSS Features

Plain `<style>` blocks, imported `.css` files, [`<style module>`](https://vuejs.org/api/sfc-css-features.html#css-modules), [`<style scoped>`](https://vuejs.org/api/sfc-css-features.html#scoped-css), and [`v-bind()` in CSS](https://vuejs.org/api/sfc-css-features.html#v-bind-in-css) all work on Lynx.

:::details Feature support details

| Feature | Status |
|---------|--------|
| `<style>` (plain) | Works |
| Imported `.css` files | Works |
| `<style module>` | Works |
| `v-bind()` in `<style>` | Works (requires config, see below) |
| `<style scoped>` | Works (see caveats below) |

:::warning `<style scoped>` caveats
[`:deep()`](https://vuejs.org/api/sfc-css-features.html#deep-selectors), [`:slotted()`](https://vuejs.org/api/sfc-css-features.html#slotted-selectors), and [`:global()`](https://vuejs.org/api/sfc-css-features.html#global-selectors) are not yet supported ([#164](https://github.com/Huxpro/vue-lynx/issues/164), [#165](https://github.com/Huxpro/vue-lynx/issues/165)).

Scopes do not stack. On the web, Vue gives a child component's root element the `data-v-*` attribute of *both* the child and its parent, so [a parent's scoped styles can also target that root element](https://vuejs.org/api/sfc-css-features.html#scoped-css). Lynx associates each element with exactly one CSS scope, and Vue Lynx always keeps the one of the component that authored the element — a component's own scoped rules always apply to its root. A parent that needs to style a child's root should pass a class the child applies itself, or add a wrapper element of its own.
:::

`v-bind()` in `<style>` requires two config options so the Lynx engine recognizes CSS custom properties in inline styles and cascades them to descendants:

```ts title="lynx.config.ts"
pluginVueLynx({
  enableCSSInlineVariables: true,
  enableCSSInheritance: true,
})
```

:::warning Known limitation
Layout-affecting properties (e.g., `font-size`) driven by `v-bind()` apply correctly on initial render but may not update visually on reactive change. This is a Lynx engine limitation. Workaround: drive layout properties via `:style` binding directly on the element.
:::

:::

<Go example="css-features" defaultFile="src/App.vue" />

## v-model

Vue's `v-model` creates two-way bindings. On **components**, the child uses [`defineModel()`](https://vuejs.org/api/sfc-script-setup.html#definemodel) (Vue 3.4+) to declare a model prop, and the parent binds it with `v-model`. On **native `<input>` and `<textarea>` elements**, `v-model` works just like standard Vue, including the `.lazy`, `.trim`, and `.number` modifiers.

The example demonstrates:

1. **Default model** — `defineModel<number>()` with `v-model="count"` for a counter
2. **Named models** — `defineModel('title')` + `defineModel('body')` with `v-model:title` / `v-model:body`
3. **Native input v-model** — `v-model` directly on `<input>`

:::warning Caveat
`v-model` on **`<select>`**, **`<input type="checkbox">`**, and **`<input type="radio">`** is not supported — Lynx has no native equivalents for these elements. Use component-level `v-model` with custom components instead.
:::

<Go example="v-model" defaultFile="src/App.vue" />

## Event Modifiers

Vue's [event modifiers](https://vuejs.org/guide/essentials/event-handling.html#event-modifiers) (`.once`, `.stop`, `.self`) work on Lynx. `.prevent` is accepted as a compatibility no-op — see the table below for details.

:::details Feature support details

| Modifier | Status | Notes |
|----------|--------|-------|
| `.once` | Works | Handler fires at most once. The Vue compiler emits `onTapOnce` prop keys; `withModifiers` also supports it. |
| `.stop` | Works | Uses Lynx's native `catchEvent` mechanism to stop propagation at the element level. Also calls `stopPropagation()` in DOM/test environments. |
| `.self` | Works | Compares by `uid` (Lynx native) or `uniqueId` (web preview) since cross-thread event objects are always distinct references. Falls back to reference equality in DOM/test environments. |
| `.prevent` | Compatibility no-op | Accepted silently so web code runs on Lynx without modification. Lynx has no browser default actions to cancel (no `<a>` navigation, no `<form>` submission), so this modifier has no observable effect. |

:::

:::info Main Thread Script event handlers
Vue's modifier system does not apply to `:main-thread-bind*` handlers (e.g. `:main-thread-bindtap`). These use Lynx-native v-bind syntax and bypass Vue's v-on event pipeline entirely — the compiler never generates `onTapOnce` keys or `withModifiers()` wrappers for them. Use the native equivalents instead: `:main-thread-catchtap` for propagation stopping, and inline Main Thread Script logic for `.once`/`.self` behaviour.
:::

The example below demonstrates `.once`, `.stop`, and `.self`. The `.prevent` card explains why no interactive demo is shown for that modifier:

<Go example="event-modifiers" defaultFile="src/App.vue" />

## Slots

Vue [slots](https://vuejs.org/guide/components/slots.html) are the primary composition mechanism for passing template content into child components. Vue Lynx supports default slots, named slots, and scoped slots.

The example below demonstrates all three patterns:

1. **Default slot** — content projected into a `<Card>` component
2. **Named slots** — `#header` and `#footer` with fallback content
3. **Scoped slot** — a `<DataList>` exposes each item to the parent for custom rendering

<Go example="slots" defaultFile="src/App.vue" />

## Provide / Inject

Vue's [`provide`](https://vuejs.org/guide/components/provide-inject.html) and `inject` APIs let an ancestor component serve as a dependency injector for all its descendants, regardless of how deep the component hierarchy is. This avoids prop drilling through intermediate components.

The example below provides a reactive `theme` ref and a static `appName` string at the root. A grandchild component injects both — the middle layer passes nothing down.

<Go example="provide-inject" defaultFile="src/App.vue" />

## Suspense

Vue's [`<Suspense>`](https://vuejs.org/guide/built-ins/suspense.html) displays fallback content while waiting for async components to resolve. On Lynx, `<Suspense>` works with both async `setup()` (top-level `await` in `<script setup>`) and `defineAsyncComponent` for deferred loading.

:::tip Code-splitting
`defineAsyncComponent(() => import('./X.vue'))` emits webpack async chunks that need Lynx's lazy-bundle runtime (`lynx.requireModuleAsync` / `lynx.loadLazyBundle`). Those APIs are not available in Lynx Web Preview, so the docs example uses delayed promises over statically imported components instead — the Suspense fallback path is the same.
:::

<Go example="suspense" defaultFile="src/App.vue" defaultEntryName="main" />

## Transition

Vue's [`<Transition>`](https://vuejs.org/guide/built-ins/transition.html) and [`<TransitionGroup>`](https://vuejs.org/guide/built-ins/transition-group.html) components apply enter/leave animations when elements are inserted or removed.

`<Transition>` is **fully supported** — CSS transitions, CSS animations, `appear`, `mode`, JS hooks, and transitions with or without an explicit `:duration` prop all work. Since [#248](https://github.com/Huxpro/vue-lynx/issues/248) (v0.5), Vue Lynx also follows Vue's persisted transition behavior for `v-show`: enter and leave hooks run on every visibility change, and `display: none` is applied only after the leave animation finishes. Patterns such as drawers, sheets, and popovers behave consistently with official Vue on both Web and native Lynx.

Without `:duration`, Vue Lynx waits for the real `transitionend`/`animationend` event (same primary path as Vue DOM). A bounded fallback cleanup ([#286](https://github.com/Huxpro/vue-lynx/issues/286)) unregisters stranded handlers if a transition is interrupted before the event fires.

:::info Remaining limitation (`<TransitionGroup>` only)
Move (FLIP) animations in `<TransitionGroup>` are not supported — `getBoundingClientRect()` is unavailable from the background thread. Enter and leave transitions for list items still work.
:::

Scroll to **9. Registry cleanup** in the example below to see a no-`duration` `<Transition>` under rapid interruption: the event-registry counter climbs while hammering, then returns to baseline after stop.

<Go example="transition" defaultFile="src/App.vue" defaultEntryFile="dist/transition.lynx.bundle" />

## KeepAlive

Vue's [`<KeepAlive>`](https://vuejs.org/guide/built-ins/keep-alive.html) caches inactive component instances instead of destroying them. When a component is toggled back in, its state is preserved. The `include`, `exclude`, and `max` props are all supported. The `onActivated` and `onDeactivated` lifecycle hooks fire as expected.

<Go example="keep-alive" defaultFile="src/App.vue" />

## Options API

Vue 3 ships the Options API alongside the Composition API for backward compatibility.
By default, Vue Lynx enables it (`optionsApi: true` in the plugin), but you can disable it to reduce bundle size:

```ts title="lynx.config.ts"
pluginVueLynx({
  optionsApi: false, // tree-shakes the Options API runtime (~9 kB)
})
```

The example below uses `defineComponent` with `data()`, `computed`, `watch`, `methods`, and the `mounted` lifecycle hook:

<Go example="option-api" defaultFile="src/App.vue" />

## v-once / v-memo

[`v-once`](https://vuejs.org/api/built-in-directives.html#v-once) and [`v-memo`](https://vuejs.org/api/built-in-directives.html#v-memo) work in Vue Lynx without any configuration. On Lynx a cache hit skips the whole cross-thread op batch for that subtree — prefer `v-once` for never-changing content, and `v-memo` when a subtree should update only for a short dependency list (common in `v-for` rows).

<Go example="v-once-memo" defaultFile="src/App.vue" />

For render functions, Vue's `withMemo` helper (what the compiler emits for [`v-memo`](https://vuejs.org/api/built-in-directives.html#v-memo)) is re-exported from `vue-lynx`.

## Teleport

Vue's [`<Teleport>`](https://vuejs.org/guide/built-ins/teleport.html) moves a template fragment to a different place in the UI tree. Vue Lynx supports it for `to="#id"` string selectors via a background-thread `idRegistry` lookup — the same pattern as a modal rendered at the page root while its trigger lives deeper in the component tree.

:::warning Caveats
Direct element refs and non-ID selectors (e.g. `to=".class"` or `to="body"`) are not yet supported. Give the destination an `id` and target it with `to="#that-id"`.

The target element must already exist when `<Teleport>` mounts — place the `id` host earlier in the tree than the `<Teleport>` (or outside the component that owns it). Vue cannot resolve a target that is created by the same render as the teleport.
:::

The example below shows a modal teleported to `#overlay-root`, plus reactive content with the `disabled` prop:

<Go example="teleport" defaultFile="src/App.vue" />

## The `<page>` Top-Level Node

Every Lynx screen has one native [`<page>`](https://lynxjs.org/api/elements/built-in/page) root. Vue Lynx creates it automatically; write an explicit `<page>` only when you need to bind a class, style, event, or ref to the root:

```vue
<template>
  <page class="app" :style="pageStyle" @tap="onPageTap">
    <view>...</view>
  </page>
</template>
```

An explicit `<page>` compiles to a transparent built-in component that applies attributes to the existing native page — it does not create a second one. Use at most one per screen, as the outermost element. Prefer Lynx Engine **3.8.1+** when using an explicit `<page>`.

## Unsupported Features

Some Vue built-in features are not yet adapted to the dual-thread native environment:

| Feature | Reason | Alternative |
|---------|--------|-------------|
| `<TransitionGroup>` move (FLIP) | `getBoundingClientRect()` is unavailable on the background thread | Enter/leave list transitions still work; animate layout changes with CSS or Main Thread Script if needed |
| `withKeys` key modifiers | No-op on native — Lynx's native runtime converts keyboard input to named events (e.g. `confirm`) before reaching JS, so `event.key` is never populated on iOS/Android. Works on web preview ([lynx-stack#2594](https://github.com/lynx-family/lynx-stack/pull/2594)). Native support requires an upstream runtime change. | Native: use `@confirm` directly on `<input>` |



---
url: /blog/announcing-vue-lynx.md
---

<BlogHeader />

Vue developers have wanted native for years. The ["Vue + Lynx = Vue Native"](https://x.com/danielkelly_io/status/1899746975588737407) tweet pulled 1.7k likes. The [Vue integration issue](https://github.com/lynx-family/lynx/issues/193) on our repo hit 1,600 upvotes — our biggest feature request ever. The demand was clear; the question was bandwidth.

When [Lynx](https://lynxjs.org/) open-sourced a year ago, [Evan You](https://x.com/youyuxi/status/1898663514581168173) and [Rich Harris](https://x.com/Huxpro/status/1927276405328429259) both shouted it out, but production-quality framework integration has always demanded serious engineering bandwidth. Then projects like [Vercel's web streams rewrite](https://vercel.com/blog/we-ralph-wiggumed-webstreams-to-make-them-10x-faster) and [Cloudflare's ViNext](https://blog.cloudflare.com/vinext/) showed how solo engineers, armed with AI, can ship what used to take a team. That changed the math for me.

Vue already has the foundation: a mature Custom Renderer API. I spent a weekend on it. One ~$1,400, 37-hour hackathon. It started with a design exploration: “Can Vue's Custom Renderer even work with dual-thread code splitting, and how?” By 3am Sunday I was debugging “Tap to increment doesn't work” with Claude. By Monday morning, I had [a working TodoMVC](https://x.com/Huxpro/status/2028672358912086524). I couldn't resist dropping a subtle subtweet, and it immediately took off on X.

## Introducing Vue Lynx

The next two weeks of evenings and weekends went into making it real: 160+ commits across ~180 sessions.

```text
▎ Week 1   ████████████░░░░░░░░  Runtime + Toolchain
▎ Week 2   ░░░░░░░░████████████  Docs + Examples + i18n
```

I could have shipped after week one. But if you know me, you know my principle:

> When things actually work, you let the demos do the talking.

Check [vue.lynxjs.org](https://vue.lynxjs.org/) for 20+ example apps running natively and on the web — you can try them without leaving your browser.

We cover the full Composition API, `<Transition>`, `<Suspense>`, and ecosystem integrations including Vue Router, Pinia, Tailwind CSS, and TanStack Query. We also ported Lynx's official tutorial (Waterfall Gallery and Swiper) to showcase native components and Main Thread Script for zero-latency gestures. A HackerNews clone brings them all together.

### Try It Today

```bash
npm create vue-lynx@latest
```

It's [open source](https://github.com/huxpro/vue-lynx), of course. If it sparked something, give it a Star! And give some love to the [Lynx Engine](https://github.com/lynx-family/lynx) and [Lynx Frontend Stack](https://github.com/lynx-family/lynx-stack) too. They are the shoulders we're standing on.

I'd love for the Vue and Lynx communities to build on it together. Issues, PRs, and feedback are all welcome.

## “Harness” Engineering

> You gotta use the hottest word after “AI”, “vibe”, and “agentic” — *harness*.

No humans were harmed to write code in the making of this project.

### Setting Up the Architecture for AI

There were two prior community efforts. The second, from the Vue Vine maintainer [@Shenqingchuan](https://x.com/Shenqingchuan), went impressively far, [even getting Main Thread Script demos running](https://x.com/Shenqingchuan/status/1996862232593129815). But both kept Vue on the main thread just like the Web. This works on Lynx, but it's not taking advantage of the [dual-thread architecture](https://lynxjs.org/blog/lynx-unlock-native-for-more#use-the-main-thread-responsibly-for-interactivity) Lynx is known for: offload the heavy framework re-rendering on background and ensure the native UI thread stays non-blocking and is only tapped when needed (with Main Thread Scripts).

This was the core architectural decision I validated on Day 1. In Vue Lynx, the entire Vue runtime runs on the Background Thread. A lightweight `ShadowElement` linked-list tree mirrors the native element tree in memory, and every DOM mutation gets serialized into a flat ops buffer shipped to the Main Thread in one batch per tick:

```text
┌──────────────────────────────────────────────────────┐
│                  Background Thread                   │
│  Vue 3 runtime · reactivity · lifecycle · your code  │
└──────────────┬──────────────────────▲────────────────┘
          ops  │                      │  events
               ▼                      │
┌──────────────────────────────────────┴───────────────┐
│                    Main Thread                       │
│  Native elements · layout · rendering · MTS handlers│
└──────────────────────────────────────────────────────┘
```

To keep the agent aligned with this dual-threaded architecture and stop it drifting toward the single-threaded Web model it defaults to, I embedded all [critical plans directly in the source tree](https://github.com/Huxpro/vue-lynx/tree/main/plans): design discussion notes, decision logs, and post-implementation learning as cross-session context. Each new session picks up where the last left off, inheriting our architectural constraints and the reasoning that shaped the code.

### Bridging the Vue Upstream Tests

The most critical investment in any AI-driven development is feedback. Ideally, to ensure conformance with official Vue, we'd reuse Vue's upstream test suite directly. But Vue's test suite assumes a single-thread DOM. How do you run it to test a dual-thread renderer?

Fortunately, Lynx already has the infrastructure for [dual-threaded testing environments](https://lynxjs.org/next/api/lynx-testing-environment/index.html#lynx-jstesting-environment). So we can rewire the suite to run through our dual-thread pipeline — BG `ShadowElement` → ops buffer → `syncFlush()` → MT `applyOps` → PAPI → jsdom — then let the agent grind until no remaining failures are fixable (effectively a [Ralph Loop](https://ghuntley.com/loop/)).

The result: 852 passed out of 949 upstream tests. Every failure is accounted for in a [skiplist](https://github.com/Huxpro/vue-lynx/blob/main/packages/upstream-tests/skiplist.json) with documented reasons, and all turned out to be negligible. See the [full report and skip analysis](https://github.com/Huxpro/vue-lynx/blob/main/packages/upstream-tests/README.md).

We also added our own tests for Lynx-specific surface area such as `<list>` elements, `bindtap` events, and Main Thread Scripting APIs. With the pipeline proven, I pushed further and forked the [7GUIs benchmark](https://vue.lynxjs.org/guide/7guis) from the official Vue docs as a stress test.

```text
                BG Thread  ┃  Main Thread
                           ┃
Vue → ShadowElement → Ops  ┃  PAPI → Lynx Engine → UI
                           ┃
├─ vue runtime-core ─┤     ┃
├─── vue runtime-dom ──────╂──┤
        ├── E2E Pipeline ──╂─────────────┤
                           ┃         ├── Agentic ───┤
```

### Agentic E2E Verification Loop

But those classic machinery tests can't catch real UI bugs that used to require human evaluation: a misaligned CSS layout, an interaction broken on a real device. For advanced Vue features like `<Transition>` and `<Suspense>`, you need to see them run and interact to verify the behavior.

With the right harnessing, writing examples isn't just demoing — they double as workloads that the agent can evaluate automatically. I wired up two execution environments: iOS Simulator via [Lynx DevTool MCP](https://lynxjs.org/next/ai/lynx-devtool-mcp.html)/CLI/Skill, and an agent-controlled browser via [Lynx for Web](https://lynxjs.org/next/guide/start/integrate-with-existing-apps?platform=web). The loop is simple: run an example in both, observe and verify the output, and let any regression trigger a fix. No human in the loop.

```text
┌──── Fix ◀─────────────────────────────────┐
│                                           │
▼                                           │
Example ──┬──▶ iOS Simulator ───┬──▶ Evaluate
          │    (DevTool MCP)     │
          │                      │
          └──▶ Lynx for Web ─────┘
               (agent-browser)
```

I started with Vue core features, where correctness is well-defined: the agent reads the official docs, writes an example, and checks whether the output conforms. Then I expanded the scope to ecosystem integrations: Vue Router, Pinia, TanStack Query, and Tailwind CSS.

For the final exams, I tried a different approach — one I'd later learn has a name: *differential evaluation*. I let the agent port existing applications and verify the output against the originals. The first used the canonical Vue HackerNews implementation as ground truth, running both the Web version and the Vue Lynx port with Lynx for Web side-by-side in the browser; the second used existing ReactLynx demos as reference, porting them to Vue Lynx and verifying parity on the iOS Simulator via Lynx DevTool MCP. The harness doesn't need to know what “correct” looks like in the abstract. It just needs the two outputs to agree.

| Ground Truth | Candidate | Environment |
| --- | --- | --- |
| Vue HackerNews (Web) | Vue Lynx port | Lynx Web (browser) |
| ReactLynx demos | Vue Lynx port | Lynx Native (Simulator) |

```text
                    ┌─────────────────────────────┐
       ┌────────────▶  ground truth ──▶       A   │
       │            │                         │   │
Input ─┤            │                      Compare ──▶ Divergence
       │            │                         │   │        │
       └────────────▶  Lynx (candidate) ──▶    B   │        ▼
                    └─────────────────────────────┘     Fix Loop
```

### The Bill

```text
┌──────────────────────────────────────────┐
│ The Bill (at Opus rate)                  │
├──────────────────────────────┬───────────┤
│ Input (3.8M tokens)          │ $      57 │
│ Output (6.8M tokens)         │ $     510 │
│ Cache Write (117.9M tokens)  │ $   2,211 │
│ Cache Read (2.5B tokens)     │ $   3,769 │
├──────────────────────────────┼───────────┤
│ TOTAL                        │ $   6,547 │
└──────────────────────────────┴───────────┘
```

The numbers tell a story. Output tokens — the code and text Claude actually *wrote* — account for just 8% of the cost. The other 92% is comprehension: re-reading the codebase, ingesting tool outputs, and re-processing conversation history across 31,700 API turns. That's 2.5 billion tokens of reading to produce 6.8 million tokens of writing — a 370:1 ratio. This is what “agentic” actually looks like at the billing level.

Was the “$6,500” API rate worth it? Claude [gifted me](https://x.com/Huxpro/status/2031973188440052119) the $200 Claude Max through [its Open Source program](https://x.com/Huxpro/status/2031973188440052119), thankfully.

## What's Next?

This project started as one person's nights-and-weekends effort. I'd love to explore with the Vue core team how we can shape the future of Vue on native together. Personally, and on behalf of the Lynx team, we're committed to supporting its growth.

Vue Lynx is pre-alpha. The architecture is solid, but Vue's API surface is large, and we haven't verified every corner of it.

* Features like `KeepAlive` and `Teleport` likely need runtime adaptations.
* `<style scoped>` and `v-model` on native inputs are solvable but not yet implemented.
* The Main Thread Script API currently reuses ReactLynx's directive-based design. A more Vue-idiomatic approach (like `<script main-thread setup>`) is worth exploring.
* Vue DevTools integration with the Lynx DevTool app.

And beyond Vue core, there's a massive Vue ecosystem waiting for us to adapt and grow on native.

The vision is simple: Vue developers should be able to ship native apps as naturally as they ship for the web today. We're not there yet, but the foundation is in place, and the path is clear.

If you've read this far: [try it](https://vue.lynxjs.org/). Build something. Tell us what's missing.

Oh, and by the way: [Lynx was initially created with Vue 2](https://x.com/Huxpro/status/2032279225479176229).

***

Originally published as an [X Article](https://x.com/Huxpro/status/2036993665965416601) on March 26, 2026.



---
url: /blog/index.md
---

<BlogList />



---
url: /index.md
---