Scoreko-dev: Auditoría de Arquitectura

Este documento consolida el análisis de la arquitectura actual y el diagnóstico de los problemas encontrados, sirviendo como punto de partida para el refactor.

Análisis de la Estructura Actual

El proyecto está estructurado utilizando pnpm workspaces (nodecg, shared y el directorio raíz). El código fuente principal reside en src/, y se compila a extension/, dashboard/ y graphics/.

Distribución de Carpetas

Carpeta	Descripción
`src/dashboard/scoreko-dev/`	Contiene la UI del dashboard construida con Vue 3, Quasar y Pinia.
`src/graphics/`	Contiene los overlays (scoreboard, commentary, scoreboard-2xko) en Vue 3.
`src/extension/`	Backend NodeCG. Contiene la integración con start.gg, Challonge y la gestión de packs.
`src/shared/`	Lógica o utilidades compartidas (por ejemplo, lista de países).
`src/browser_shared/`	Replicantes expuestos a las apps Vue.

Flujo de Datos y Estado (Stores y Replicants)

Dashboard (Pinia + Replicants): Se usan stores de Pinia (scoreboard.ts, players.ts, commentary.ts) para manejar el estado en el dashboard. Existe un mecanismo de sincronización store-sync.ts que ata los ref de Vue (stores) a los Replicants de NodeCG, con un fallback en localStorage.
Graphics: Los componentes gráficos (ej. src/graphics/scoreboard/main.vue) importan directamente los replicants de browser_shared/replicants.ts y usan watch para reaccionar a cambios. No parecen usar Pinia, sino estado reactivo local (ref, computed).

Componentes Monolíticos

Existen componentes excesivamente grandes que mezclan responsabilidades:

src/dashboard/scoreko-dev/views/Players.vue (>680 líneas): Mezcla presentación, diálogos de UI, validaciones de formulario, llamadas a composables de integración (useIntegration), transformación de datos, renderizado manual de iconos SVG hardcodeados y lógica de exportación/importación JSON.
src/graphics/scoreboard/main.vue (>690 líneas): Mezcla la UI del marcador, cálculos de dimensiones de fuentes (fitText), timeouts manuales para animaciones, carga asíncrona de SVG de banderas usando importación dinámica de Vite, bindings a NodeCG y redirecciones de URL basadas en configuraciones gráficas.

Acoplamientos y Efectos Secundarios

En el dashboard, la lógica de integración de torneos (start.gg/Challonge) está fuertemente acoplada a la vista de jugadores mediante composables y callbacks, con SVGs directamente embebidos en el template.
En el backend (src/extension/startgg.ts), hay mezcla de servidor OAuth HTTP puro, lógica de peticiones GraphQL con strings literales gigantes, parsing de errores y endpoints de NodeCG (nodecg.listenFor), todo en el mismo archivo (>440 líneas).

Diagnóstico

Problemas Críticos

Lógica de negocio acoplada a la UI: Componentes como Players.vue y main.vue del scoreboard saben demasiado. Tienen lógica de red, cálculos de DOM, manejo de timeouts y manipulación de datos en crudo en lugar de delegar a stores o servicios.
"Vibe Coding" y AI Slop: Hay parches evidentes como la inclusión manual de SVGs inmensos inline en los templates, y utilidades infladas (cálculos rudimentarios de fitText en los overlays en lugar de usar CSS moderno o directivas reutilizables).
Estado implícito y dependencias circulares potenciales: El sistema de store-sync.ts que sincroniza Pinia <-> LocalStorage <-> NodeCG Replicants es frágil, creando condiciones de carrera sobre cuál es la "fuente de la verdad".
Falta de abstracción en el Backend NodeCG: Los archivos de extension/ son scripts procesales en lugar de arquitecturas separadas.

Impacto a Medio y Largo Plazo

Mantenibilidad Reducida: Agregar nuevas integraciones (ej. smash.gg, Toornament) requerirá copiar/pegar más bloques monolíticos y añadir más SVGs hardcodeados.
Riesgo de Regresiones: Modificar animaciones del scoreboard puede romper el cálculo del tamaño de fuente o la lógica de banderas, debido al acoplamiento.
Developer Experience (DX) Pobre: La curva de aprendizaje es alta. Entender cómo fluye un cambio de score desde el dashboard hasta el overlay se vuelve muy complejo.

Estrategia de Resolución

Reorganización: Mantener la estructura base (src/dashboard, src/graphics, src/extension), pero crear subcarpetas por dominio/feature en el backend y separación estricta en el frontend.
Refactor: Simplificar stores (eliminar puentes complejos a NodeCG), extracción de composables puros en el dashboard, separación de UI Dumb vs UI Smart.
Reescritura controlada:
- Players.vue: Dividir drásticamente.
- main.vue (scoreboard): Extraer lógica de flags, animaciones y fitText.
- startgg.ts / challonge.ts: Adoptar un patrón Service/Repository.

4.8 KiB Raw Blame History