Vue 3 + Pinia: la arquitectura frontend que elegimos y por qué

La razón principal no es filosófica. Es práctica: Vue 3 con `<script setup>` es el framework más legible para personas que vienen de distintos backgrounds. Un desarrollador que viene de React puede entender el código en horas. Alguien que viene de JavaScript vanilla puede hacerlo en días.

La Composition API tiene ventajas reales sobre la Options API para sistemas complejos. En un módulo de propiedades inmobiliarias, la lógica de filtrado, la lógica de paginación, la lógica de favoritos y la lógica de comparación son cuatro responsabilidades distintas. Con Composition API, cada una vive en su propio composable. Con Options API, todo convive en el mismo objeto `methods` y se vuelve difícil de seguir.

Los Single File Components (SFC) — template, lógica y estilos en un solo archivo — siguen siendo la decisión más práctica para un equipo que no tiene diseñadores frontenders separados de los que escriben lógica. Ves todo junto, modificás todo junto.

Tenemos una regla que no tiene excepciones: las vistas nunca llaman a la API directamente.

El flujo es: **View → Store → Service → API**.

Las vistas acceden a datos a través del store. El store llama al service para obtener o modificar datos. El service es el único que habla con la API. La configuración del endpoint (URL base, headers, autenticación) vive solo en `src/config/api.js`.

Esto parece agregar capas innecesarias. En la práctica, cada capa tiene una responsabilidad distinta:

- La **vista** sabe cómo mostrar datos y reaccionar a interacciones del usuario. No sabe nada de HTTP.
- El **store** (Pinia) mantiene el estado de la aplicación: qué datos están cargados, si están cargando, si hay un error, qué filtros están activos. No sabe nada de cómo se obtienen esos datos.
- El **service** sabe cómo pedirle datos a la API: qué endpoint, qué headers, cómo transformar la respuesta en el formato que el store espera. No sabe nada de Vue.
- La **config de API** sabe la URL base y cómo construir los headers de autenticación. Nada más.

La consecuencia es que cuando cambia el formato de respuesta de la API, solo cambia el service. La vista y el store no se tocan. Cuando cambia la lógica de estado, solo cambia el store.

Vuex fue el gestor de estado estándar de Vue 2 y parte de Vue 3. Pinia es su reemplazo oficial. La diferencia práctica más importante: Pinia elimina las mutations.

En Vuex, el flujo para modificar estado es: acción → mutation → estado. Las mutations son síncronas, las acciones pueden ser asíncronas, y la separación existe por razones históricas de las devtools. En la práctica, la mayoría del código de Vuex es boilerplate para atravesar esa separación.

Pinia colapsa mutations y actions: los stores tienen state (datos), getters (datos computados) y actions (funciones que modifican el estado o llaman a servicios). El código es más corto y más directo.

En un sistema con 20+ stores — uno por módulo de negocio — esa diferencia de verbosidad acumula.

Para lógica que aparece en múltiples lugares, usamos composables: funciones que encapsulan estado reactivo y comportamiento.

`usePagination` maneja la lógica de paginación. Cualquier store que necesite paginar llama a `usePagination` y obtiene los métodos y estado necesarios. `useFilters` maneja filtros activos. `useConfirmation` maneja el estado de diálogos de confirmación.

La regla es: si la misma lógica aparece en dos stores distintos, va a un composable. Si aparece en tres, el composable ya debería existir.

La arquitectura tiene valor porque se aplica consistentemente. Un módulo nuevo sigue el mismo patrón que los otros. Alguien que conoce cómo funciona el módulo de publicaciones puede entender el módulo de propiedades sin explicación.

La consistencia es la diferencia entre código que escala y código que se convierte en arqueología.