Desarrollo Frontend Senior

Habilidad de Desarrollo Frontend

Ingeniería frontend de nivel sénior, pragmática y lista para producción. El objetivo es siempre código funcional, mantenible y de alto rendimiento, no pureza académica.

Detección del Stack

Antes de cualquier otra cosa, identifica el stack a partir del contexto. Si no está claro, pregunta. Luego carga el archivo de referencia adecuado.

Stack	Cargar
React (sin GraphQL)	references/react.md
React + GraphQL/Relay	references/react-graphql.md
Angular	references/angular.md
TypeScript (todos los stacks)	references/typescript.md (cargar junto con el archivo del stack)

Siempre carga references/typescript.md además del archivo del stack, a menos que el proyecto sea explícitamente solo JS.

---

Principios Universales

Estos aplican independientemente del stack. No los omitas.

Arquitectura

• Separa las responsabilidades de forma agresiva: La representación de la UI, la lógica de negocio, la obtención de datos y los efectos secundarios viven en capas diferentes. Los componentes no deben contener llamadas fetch, cadenas de API sin procesar ni reglas de negocio.
• Co-ubicación por funcionalidad, no por tipo: Prefiere features/user-profile/ que contenga componente + hook + test + estilos sobre carpetas de nivel superior como components/, hooks/, tests/. Escala la estructura según la complejidad de la aplicación — no sobreingenierices una aplicación pequeña.
• Composición sobre herencia: Construye UIs componiendo componentes pequeños y enfocados. Evita jerarquías de componentes profundas.
• Sin abstracciones prematuras: Escribe la cosa dos veces, luego abstrae. Una abstracción construida sobre un solo caso de uso suele ser incorrecta.

Diseño de Componentes

• Los componentes deben hacer una sola cosa. Si un componente tiene más de una razón para cambiar, divídelo.
• Separa componentes de presentación (UI pura, sin efectos secundarios) de componentes contenedores/inteligentes (datos, lógica, orquestación).
• Las interfaces de props deben ser explícitas y tipadas. Nada de any, object ni {} como tipo.
• Por defecto, usa componentes controlados para formularios.

Rendimiento (líneas base no negociables)

Objetivos de Core Web Vitals (medir en el percentil 75 de usuarios reales):

• LCP ≤ 2.5 s (carga)
• INP ≤ 200 ms (interactividad — reemplazó a FID en marzo de 2024)
• CLS ≤ 0.1 (estabilidad visual)

Reglas universales de rendimiento:

• Nunca bloquees el hilo principal con tareas síncronas largas
• Carga bajo demanda rutas y componentes pesados por defecto
• Establece dimensiones explícitas en todas las imágenes y medios (previene CLS)
• Usa fetchpriority="high" en imágenes LCP
• Difiere los scripts de terceros no críticos
• Evita el thrashing de diseño (agrupa lecturas/escrituras del DOM)
• Habilita la elegibilidad para bfcache: evita listeners unload, evita no-store donde no sea necesario

Sistemas de Diseño y Tokens

• Define tokens de diseño (color, espaciado, tipografía, radio, sombra) como la verdad absoluta — nunca codifiques valores en los componentes
• Usa propiedades personalizadas de CSS (--color-primary) o un sistema de tokens (Style Dictionary, configuración de Tailwind) para que el theming esté centralizado
• Atomic Design como modelo mental: átomos → moléculas → organismos → plantillas → páginas. No fuerces la nomenclatura, pero piensa en esta jerarquía
• Documenta los componentes en Storybook para aislamiento, descubribilidad y pruebas de regresión visual
• La accesibilidad no es opcional: WCAG 2.1 AA como mínimo. Cada elemento interactivo necesita soporte de teclado, gestión de enfoque y ARIA donde el HTML semántico sea insuficiente

Integración de API

• Nunca llames a APIs directamente desde los componentes. Usa una capa de datos: hooks personalizados, servicios o una librería de consultas
• Maneja los tres estados explícitamente: carga, error, éxito — nunca asumas el camino feliz
• Usa actualizaciones optimistas para el rendimiento percibido por el usuario en mutaciones
• Valida las respuestas de la API en el límite (Zod, io-ts o equivalente) — no confíes en la forma de los datos externos
• Centraliza las URLs base de la API y la inyección de tokens de autenticación — nunca los disperses entre componentes

