Diseño: @libs-core/ui-framework

Arquitectura de componentes UI MÍNIMOS y SIMPLES siguiendo patrones Angular 20 standalone para soporte de módulos de testing.

Objetivos de diseño

• Objetivo 1: Implementar componentes UI EXTREMADAMENTE SIMPLES para US-001, US-002, US-003, US-004
• Objetivo 2: Mantener código simple y directo (R-007, R-008)
• Objetivo 3: Angular 20+ standalone básico (R-009, R-010)
• Objetivo 4: Testing y logging mínimo (R-011, R-013)

Dependencias y límites del módulo

Dependencias internas (MÍNIMAS)

• @gograb-space/utilities: Solo ArrayUtils básico para sorting simple
• @libs-core/log-system: Solo logging de errores críticos
• Sin @libs-core/event-system - eventos Angular básicos únicamente

Dependencias externas

• @angular/core: Framework base
• @angular/common: Directivas comunes
• @angular/forms: Reactive forms integration

Límites del módulo

• Entrada: Configuración de componentes vía inputs
• Salida: Eventos de usuario vía outputs
• No: Lógica de negocio, servicios de datos, routing

Arquitectura y componentes

@libs-core/ui-framework
├── components/
│   ├── table/          # GgsTableComponent
│   ├── form/           # GgsInputComponent, GgsButtonComponent, GgsSelectComponent
│   ├── card/           # GgsCardComponent
│   └── chart/          # GgsSimpleChartComponent
├── types/              # Interfaces y tipos
└── styles/             # SCSS base

División de responsabilidades

GgsTableComponent

• Renderizado simple de tabla HTML básica
• Sorting básico de una columna usando ArrayUtils.sortBy()
• Paginación anterior/siguiente únicamente
• Eventos Angular básicos (click) únicamente

Form Components

• GgsInputComponent: Input HTML básico con validación required únicamente
• GgsButtonComponent: Button HTML básico sin estados complejos
• GgsSelectComponent: Select HTML básico sin filtrado

GgsCardComponent

• Div contenedor con header y body únicamente
• Styling CSS mínimo y fijo
• Sin error boundaries complejos

GgsSimpleChartComponent

• Canvas básico para barras simples únicamente
• Sin datos reactivos - datos estáticos
• Sin performance monitoring

Contratos y modelos

Interfaces principales

// Interfaces MÍNIMAS y SIMPLES

// Table básica
interface TableColumn {
  key: string;
  label: string;
}

interface TableConfig {
  columns: TableColumn[];
  pageSize: number; // Fijo, sin opcional
}

// Chart básico
interface ChartData {
  label: string;
  value: number;
}

interface ChartConfig {
  data: ChartData[];
  width: number;  // Fijo
  height: number; // Fijo
}

Eventos principales

// Eventos Angular BÁSICOS únicamente

// Eventos de tabla
- `(rowClick)`: Emite data del row clickeado
- `(sortClick)`: Emite string con la columna
- `(pageClick)`: Emite 'next' | 'prev'

// Eventos de formulario
- `(click)`: Click básico de botón
- `(valueChange)`: Valor básico del input/select

Decisiones de diseño

DEC-001: Standalone Components

Decisión: Usar exclusively componentes standalone Alternativa: NgModules tradicionales Justificación: Angular 20 best practices, mejor tree-shaking, menor acoplamiento Impacto: Requiere imports explícitos en cada uso

DEC-002: OnPush Strategy

Decisión: OnPush change detection obligatorio Alternativa: Default change detection Justificación: Performance crítica para tablas grandes (R-007, R-008) Impacto: Requiere immutable data patterns

DEC-003: Canvas para Charts

Decisión: Canvas API nativo para gráficos Alternativa: SVG, librerías como Chart.js Justificación: Sin dependencias externas (R-012), performance Impacto: Implementación manual de gráficos básicos

DEC-004: SCSS Styling

Decisión: SCSS con variables CSS para theming básico Alternativa: CSS-in-JS, styled-components Justificación: Compatibilidad Angular, simplicidad Impacto: Styling mínimo pero extensible

DEC-005: Mínima dependencia de Core Libraries

Decisión: Uso mínimo de @gograb-space/utilities y log-system Alternativa: Máxima reutilización de ecosystem Justificación: Simplicidad, componentes autocontenidos, facilidad de entendimiento Impacto: Código más simple pero posible duplicación mínima

Riesgos y mitigaciones

• Riesgo: Performance en tablas grandes Mitigación: Limiting a páginas pequeñas únicamente (sin virtual scrolling)
• Riesgo: Complejidad de Canvas charts Mitigación: Solo barras básicas - sin features avanzadas

Estrategia de pruebas y observabilidad

Pruebas

• Unitarias: Testing básico de inputs/outputs
• Integración: Testing básico con forms
• Sin visual testing - solo funcional básico

Observabilidad

• Logging básico de errores críticos únicamente
• Sin performance monitoring

Mapeo de cobertura