Resumen del componente
Mas Consents es un frontend alojado que permite a un cliente revisar y guardar declaraciones de consentimiento.
Está pensado para flujos expuestos a cliente donde una aplicación necesita mostrar, recoger o actualizar consentimientos sin implementar su propia UI de consentimientos.
Las aplicaciones consumidoras embeben el componente y construyen su URL con el contexto del cliente, el token de autenticación y el flujo de negocio que se debe cargar. El componente llama al backend de Consents, renderiza las declaraciones de consentimiento y comunica el resultado a la aplicación host.
Qué proporciona el componente
Mas Consents proporciona:
- una UI de consentimientos alojada y preparada para embeberse en iframe, popup o WebView
- llamadas de carga y submit contra el backend de Consents
- gestión de idioma para los locales soportados
- mensajes de ciclo de vida para estados de carga, finalización y error
- personalización visual y de comportamiento opcional mediante configuración JSON
Contrato básico de integración
La aplicación host proporciona el contexto de ejecución. Mas Consents se encarga de la UI de consentimientos y de las llamadas necesarias para el flujo embebido.
| Área | El host proporciona | El componente gestiona |
|---|---|---|
| Autenticación | Un token acotado para el flujo embebido de consentimientos | Envía el token al backend de Consents como autenticación bearer |
| Contexto de cliente | Parámetros de URL customerId, brand y sector | Los usa para cargar y guardar los consentimientos correctos |
| Selección del flujo | Uno o varios valores view, y opcionalmente choice | Solicita el conjunto de consentimientos de ese flujo |
| Localización | lang, y opcionalmente locales | Selecciona el idioma inicial y los idiomas disponibles |
| Gestión del resultado | Listeners para mensajes de finalización y error | Emite mensajes de ciclo de vida hacia el host |
| Personalización | Configuración JSON opcional cuando se solicite | Aplica tema, opciones de UI y sobrescrituras de tokens |
Modelo de integración
Aplicación host
-> construye la URL del iframe / WebView
-> opcionalmente escucha CONSENTS_CONFIG_REQUIRED
-> opcionalmente envía SET_CONFIG
-> escucha eventos loaded, completed y error
mas-consents
-> lee parámetros de URL
-> carga /config.json
-> inicializa el bridge
-> renderiza la UI Custom
-> llama al backend
-> informa al host con eventos de ciclo de vidaResponsabilidades del host
La aplicación host debe:
- proporcionar los parámetros de URL necesarios para el flujo objetivo
- aportar un token válido para el flujo embebido de consentimientos
- escuchar eventos de finalización y error
- decidir qué hacer tras el submit del cliente o cuando el componente reporta un error
- enviar configuración JSON solo cuando quiera personalizar el componente
La aplicación host no necesita conocer el árbol interno de declaraciones, la implementación del backend de Consents ni la configuración de desarrollo local para integrar el componente. Esos detalles están cubiertos en la referencia técnica del IDP.
Comportamiento de runtime
El runtime tiene un único camino de renderizado: AppCustomTheme montando ConsentsCoreCustom.
El componente Legacy anterior ya no forma parte del flujo de la aplicación.
enableCustomConfig no selecciona otra implementación del componente.
Solo controla si el componente renderiza inmediatamente con valores por defecto o si espera un mensaje SET_CONFIG antes de renderizar.