Documentación para desarrolladores de Páginas
Documentación para desarrolladores de Páginas
Las páginas son la unidad de ensamblaje de nivel superior en FaceFlow.
Para usuarios técnicos, una Página no es un archivo de plantilla. Es un registro estructurado en tiempo de ejecución que vincula un diseño, secciones ordenadas, activos compartidos y sistemas empresariales opcionales en una sola experiencia publicable.
Responsabilidad principal
La capa de Página es responsable de:
- seleccionar la envoltura de diseño
- almacenar la composición ordenada de secciones
- vincular los valores de campos creados con los contratos reutilizables de componentes
- coordinar sistemas integrados como Formularios, Reseñas y Listas
- soportar flujos gobernados de edición, vista previa y publicación
Las Páginas deben orquestar. No deben convertirse en el lugar donde la lógica de diseño, las decisiones del esquema de componentes y las reglas comerciales puntuales se colapsen juntas.
Modelo de Página
Una Página típica combina:
- un diseño
- una lista ordenada de instancias de componentes
- secciones reutilizables opcionales con alcance de página
- experiencias de Formulario o Reseña integradas opcionales
- comportamiento dinámico de listas opcional
Conceptualmente:
{
"layout": "default-site",
"components": [
{
"component": "hero-banner",
"scope": "page",
"fields": {
"heading": "Build faster with FaceFlow",
"subheading": "Reusable sections for scalable websites"
}
},
{
"component": "testimonial-strip",
"scope": "layout"
}
]
}La implementación exacta del almacenamiento es interna. Lo que importa para los usuarios técnicos es el contrato: las Páginas ensamblan objetos reutilizables en lugar de poseer directamente código de plantilla sin procesar.
Ruta de renderizado
En tiempo de ejecución, la representación de una Página típicamente sigue este flujo:
- resolver la Página solicitada
- cargar el Diseño asignado
- resolver las secciones compartidas con alcance de sitio, diseño y página
- renderizar los Componentes ordenados con sus valores de campo
- renderizar sistemas dinámicos integrados como Listas, Formularios o Reseñas
- devolver el resultado final ensamblado
Una estructura simplificada se ve así:
<body>
{header}
{siteComponents}
<main>
{content}
</main>
{footer}
</body>La Página posee la orquestación de {content}. El Diseño posee la envoltura alrededor de ella.
Ejemplo de ensamblaje
Un ensamblaje de Página más explícito puede razonarse así:
{
"layout": "service-site-shell",
"components": [
{
"component": "hero-banner",
"scope": "page",
"fields": {
"heading": "Enterprise Security",
"summary": "Structured trust content for SaaS websites",
"ctaUrl": "/contact/"
}
},
{
"component": "lead-form",
"scope": "page",
"fields": {
"contactForm": "contact-sales"
}
}
]
}Este ejemplo es útil porque muestra a la Página poseyendo la composición y los valores de instancia, mientras que los contratos de Diseño y Componente permanecen separados.
Relación con diseños y componentes
Mantén estos límites estrictos:
- Diseño define la envoltura de la página
- Componente define un contrato de sección reutilizable
- Página ensambla una secuencia de componentes en una experiencia final
Si una Página empieza a asumir lógica estructural de la envoltura, el Diseño es demasiado débil.
Si una Página comienza a duplicar reglas de sección que deberían pertenecer a un Componente, la reutilización se está comprometiendo.
Ejemplo común de composición de página
default-site layout
-> hero-banner component
-> feature-grid component
-> lead-form component
-> faq-accordion componentEsa composición debe permanecer comprensible sin leer código personalizado. Si no lo es, la arquitectura generalmente está desviándose.
Contenido dinámico e interactivo
Las Páginas a menudo incluyen más que secciones estáticas. Casos comunes incluyen:
- un Componente de captura de clientes potenciales que integra un Formulario
- una sección de confianza que integra un modelo de Reseñas
- un archivo de recursos impulsado por una Lista
- Variables conscientes de la página reutilizadas en varias secciones
Ejemplo:
<section class="section-contact">
<div data-form-embed="enterprise-demo-request"></div>
</section>
<section class="section-proof">
<div data-review-embed="customer-success-reviews"></div>
</section>Por eso la revisión del diseño de la Página debe considerar la ruta completa en tiempo de ejecución, no solo la composición visual.
Límites de integración
En la revisión técnica, mantén estos límites estables:
- La Página decide qué sistemas reutilizables participan en la experiencia
- El Componente define cómo se renderiza una sección reutilizable
- Los modelos de Formulario y Reseña poseen el comportamiento de envío
- Las definiciones de Lista poseen el comportamiento dinámico de archivo
Si una Página comienza a llevar demasiados detalles de implementación, el modelo de objetos está desviándose.
Tipos de página y estrategia de cambio
No todas las Páginas deben tratarse de la misma manera.
- las páginas de campaña se optimizan para velocidad y variación controlada
- las páginas de servicio perennes se optimizan para reutilización y mantenimiento a largo plazo
- las páginas impulsadas por listas se optimizan para el crecimiento dinámico de contenido
- las páginas de confianza o conversión a menudo coordinan múltiples sistemas juntos
Los equipos técnicos deben elegir los activos circundantes adecuados para cada tipo en lugar de forzar cada Página en el mismo patrón.
Versionado, localización y portabilidad
Las Páginas son a menudo la unidad que los equipos:
- localizan entre idiomas
- restauran tras un cambio no deseado
- mueven entre entornos
- revisan antes de la publicación
Trata la Página como un activo operativo, no solo como un objetivo de salida visual.
Related feature references:
Lista de verificación para revisión técnica
- ¿La Página utiliza el Diseño correcto para su familia de páginas?
- ¿Los Componentes están ordenados y con el alcance intencional?
- ¿Los Formularios, Reseñas o Listas están integrados mediante contratos reutilizables en lugar de marcado codificado?
- ¿La Página depende de Variables o secciones compartidas donde se espera reutilización?
- ¿Un editor futuro comprendería la estructura de la Página sin necesidad de ingeniería inversa para las excepciones?
Anti-patrones
Evita estos patrones:
- marcado de envoltura específico de la página que debería pertenecer al Diseño
- marcado de sección libre repetido en muchas Páginas
- lógica de negocio oculta en contenido exclusivo de la página
- mezclar objetivos no relacionados en una sola Página solo porque ya está en vivo
- forzar un archivo dinámico en una composición de Página mantenida manualmente
Patrón de construcción de ejemplo
Para una página de aterrizaje de servicio típica:
Layout: service-site-shell
Page:
- hero-banner
- benefits-grid
- customer-logos
- review-strip
- demo-request-formEse patrón sigue siendo mantenible porque cada responsabilidad tiene un lugar claro.