Server-driven UI

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

El cliente conoce un catálogo de componentes; el servidor envía estructura y datos mediante un contrato. Solo las capacidades ya implementadas pueden cambiar sin actualizar la aplicación.

Ejemplo de uso

Enviar un documento con bloques de título, promoción y botón, identificados por tipo y versión. Si un cliente desconoce un bloque, usa un comportamiento de compatibilidad definido.

Contrato de pantalla

{
  "schemaVersion": 3,
  "screen": "inicio",
  "sections": [
    {
      "type": "hero.v2",
      "id": "promo-octubre",
      "data": {
        "titulo": "Crédito de libre inversión",
        "subtitulo": "Hasta 24 meses"
      },
      "action": {
        "type": "navigate",
        "target": "simulador",
        "params": { "producto": "libre" }
      }
    },
    {
      "type": "credito.resumen.v1",
      "id": "creditos-activos",
      "data": {
        "creditoId": "42",
        "proximaCuota": "2026-11-05",
        "valor": 250000
      }
    },
    {
      "type": "banner.v1",
      "id": "aviso-mora",
      "visibleIf": "cliente.diasMora > 0",
      "data": { "texto": "Tienes una cuota vencida" },
      "action": { "type": "navigate", "target": "pagos" }
    }
  ],
  "fallback": { "unknownSection": "skip" }
}

Elemento	Propósito
type versionado	El cliente sabe qué componente nativo usar; v2 convive con v1
data	Contenido del componente, sin lógica de presentación
action	Catálogo cerrado de acciones permitidas (navegar, llamar API, abrir enlace)
fallback	Qué hacer con secciones desconocidas por clientes antiguos

Negociación de capacidades

El cliente envía su versión y los componentes que soporta (X-UI-Capabilities: hero.v1,hero.v2,credito.resumen.v1), y el servidor compone la pantalla solo con piezas compatibles. Así, versiones antiguas de la app siguen funcionando mientras las nuevas reciben componentes mejorados.

Qué se puede cambiar sin publicar y qué no

Sin nueva versión de la app	Requiere publicar en la tienda
Orden, presencia y contenido de secciones	Un tipo de componente nuevo
Textos, imágenes, promociones por segmento	Una acción nueva no contemplada en el catálogo
Experimentos A/B de composición	Cambios de navegación estructural
Ocultar una sección problemática	Acceso a nuevas APIs del dispositivo

Coste y riesgos

• Plataforma: servidor de composición, catálogo de componentes, herramientas de vista previa y pruebas. Es una inversión que se justifica con equipos y frecuencia de cambios altos.
• Rendimiento: la pantalla depende de una respuesta del servidor; usa caché local y una versión empaquetada por defecto para arranque sin conexión.
• Seguridad: valida el payload, no ejecutes código remoto y limita las acciones a un catálogo seguro.
• Políticas de las tiendas: cambiar contenido y composición es aceptado; cambiar la funcionalidad esencial de la app de forma remota puede no serlo.
• Pruebas: pruebas de contrato del esquema y pruebas visuales de cada componente con datos extremos.

Encaja especialmente en pantallas de inicio, ofertas y onboarding de apps de React Native o nativas, y se combina bien con feature toggles y experimentación (ABsmartly).

Criterios de implementación

Validar payloads y acciones permitidas, incluir caché y fallback sin conexión y medir latencia. Aplicar la técnica donde la frecuencia de cambios justifique su coste de plataforma.