Widgets y frameworks de vista
Cómo el CDN prepara y entrega widgets de Beyond escritos con React 19, Vue, Svelte o HTML simple: paquetes compilados por el bundler que declaran, controladores de framework, estilos adoptados dentro de la shadow root de cada widget y la hoja de estilos compartida de un paquete.
- Disponibilidad: Experimental
- Evidencia: Ejecución registrada
- Guía práctica
Estado inicial
Tienes una aplicación cuyo punto de entrada monta widgets de Beyond: elementos personalizados cuya vista está escrita con React 19, Vue, Svelte o HTML simple. Quieres que el CDN la prepare y la entregue, y quieres saber qué llega al navegador.
Nada de los widgets es especial para el contrato de entrega. Un widget es un módulo público, entregado en las mismas direcciones /m/…, resuelto por los mismos documentos y cargado con las mismas estrategias que cualquier otro módulo. Lo específico es cómo se compilan los módulos y cómo se aplican sus estilos.
Qué es un paquete y qué es un controlador
| Parte | Paquete | Qué hace |
|---|---|---|
| Widgets | @beyond-js/widgets |
Registra el elemento de cada widget, abre su shadow root, carga su módulo y adopta sus hojas de estilos |
| Controladores de framework | @beyond-js/react-19-widgets, @beyond-js/vue-widgets, @beyond-js/svelte-widgets |
Los objetos que montan, hidratan, refrescan y desmontan una vista de un framework. Un widget de HTML simple extiende directamente WidgetClientController de Widgets. |
| El runtime de desarrollo | @beyond-js/local-2026 (nombre provisional) |
Compone los módulos internos de un widget y aplica las actualizaciones de desarrollo |
| Los frameworks | react, react-dom, vue, svelte |
Paquetes npm comunes |
Tu aplicación depende de ellos como de cualquier paquete. Se resuelven en el grafo de la aplicación y se fijan con él; consulta El registro y el grafo fijado.
Cada paquete se compila con el bundler que declara
Widgets, los controladores y un paquete de widgets tuyo declaran beyond.publication con la forma source y nombran su bundler (beyond.bundler, el bundler ts en estos casos). El CDN compila cada uno de sus módulos públicos con ese bundler, exactamente como lo hace el servidor de desarrollo: los componentes .vue y .svelte, las hojas de estilos Sass y Tailwind y el registro del elemento los produce él, no un compilador genérico. Consulta Publica fuentes de Beyond en npm.
Los frameworks son paquetes npm comunes, compilados de a un módulo público por vez. Cuando varias subrutas públicas de un paquete comparten estado interno, como el runtime de Svelte, se entregan de modo que la página tenga una sola copia de ese estado. Los widgets de varios frameworks en una página cargan cada framework una sola vez.
Los estilos se quedan dentro de cada widget
Un navegador nunca aplica una hoja de estilos por una extensión, así que la entrega indica quién aplica cada una:
- Un widget adopta, dentro de su propia shadow root, su propia hoja de estilos y las hojas de estilos de los módulos públicos que importa, de forma transitiva, deteniéndose en otro widget, que tiene su propia raíz. Ninguna regla de un widget llega a la página, y ninguna regla de la página llega a un widget.
- El documento enlaza solo las hojas de estilos de los módulos que carga fuera de cualquier widget.
- Un módulo selecciona la hoja de estilos de otro módulo público con
.css:import '@example/ui/theme.css'. Es una relación de estilo, no un import de código; consulta Seleccionar una salida.
La hoja de estilos compartida de un paquete
Un paquete que publica el módulo de estilo ./global tiene una hoja de estilos que comparten todos sus widgets:
{ "exports": { "./global": "./global.css" } }Cada widget de ese paquete la adopta dentro de su raíz, antes de sus propias hojas, así que sus reglas pueden usar :host y llegar al árbol shadow del widget. Preparar una aplicación que usa un solo widget del paquete prepara también la hoja; un widget de otro paquete no la adopta; un paquete que no publica ./global no produce ninguna solicitud de ella. Consulta La hoja de estilos compartida de un paquete.
Ambos modos de carga, y el servidor
Las cuatro familias se renderizan en releases de módulos ES nativos y en releases SystemJS. SystemJS necesita el extra de espacios de nombres que lleva el loader.js de cada release: sin él, el módulo de efectos secundarios de Svelte deja a un importador sin espacio de nombres. Consulta SystemJS.
Un módulo widget que también compila para Node se renderiza en un servidor mediante su controlador de servidor. Un host de Node.js lo carga con BEE Node, desde un servidor de desarrollo o desde la base de un release; consulta Crear un entorno de ejecución modular.
Reglas que conviene mantener
- Un
name@versionpor aplicación. El runtime registra un módulo cargado por nombre, versión y subruta, así que una aplicación no puede tener una versión de un paquete desde dos fuentes. - Mantén el widget, su controlador y su vista en los módulos públicos y archivos internos tal como los declara el paquete. Un cargador que reescribe un import público como la ruta a un archivo interno rompe el módulo con el que se compiló el widget.
Siguiente
Escribe un widget: Crear un widget Beyond. Integra otro framework: Integrar un framework de vistas. Coloca uno en una página que no se construyó con Beyond: Incrustar un widget en una página existente.