Personalizar Quasar para interfaces WebRTC reactivas y configurables

Cuando empezamos a construir la interfaz de una aplicación de videorreuniones multiorganización, Quasar no era la opción obvia. Es más conocido para paneles de administración y dashboards que para medios en tiempo real. Visto con perspectiva, fue una de las decisiones que más tiempo nos ahorraron.

Una pantalla de reunión es un dashboard que nunca deja de moverse. La gente entra, las cámaras se apagan, alguien presenta, un moderador silencia la sala, y cada uno de esos eventos WebRTC tiene que reflejarse al instante. Además, cada organización cliente quería sus propias reglas. Esto es lo que aprendimos al personalizar Quasar para resolver ambas cosas, y dónde nos hizo el trabajo más rápido que montar las piezas por nuestra cuenta.

Por qué Quasar encaja en una interfaz de videollamada

Una interfaz de reunión necesita mucho más que mosaicos de vídeo: un layout adaptable, paneles laterales para el chat y los participantes, menús distintos para moderadores e invitados, diálogos de dispositivos, notificaciones ligadas al estado de la llamada y temas visuales por cliente. Con Vue a secas, eso supone un kit de UI, una librería de toasts, un helper de breakpoints y un wrapper de almacenamiento, cada uno configurado por separado.

Quasar trae todo eso como un único conjunto coherente y, lo más importante para el trabajo en tiempo real, cada pieza es reactiva y se puede controlar desde el estado. Eso nos permitió seguir una sola regla: los eventos WebRTC solo actualizan un store central, y cada capa de Quasar reacciona a ese store, nunca al SDK de medios.

Vistas de layout que se reconfiguran solas

La aplicación ofrece tres vistas: una vista de presentador con un escenario grande y un carrusel de miniaturas, una vista solo del orador y una cuadrícula uniforme. La vista actual es un único valor en el store, y Quasar se encarga del resto.

• Elegir una vista es una opción anidada dentro de un QMenu. QMenu, QList y QItem ya resuelven el posicionamiento, el anidamiento y el acceso por teclado.
• Recordarla es una sola llamada al plugin LocalStorage de Quasar, así que la siguiente reunión se abre en la vista en la que la dejaste. El mismo plugin guarda los dispositivos elegidos y el estado del micrófono.
• Adaptarse a la pantalla es donde Quasar más se notó. La cuadrícula elige sus columnas a partir del número de participantes y del breakpoint actual del plugin Screen. Como el plugin es reactivo, girar el móvil o redimensionar la ventana reorganiza la cuadrícula al instante, sin listeners de resize que escribir ni limpiar.

La vista de presentador reacciona a los eventos de orador activo: el escenario muestra primero la pantalla compartida y, si no la hay, a quien esté hablando. El carrusel que hay encima admite hasta seis miniaturas, con las personas fijadas primero. Una lección sincera: QCarousel pasa las diapositivas de una en una, mientras que una reunión necesita ver todas las miniaturas a la vez, así que una simple fila con scroll encajaba mejor. Elige el componente por la interacción, no por su nombre.

Compartir pantalla: un evento y toda la pantalla cambia

Compartir pantalla es la mejor prueba de reactividad, porque un solo evento WebRTC lo cambia casi todo. Cuando empieza una compartición, el store lo registra y la capa de Quasar lo sigue:

1. El layout cambia solo. Una presentación compartida no sirve de nada como un mosaico pequeño dentro de una cuadrícula, así que la vista pasa automáticamente al layout de presentador. Cuando termina la última compartición, se restaura lo que el usuario tenía antes.
2. La barra de herramientas se actualiza. El QBtn de compartir cambia de icono, de color y de texto en su QTooltip, y aparece un icono de presentador junto a la persona correcta en la lista de participantes dentro del QDrawer.
3. Aparecen controles nuevos donde hacen falta. Un pequeño QBtn sobre la pantalla compartida la separa en su propia ventana del navegador, algo útil con un segundo monitor. Mientras está separada, todos los layouts se comportan como si nadie estuviera compartiendo.
4. Los conflictos se resuelven solos. Si alguien ya está compartiendo, la aplicación le pide que pare a través del canal de datos de la llamada y arranca la nueva compartición cuando termina la suya. Para el usuario, es un solo clic.

Nada de esto necesitó manipular el DOM de forma imperativa. Cada componente de Quasar ya expone las props que necesitábamos (icono, color, etiqueta, deshabilitado, contenido del tooltip), así que reaccionar a una compartición de pantalla fue cuestión de enlazar esas props al estado.

Estado de silencio: un botón, varias fuentes de verdad

Un botón de micrófono parece trivial hasta que cuentas quién puede cambiarlo: el usuario, un moderador y la política de la reunión de "entrar silenciado". Guardamos por separado la elección del usuario y las restricciones de la sala, y cada componente de Quasar muestra el resultado combinado.