Estrategia de Pruebas

Enfoque de tres capas:

1. Pruebas unitarias: Funciones puras, utilidades, hooks personalizados (Jest / Vitest)
2. Pruebas de componentes: Comportamiento de renderizado, interacciones del usuario, cambios de estado (Testing Library — prueba el comportamiento, no la implementación)
3. Pruebas E2E: Solo recorridos críticos del usuario (Playwright o Cypress)

Reglas:

• Prueba el comportamiento desde la perspectiva del usuario, no la implementación interna
• Sin snapshots para lógica — son frágiles. Usa snapshots solo para regresión visual intencional
• Apunta a una alta cobertura en lógica de negocio, no en boilerplate
• Co-ubicación de archivos de prueba con el código que prueban: Button.test.tsx junto a Button.tsx

Navegación de Código (tsserver)

El flujo de trabajo general de LSP sobre búsqueda de texto reside en la habilidad dev-standards ("Code navigation"). Notas específicas de TypeScript:

La herramienta LSP enruta a tsserver para TS/TSX. Las operaciones de un solo archivo son fiables en frío: documentSymbol, hover, goToDefinition.

Advertencia: tsserver indexa de forma perezosa (a diferencia de gopls). Una consulta entre archivos (findReferences/workspaceSymbol) ejecutada contra un servidor frío puede subcontar silenciosamente: solo conoce los archivos ya cargados en su proyecto y devuelve un resultado confiado pero incompleto (por ejemplo, solo la declaración). Protégete contra ello:

• Trata un recuento de referencias sospechosamente bajo como no verificado.
• Consulta findReferences desde un sitio de uso (un archivo que importe el símbolo), no desde la declaración de forma aislada — esto fuerza la carga del grafo del proyecto.
• Para decisiones del tipo "¿esto todavía se usa en algún lado?" (eliminación de código muerto, renombrados seguros), confirma con grep — un subconteo aquí es peligroso.

Herramientas Predeterminadas (2025)

• Bundler: Vite (por defecto para proyectos nuevos); Webpack 5 para configuraciones empresariales grandes que ya lo usen
• Linting: ESLint + @typescript-eslint + Prettier (formateo separado del linting)
• Gestor de paquetes: pnpm preferido para monorepos; npm o yarn aceptables
• Monorepo: Nx o Turborepo para espacios de trabajo multi-paquete
• CI: Ejecuta type-check, lint, test y build en cada PR. Nunca fusiones pipelines en rojo.

---

Modos de Salida

Al producir salidas, sigue estas directrices:

Código de componente: Incluye tipos, maneja casos extremos, sigue los patrones del stack según el archivo de referencia. Proporciona el componente y su prueba en la misma respuesta, a menos que el tamaño lo impida.

Arquitectura / estructura de archivos: Muestra primero el árbol de directorios, luego explica el razonamiento. Sé decidido: da una estructura buena, no un menú de opciones.

Auditoría de rendimiento: Enumera los hallazgos por severidad (Crítico / Advertencia / Informativo). Para cada hallazgo: qué es, por qué importa, cómo solucionarlo.

Configuración del sistema de diseño: Primero la estructura de tokens, luego los componentes primitivos, luego la configuración de documentación.

Integración de API: Muestra el patrón de la capa de datos para el stack específico, luego el componente que lo consume.

Pruebas: Muestra las pruebas junto al código que se prueba. Sigue AAA (Arrange, Act, Assert).

---

Habilidad Complementaria

Esta habilidad cubre ingeniería. Para la estética visual — elecciones tipográficas, sistemas de color, diseño de movimiento, composición espacial y evitación de estéticas genéricas de IA — consulta la habilidad frontend-design. En tareas que requieran ambas (por ejemplo, "construye un dashboard que se vea genial"), usa ambas habilidades juntas: frontend-dev para arquitectura y calidad de código, frontend-design para dirección visual.

Archivos de Referencia

Lee estos antes de producir una salida específica del stack:

• references/typescript.md — TypeScript modo estricto, patrones, errores comunes
• references/react.md — React 19, Next.js, hooks, gestión de estado, estrategias de renderizado
• references/react-graphql.md — Relay, fragmentos co-ubicados, patrones de GraphQL en React
• references/angular.md — Angular v22, Signals, Standalone Components, sin zone, NgRx