Entrevista de Frontend: ¿Cómo diseñarías un fallback de la Badging API para mensajes no leídos en una PWA?

Planteamiento y alcance

Una PWA instalada debería mostrar un contador de no leídos en el ícono de su aplicación. Explica la detección de capacidades, los flujos de actualización y borrado para la Badging API, y el fallback cuando un navegador no la soporta o la llamada falla.

Qué evalúa el entrevistador

• Saber que navigator.setAppBadge() y clearAppBadge() requieren un contexto seguro compatible.
• Distinguir las capacidades de WorkerNavigator en la página y en el Service Worker, y manejar los fallos de Promise.
• Tratar la API como una sugerencia de presentación en lugar de la fuente de la verdad para los datos de no leídos.
• Proporcionar fallbacks perceptibles como el título, contadores dentro de la app y texto de estado accesible, a la vez que se limitan (throttle) las actualizaciones.

Preguntas de clarificación

1. ¿El objetivo es el ícono de una PWA instalada o una pestaña común del navegador?
2. ¿Qué es lo autoritativo para el conteo de no leídos, y cómo se mantienen consistentes las recargas y las múltiples pestañas?
3. ¿Se requieren actualizaciones sin conexión, notificaciones push en segundo plano y combinaciones específicas de navegador/SO?
4. ¿Cómo deberían recibir el mismo estado los usuarios de lectores de pantalla, y deberían los contadores limitarse (cap) u ocultarse parcialmente?

Estructura de respuesta en 30 segundos

Trataría el distintivo como una capa de presentación opcional. En HTTPS, detectaría navigator.setAppBadge, lo actualizaría a partir del conteo de no leídos sincronizado, verificaría los fallos de Promise y llamaría a clearAppBadge al llegar a cero. Si no es compatible o falla, mantendría un contador dentro de la app, un indicador en el título o favicon, y texto de estado accesible. La página y el Service Worker comparten un protocolo de conteo versionado, las actualizaciones se limitan y la lectura de mensajes nunca depende del distintivo.

Análisis detallado paso a paso

1. Definir los límites de capacidad y visualización

La Badging API está dirigida a los íconos de aplicaciones web instaladas; el Working Draft del W3C de 2026 expone setAppBadge y clearAppBadge en Navigator y WorkerNavigator. Es una capacidad de contexto seguro, y un agente de usuario puede omitirla o cambiar la forma en que se muestra un valor, por lo que no se pueden prometer números exactos entre diferentes plataformas.

2. Impulsar actualizaciones a partir de datos autoritativos de no leídos

Obtén un entero no negativo del servidor o de la capa de sincronización, límitalo y desduplícalo, luego llama a navigator.setAppBadge(count). Al llegar a cero, llama a clearAppBadge(); para mostrar solo un indicador visual, omite el número. Maneja cada rechazo de Promise y registra la capacidad o el tipo de error, nunca el contenido del mensaje.

3. Diseñar rutas para primer plano y segundo plano

La página puede actualizarse después de un evento de sincronización; un Service Worker puede usar su capacidad de worker correspondiente para eventos en segundo plano, sujeto al soporte real del navegador. Ambas rutas escriben el mismo conteo versionado para que un evento antiguo no pueda sobrescribir un valor más nuevo. Al iniciar, resincroniza el conteo autoritativo; el distintivo no es una base de datos.

4. Manejar fallos y accesibilidad

Si falta la capacidad, el contexto no es seguro, la PWA no está instalada o la llamada falla, mantén la lista dentro de la app, el conteo en la navegación y la pista en el título del documento, además de texto legible como “3 mensajes no leídos”. Limita (throttle) los anuncios de aria-live únicamente a los cambios. El distintivo nunca debe ser el único canal, y el fallo no debe bloquear la lectura ni el marcar mensajes como leídos.

Respuesta de ejemplo de alta calidad

Primero confirmaría que el producto tiene como objetivo el ícono de una PWA instalada en lugar de una pestaña normal. En una página HTTPS detectaría navigator.setAppBadge, lo impulsaría con un conteo no negativo de no leídos sincronizado, lo limpiaría en cero y capturaría los fallos de Promise. La página y el Service Worker consumirían un solo conteo versionado y se resincronizarían al iniciar, evitando que eventos desactualizados se impongan. Dado que el soporte es limitado y una plataforma puede renderizar un valor grande como un simple marcador, mantendría contadores dentro de la app, fallbacks en el título o favicon, y texto de estado accesible limitado. El distintivo es solo una sugerencia; su fallo no puede bloquear la lectura de mensajes.

Errores comunes

• Asumir que cada pestaña del navegador soporta un distintivo numérico exacto.
• Omitir las comprobaciones de HTTPS, instalación, existencia del método o rechazo de Promise.
• Usar el distintivo como el único almacenamiento de datos no leídos, provocando desincronización en recargas y entre múltiples dispositivos.
• Dejar que la página y el Service Worker mantengan conteos independientes, permitiendo que eventos obsoletos se impongan.
• Ofrecer solo un cambio de color sin título, contador dentro de la app o fallback accesible.
• Llamar a la API por cada mensaje, causando sobrecarga innecesaria (churn), consumo de batería y actualizaciones redundantes.

Preguntas de seguimiento y respuestas

¿Por qué no actualizar únicamente el favicon?

Un favicon afecta a las pestañas o marcadores y no puede representar el ícono de una aplicación instalada. Conviene combinar la Badging API, favicon, título y el conteo dentro de la app como capas de presentación dependientes de las capacidades.

¿Qué sucede si paso 4000?

El agente de usuario puede comprimir un valor grande a 99+ o mostrar solo un marcador. Limita el valor visual y conserva el conteo exacto dentro de la app.

¿Cómo probarías el fallback?

Cubriendo contextos seguros e inseguros, una PWA no instalada, un método faltante, rechazos de Promise, limpieza en cero, eventos en segundo plano fuera de orden y texto para lectores de pantalla; en cada caso, verifica que el flujo de datos de los mensajes siga funcionando.