El QBtn de la barra de herramientas y los QIcon de cada mosaico de vídeo leen ese mismo estado, así que nunca pueden contradecirse. Los iconos de los mosaicos se pueden configurar para aparecer siempre, solo cuando están activos o solo cuando están silenciados, y para los moderadores esos mismos iconos se convierten en controles clicables.

Notificaciones que siguen a la llamada

Una videollamada genera un flujo constante de pequeñas novedades: ha empezado una grabación, alguien espera en la sala de espera, la reunión se acerca a su límite de tiempo, un moderador te ha silenciado. El plugin Notify de Quasar resultó ser una de las partes más útiles del conjunto para esto.

Cómo funciona. Notify se activa con una línea en la configuración de Quasar. A partir de ahí, una sola llamada lanza una notificación desde cualquier sitio: un componente, un store o una función cualquiera. No hay que colocar ningún componente de toast en el layout ni gestionar contenedores. Cada llamada admite unas pocas opciones: el mensaje, un color del tema, un icono, la posición, cuánto tiempo se queda (cero la mantiene hasta que se cierra) y botones de acción opcionales como Cerrar. Devuelve un handle que cierra exactamente esa notificación.

Por qué encaja con el tiempo real. Los eventos de la llamada llegan fuera de cualquier componente. Como Notify se llama desde código normal y devuelve un handle, el mismo watcher que abre un mensaje puede cerrarlo en cuanto cambia la situación. Los colores vienen del tema y los iconos de nuestro mapa de iconos personalizado, así que cada mensaje respeta la marca sin estilos extra, y no hay que añadir ni conectar una librería de toasts aparte.

Cómo lo usamos. Un pequeño helper envuelve Notify con tres presets: info, aviso y error. Traduce el mensaje, aplica los colores de la marca, lo muestra arriba durante cinco segundos o lo mantiene con un botón de Cerrar, y limpia las notificaciones abiertas cuando se cierra la pantalla que las lanzó.

Personalizar una vez, configurar en todas partes

Lo que más tiempo nos ahorró fue que Quasar se puede personalizar en unos pocos puntos centrales, mientras el resto del código sigue usando componentes estándar. Así mantuvimos el producto fiel a la marca sin hacer ningún fork.

1. Variables del tema. Los colores de marca, los radios de las esquinas y las sombras viven en las variables del tema de Quasar. Cada QBtn, QBadge y QBanner las recoge a través de los nombres de color habituales, así que la barra de herramientas, los diálogos y las notificaciones encajan sin estilos por componente.
2. Un mapa de iconos propio. Un boot file registra unos setenta iconos personalizados mediante la función de mapeo de iconos de Quasar. A partir de ahí, un nombre corto funciona en cualquier sitio donde Quasar acepte un icono, así que pasar de "micrófono activado" a "micrófono desactivado" es solo un nombre distinto en un binding.
3. Boot files para la configuración en tiempo de ejecución. Las traducciones, la configuración del entorno, el cliente HTTP y el conjunto de iconos se cargan en boot files antes de que se pinte la primera pantalla. El fichero de entorno se genera al arrancar el contenedor, así que una sola build funciona en desarrollo, en staging y en el entorno de cada cliente.
4. Wrappers finos, nunca forks. Solo envolvimos lo que estilamos igual en todas partes: el botón principal, un desplegable compacto y un helper de Notify con nuestros colores y textos traducidos. Todo lo demás es Quasar tal cual.
5. Primitivas integradas para la pantalla de llamada. Un QLayout con un QDrawer para el chat o los participantes, QDialog para los ajustes, un QBadge que cuenta la sala de espera y una barra de herramientas que el plugin Screen convierte en un desplegable en pantallas pequeñas.

El mismo enfoque hizo que el producto fuera configurable por organización. Los ajustes de cada reunión (sala de espera, quién puede compartir, si los invitados entran silenciados, chat, acceso telefónico, marca, cifrado) se combinan con el rol del usuario en un único conjunto de permisos. Los componentes de Quasar se enlazan directamente a él: botones deshabilitados, entradas de QMenu solo para moderadores, un QBanner cuando el acceso telefónico no está disponible. Una política cambiada en la consola de administración se aplica en la siguiente reunión, sin ninguna release del front-end.

En resumen

Lo que hizo de Quasar una buena opción para una aplicación de videollamadas no fue ningún componente concreto. Fue que todas sus partes (componentes, el plugin Screen, Notify, LocalStorage, los temas y los boot files) se pueden controlar desde el estado y personalizar en un solo lugar. Lleva los eventos de la llamada a un store, enlaza Quasar a ese store, y compartir pantalla, los cambios de silencio y los cambios de layout pasan a ser configuración en lugar de código.