Introducción

¿Qué es Vue Remote?

@omnicajs/vue-remote es una biblioteca de sincronización de render para ecosistemas de extensiones basados en Vue 3.

Permite que un producto host renderice UI descrita por un runtime remoto aislado. El lado remoto declara árboles de componentes, y el lado host controla qué componentes están realmente permitidos y cómo se renderizan.

¿Por qué usar Vue Remote?

Usa esta biblioteca cuando quieras convertir una aplicación en una plataforma de extensiones:

• tu producto posee el runtime host y los límites de la UI;
• equipos de terceros desarrollan extensiones de forma independiente;
• la UI de las extensiones debe ejecutarse aislada (por ejemplo en un iframe o en un worker runtime);
• el renderizado debe seguir integrándose en contratos de UI controlados por el host.

Ejemplo básico

En el caso mínimo, host y remoto intercambian un canal de render:

// 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)

A partir de ahí, los componentes remotos emiten intención mediante props/eventos, mientras el host conserva el control sobre las capacidades de render permitidas.

¿Por qué Vue Remote?

Este modelo da al producto host control de plataforma sin obligar a los autores de extensiones a entrar en los detalles internos del host:

• Los equipos host definen los límites de capacidades mediante contratos de componentes del provider.
• Los autores de extensiones se concentran en funcionalidades del producto e intención de UI.
• El aislamiento del runtime reduce el acoplamiento accidental y hace las actualizaciones más seguras.
• Varias extensiones remotas pueden coexistir compartiendo un mismo contrato UX del host.

Un ejemplo más realista

En un producto de producción, una extensión suele necesitar tanto sincronización de render como acceso a capacidades de negocio:

1. Canal de render: el remoto renderiza componentes aprobados por el host mediante @omnicajs/vue-remote.
2. Puente de negocio: el remoto llama a APIs del producto mediante un contrato separado (hostBridge).
3. Política de capacidades: el host decide qué puede renderizar y llamar cada extensión.

Esta separación es intencional: el ciclo de vida del render se mantiene estable incluso cuando evolucionan los contratos de negocio.

La idea central

Colaboran dos runtimes:

1. Runtime host: registra los componentes permitidos con createProvider(...), recibe actualizaciones del árbol remoto con createReceiver(), renderiza HostedTree.
2. Runtime remoto: crea una raíz sincronizada con createRemoteRoot(...), usa createRemoteRenderer(...), referencia los componentes expuestos por el host mediante defineRemoteComponent(...).

Las actualizaciones viajan por un transporte basado en canales, normalmente @remote-ui/rpc.

Qué cubre esta biblioteca

Dentro del alcance:

• renderizado sincronizado del árbol de UI entre host y remoto;
• allowlist de componentes controlada por el host;
• contrato de props/eventos/slots a través del límite entre runtimes;
• etiquetas remotas nativas (html, svg, mathml) reflejadas en el árbol de render del host.

Fuera del alcance:

• protocolo de APIs de negocio del producto;
• auth, permissions, billing, marketplace y descubrimiento de extensiones;
• empaquetado, publicación y política de ciclo de vida de extensiones;
• gobernanza y gestión de confianza específicas del producto.

Estas capacidades deben vivir en el tooling de plataforma que rodea a la biblioteca.

Qué significa esto en ecosistemas reales

Un ecosistema de extensiones en producción suele tener tres capas separadas:

1. Capa de sincronización de render (@omnicajs/vue-remote).
2. Capa de puente del producto (métodos de negocio y contratos de datos).
3. Capa de plataforma (permissions, discovery, monetization, governance).

Mantener estas capas separadas reduce el acoplamiento y permite versionarlas de forma independiente.

Comparación con un enfoque de embed directo

Frente a incrustar directamente código de UI de terceros dentro del runtime host:

• Vue Remote mejora el control del host sobre la superficie de componentes permitida.
• Favorece contratos explícitos en lugar de acceso implícito a los detalles internos del host.
• Funciona mejor en runtimes aislados donde el remoto no posee el DOM real.

La contrapartida es que debes diseñar con cuidado los contratos de frontera y las reglas de serialización.

Modelo mental

Piensa en el lado remoto como un productor declarativo de intención de UI, no como el dueño directo del DOM.

• El código remoto compone la UI y emite intención.
• El código host aplica las capacidades, valida los límites y realiza el render real.
• Los payloads entre runtimes deben permanecer serializables allí donde los datos cruzan el canal.

Esta separación hace que los ecosistemas de extensiones sean más seguros y más fáciles de evolucionar con el tiempo.

Cuándo no encaja bien

@omnicajs/vue-remote puede ser innecesario si:

• controlas ambos lados y no necesitas aislamiento de runtime;
• no necesitas límites de componentes controlados por el host;
• una simple biblioteca local de componentes resuelve tu integración.

También puede quedarse corto si hoy necesitas una plataforma completa de plugins. En ese caso, mantén esta biblioteca como núcleo de render y añade alrededor los servicios de plataforma.

Flujo de uso típico

1. El producto host inicia el shell del runtime de extensiones y el render receiver.
2. La extensión remota expone la API run/release.
3. El host proporciona el canal de render y, opcionalmente, un contrato de puente de negocio.
4. El remoto monta y renderiza mediante actualizaciones de canal sincronizadas.
5. La sesión termina con release().

Consulta el cableado agnóstico al transporte en Resumen y los detalles específicos de iframe en Integración con iframe.

Qué leer a continuación

• Si eres nuevo en el modelo: Primeros pasos.
• Si diseñas contratos del host: Componentes del host.
• Si construyes UI remota de extensión: Componentes remotos.
• Si planificas la arquitectura de runtime: Resumen.
• Si planificas integración con iframe: Integración con iframe.