Refactorización de la capa de estado: Optimizando TuTiendaWeb
La necesidad de una arquitectura robusta
En el proyecto TuTiendaWeb, nos enfrentamos a un reto común en aplicaciones de comercio electrónico en crecimiento: la gestión del estado se estaba volviendo difícil de mantener conforme añadíamos nuevas funcionalidades. La complejidad de interactuar con Firebase y Firestore directamente desde los componentes provocaba una fuerte dependencia, dificultando las pruebas y la escalabilidad.
El Problema: Acoplamiento excesivo
Anteriormente, la lógica de negocio y la persistencia de datos estaban entrelazadas. Esto nos llevó a varios problemas:
- Difícil mantenimiento: Cambiar la lógica de un producto implicaba modificar múltiples componentes de React.
- Dificultad en pruebas: No podíamos testear la lógica sin disparar peticiones reales a Firestore.
- Estado fragmentado: La gestión del estado global mediante Zustand estaba dispersa y sin una estructura clara de dominio.
La Solución: Refactorización hacia una Arquitectura Hexagonal
Para solucionar esto, implementamos una separación clara de responsabilidades. Decidimos adoptar principios de la Arquitectura Hexagonal, encapsulando la lógica de la tienda en una capa de dominio que es independiente de la interfaz de usuario.
interface StoreState {
items: Product[];
addItem: (item: Product) => void;
}
export const useStore = create<StoreState>((set) => ({
items: [],
addItem: (item) => set((state) => ({
items: [...state.items, item]
})),
}));
Este código ilustra cómo centralizamos la gestión del estado mediante Zustand. Al separar esta definición de los componentes visuales, logramos que nuestra lógica sea predecible y fácil de testear. Además, utilizamos Zod para validar la integridad de los datos antes de persistirlos en Firestore, asegurando que la información que llega a nuestra base de datos siempre sea consistente.
Resultados obtenidos
La refactorización completa de la store nos ha permitido:
- Reducción de errores: La validación con Zod atrapa inconsistencias antes de enviarlas al servidor.
- Mejor DX: Ahora, los desarrolladores pueden entender el flujo de datos del proyecto leyendo una sola capa de servicios.
- Desacoplamiento: Podemos cambiar la implementación de la persistencia (por ejemplo, cambiar de Firebase a otro proveedor) sin tocar el resto de la aplicación.
Próximos pasos
Tras estabilizar la base de datos y el estado, el siguiente paso será estandarizar el manejo de horarios de atención y mejorar el sistema de estilos. La arquitectura actual nos da la flexibilidad necesaria para abordar estos cambios con total confianza.
Conclusión
La clave para una aplicación escalable es la separación de intereses. Automatizar la validación y centralizar el estado no es solo una buena práctica; es la base para construir productos que puedan evolucionar sin colapsar bajo su propia complejidad.
Generated with Gitvlg.com
