Обзор

Что такое Vue Remote?

@omnicajs/vue-remote — это библиотека синхронизации рендеринга для extension-экосистем на Vue 3.

Она позволяет хост-продукту рендерить UI, который описывается в изолированном remote-runtime. Сторона remote объявляет деревья компонентов, а сторона host контролирует, какие компоненты реально разрешены и как они отрисовываются.

Когда стоит использовать Vue Remote?

Используйте библиотеку, когда хотите превратить приложение в extension-платформу:

• ваш продукт владеет host-runtime и границами UI;
• сторонние команды разрабатывают extensions независимо;
• UI расширений должен работать изолированно (например, в iframe или worker-runtime);
• рендеринг все равно должен интегрироваться в UI-контракты, контролируемые хостом.

Базовый пример

На минимальном уровне host и remote обмениваются одним render-channel:

// host
const provider = createProvider({ VButton, VInput })
const receiver = createReceiver()
// render <HostedTree provider={provider} receiver={receiver} />
// then call remote.run(receiver.receive, hostBridge)

// remote
const root = createRemoteRoot(channel, { components: ['VButton', 'VInput'] })
await root.mount()
createRemoteRenderer(root).createApp(RemoteApp).mount(root)

Далее remote-компоненты передают intent через props/events, а host сохраняет контроль над разрешенными возможностями рендеринга.

Почему именно Vue Remote?

Модель дает хост-продукту платформенный контроль, не заставляя авторов extensions погружаться во внутренности host:

• host-команды определяют границы возможностей через component-контракты provider;
• авторы extensions фокусируются на продуктовых фичах и UI intent;
• изоляция runtime снижает случайную связанность и делает обновления безопаснее;
• несколько remote-extensions могут сосуществовать, разделяя единый UX-контракт хоста.

Более реалистичный пример

В production-продукте extension обычно нужен не только render sync, но и доступ к бизнес-данным:

1. Render channel: remote рендерит компоненты, одобренные host, через @omnicajs/vue-remote.
2. Business bridge: remote вызывает API продукта через отдельный контракт (hostBridge).
3. Capability policy: host решает, что конкретному extension разрешено рендерить и вызывать.

Это разделение сделано намеренно: lifecycle рендера остается стабильным, даже когда бизнес-контракты меняются.

Ключевая идея

Взаимодействуют два runtime:

1. Host runtime: регистрирует разрешенные компоненты через createProvider(...), получает обновления remote-дерева через createReceiver(), рендерит HostedTree.
2. Remote runtime: создает синхронизированный root через createRemoteRoot(...), использует createRemoteRenderer(...), ссылается на компоненты, отданные host, через defineRemoteComponent(...).

Обновления проходят через channel transport (обычно @remote-ui/rpc).

Что покрывает библиотека

В scope:

• синхронизированный рендер UI-дерева между host и remote;
• allowlist компонентов под контролем host;
• контракт props/events/slots через границу runtime;
• native remote-теги (html, svg, mathml), зеркалируемые в host render tree.

Вне scope:

• протокол бизнес-API продукта;
• auth, permissions, billing, marketplace, discovery расширений;
• packaging, publishing и lifecycle-policy расширений;
• продукт-специфичное governance и управление доверием.

Эти возможности должны жить в окружающем платформенном tooling.

Что это значит для реальной экосистемы

В production-экосистеме расширений обычно есть три отдельных слоя:

1. Слой синхронизации рендера (@omnicajs/vue-remote).
2. Слой product bridge (бизнес-методы и data-контракты).
3. Платформенный слой (permissions, discovery, monetization, governance).

Разделение слоев уменьшает связанность и позволяет версионировать их независимо.

Сравнение с прямым embed-подходом

По сравнению с прямым встраиванием стороннего UI-кода в host-runtime:

• Vue Remote усиливает контроль хоста над разрешенной component surface;
• библиотека предпочитает явные контракты вместо неявного доступа к внутренностям host;
• подход лучше подходит для изолированных runtime, где remote не владеет реальным DOM.

Компромисс в том, что нужно аккуратно проектировать граничные контракты и правила сериализации.

Ментальная модель

Думайте о стороне remote как о producer декларативного UI intent, а не как о прямом владельце DOM.

• Remote-код композитит UI и отправляет intent.
• Host-код применяет capability-ограничения, валидирует границы и делает реальный рендеринг.
• Payload, который пересекает runtime-границы, должен оставаться сериализуемым.

Это разделение делает extension-экосистемы безопаснее и проще в развитии.

Когда это плохой выбор

@omnicajs/vue-remote может быть избыточным, если:

• вы контролируете обе стороны и вам не нужна изоляция runtime;
• вам не нужны границы компонентов под контролем host;
• простая локальная component-библиотека уже решает вашу задачу интеграции.

Также этого может быть недостаточно, если вам уже сегодня нужен полный runtime плагин-платформы. В таком случае используйте библиотеку как render-core и добавляйте вокруг нее платформенные сервисы.

Типичный flow использования

1. Host-продукт запускает оболочку extension-runtime и render receiver.
2. Remote-extension экспортирует API run/release.
3. Host передает render channel (и опциональный business bridge).
4. Remote монтируется и рендерит через синхронизированные channel-updates.
5. Сессия завершается вызовом release().

Транспорт-независимую схему смотрите в разделе Обзор, а iframe-специфику в Интеграция через iframe.

Что читать дальше

• Если вы только знакомитесь с моделью: Быстрый старт.
• Если проектируете host-контракты: Компоненты хоста.
• Если разрабатываете UI расширения: Компоненты remote.
• Если проектируете runtime-архитектуру: Обзор.
• Если планируете iframe-интеграцию: Интеграция через iframe.