El contenido y el código van por separado. Se encuentran cuando una página se renderiza.
Un proyecto Uniweb tiene dos partes. El sitio es contenido. La foundation es React. Un runtime ligero las une allí donde se renderiza una página: en el build, en el host y en el navegador. Esta página muestra cómo se ve eso en un proyecto real, tanto si trabajas con un agente como por tu cuenta, en tus sitios o en los de tus clientes.
Entra Markdown. Sale un objeto tipado.
Los autores escriben cada sección como un archivo Markdown. Antes de que ningún componente lo vea, el archivo se convierte en un objeto con campos con nombre: cadenas y arrays, nunca null. Los encabezados marcan la estructura, no el tamaño.
---
type: Hero
theme: dark
---
# Ship the site this week
## Not every change needs a developer
We help small teams publish.
[Get started](/start)content = {
title: 'Ship the site this week',
subtitle: 'Not every change needs…',
paragraphs: ['We help small teams…'],
links: [{ label: 'Get started', … }],
items: [],
// images, icons, data, …
}$ uniweb inspect pages/home/hero.md
import { H1, H2, P } from '@uniweb/kit'
export default function Hero({ content }) {
return (
<>
<H1 text={content.title} />
<H2 text={content.subtitle} />
<P text={content.paragraphs} />
</>
)
}Ese es el componente completo. No tiene elemento contenedor, ni comprobaciones de null, ni lógica de tema, ni textos fijos en el código.
Tipos de sección ligeros. React normal detrás.
Un tipo de sección es la parte que los autores pueden nombrar. Lee los parámetros, elige un componente y le pasa props simples. Todo lo que hay detrás es React normal: cualquier paquete, cualquier librería, cualquier patrón.
Un solo tipo para el autor, tantas versiones como necesite el diseño.
const workers = { slider: SliderHero, contact: ContactHero }
export default function Hero({ content, params, block }) {
const Worker = workers[params.variant] || SliderHero
return (
<Worker
title={content.title}
links={content.links}
images={content.images}
block={block}
/>
)
}meta.js es la interfaz.
Cada tipo de sección declara lo que lee y qué parámetros acepta. Ese único archivo fija los valores por defecto, crea los controles del editor visual y le dice a un agente qué existe.
Cada parámetro que declaras es algo que un autor puede cambiar sin ti.
export default {
title: 'Feature Grid',
content: {
title: 'Heading',
items: { label: 'Cards [3-6]' },
},
params: {
columns: { type: 'number', default: 3 },
variant: {
type: 'select',
options: ['default', 'centered'],
default: 'default',
},
},
}El runtime hace esto una vez, para todas las secciones.
Lo que te queda por escribir es la lógica de renderizado.
meta.js: los registros llegan en content.data, prerenderizados. Sin fetch en un effect.llms.txt y una copia en Markdown de cada página, a partir del mismo contenido.Un proyecto normal, en dos paquetes.
El sitio y la foundation son paquetes separados en un mismo workspace. Instala cualquier librería en la foundation como en cualquier proyecto React. La configuración del build es cosa del CLI.
Una foundation puede servir a muchos sitios.
Crear
Un proyecto a partir de una plantilla, con su manual para agentes.
$ npx uniweb@latest create my-site --template marketingEjecutar
El servidor de desarrollo muestra su dirección, y la página se actualiza al guardar.
$ cd my-site && pnpm install && pnpm devComprobar
Mira en qué se convierte un archivo de sección antes de que se renderice nada.
$ npx uniweb inspect site/pages/home/hero.mdPublicar
En línea en el hosting de Uniweb, y en el editor visual para cualquiera con quien trabajes.
$ npx uniweb publishCon un agente, o por tu cuenta.
Hoy la mayoría de los desarrolladores trabaja con un agente, y Uniweb está hecho para eso, pero nada en él lo exige. El proyecto son archivos normales, y el manual que trae cada proyecto se lee igual de bien para una persona que para un agente.
AGENTS.mdEl manual del proyecto: cómo funciona el framework, dónde te engañan los hábitos de otros frameworks y cómo comprobar tu trabajo.uniweb guideEl resto del manual, un tema a la vez, para la versión que usas.uniweb.io/docsGuías y referencia, con un índice para agentes en llms.txt.Comandos que te dicen la verdad.
Tú y tu agente usan los mismos. No hay que adivinar nada: el listado de carpetas es el catálogo, e inspect muestra en qué se convirtió un archivo.
uniweb createCrea un proyecto a partir de una plantilla.uniweb devSirve el sitio en local con recarga en vivo.uniweb inspectMuestra la estructura analizada de un archivo o una página.uniweb doctorComprueba la configuración del proyecto.uniweb validateComprueba los registros contra sus esquemas.uniweb guideLee el manual de la versión que usas.uniweb push / pullSincroniza con el editor visual. Los cambios de los autores vuelven como un commit.uniweb publishPublica en Uniweb Cloud.uniweb deployDespliega en un hosting estático, como Cloudflare Pages o Netlify.De un sitio a una aplicación.
El mismo proyecto crece más allá de las páginas. Los registros se sirven en vivo, los servicios se activan con una línea en site.yml, y un sitio puede tener su propio backend, con cuentas y pagos. Nada de esto exige reescribir: la misma foundation funciona en un sitio con estos servicios y en uno sin ellos.
records/<schema>/, pedidos por nombre en queries.yml. Se sirven en vivo en el hosting de Uniweb, se compilan en el build en un hosting estático y se editan en el editor visual como formularios.services: en site.yml.@uniweb/api y el servicio backend del sitio, con un backend simulado para uniweb dev.Tus sitios, o los de tus clientes.
Uniweb se adapta a las dos formas de trabajar.
Archivos, la app, o ambos
Mantén el contenido en tus archivos y en Git, lleva el sitio al editor visual, o trabaja en ambos, y publica cuando esté listo.
$ uniweb publishTu foundation, sus sitios
Registra la foundation, y tus clientes componen sus sitios en el editor visual con tus tipos de sección y las opciones que les diste. Tú la sigues mejorando y publicas nuevas versiones.
$ uniweb registerDos formas de publicar.
Recomendamos Uniweb Cloud desde las primeras páginas de un sitio. Un sitio sencillo cuesta menos ahí, porque cada servicio tiene su propio precio; cada publicación mantiene el sitio en el editor visual, listo para editar; y el sitio crece hasta todo lo que puede hacer un sitio Uniweb sin cambios. Un hosting estático es gratuito, y sirve lo que produce un build.
Uniweb Cloud
Páginas prerenderizadas justo a tiempo en el edge, con datos en vivo. El sitio en el editor visual en cada publicación. Registros en vivo, formularios, analíticas, cuentas y pagos cuando los necesites.
$ uniweb publishVer preciosCualquier hosting estático
Despliega con un solo comando en Cloudflare Pages, GitHub Pages, Netlify, Vercel o S3 con CloudFront, o exporta una carpeta para cualquier otro hosting. Los cambios de la app le llegan con un nuevo build, y el contenido en vivo, los formularios, las analíticas y las cuentas necesitan servicios propios.
$ uniweb deploy --host=cloudflare-pagesEmpieza un proyecto.
$ npm create uniwebO déjaselo a tu agente. Cada proyecto incluye un AGENTS.md que le explica cómo funciona el framework y cómo comprobar su propio trabajo.