Feedback

[rcellas]

Hola Jordi,

aquí tienes el feedback del sprint 9. Cualquier cosa lo miramos.

1. Cambios realizados desde la última revisión

Puntos positivos

• Se han resuelto los TODOs más importantes señalados anteriormente:
  • En el calendario (CalendarViewComponent) ahora se usa un enum (CalendarModalState) para gestionar el estado de los modales, y un signal para el modal activo, haciendo que el flujo de estados sea más claro y totalmente tipado.
  • El formulario de vehículo ha extraído los textos y mensajes de error a un servicio dedicado (VehicleMessagesService), evitando duplicaciones y facilitando el mantenimiento y la posible traducción de mensajes.
  • En GeolocationService se han definido de forma explícita las opciones de geolocalización (timeout, maximumAge) y se ha añadido una cadena de fallback: primero GPS, luego localización por IP y, si todo falla, coordenadas por defecto.
• El calendario se integra mejor con el modelo reactivo de la aplicación: se utiliza un effect sobre los signals de eventos para refrescar la vista de FullCalendar, manteniendo el estado sincronizado con los servicios.

Puntos a destacar

• Algunos problemas señalados en la revisión anterior (por ejemplo, URLs del API hardcodeadas o el lang="en" en index.html) siguen presentes, por lo que se mantienen como oportunidades de mejora, pero no se repiten en detalle en este informe para evitar redundancias.

---

2. Nuevos puntos positivos

2.1. Patrones de código y configuración

• Configuración estricta de TypeScript y Angular:

  • El proyecto está configurado con strict: true, noImplicitReturns, noFallthroughCasesInSwitch, etc., lo que eleva significativamente la seguridad de tipos y reduce errores sutiles.
  • Las opciones del compilador de Angular (strictTemplates, strictInjectionParameters, typeCheckHostBindings) garantizan revisiones más estrictas a nivel de plantillas y DI.
  • Este nivel de exigencia en la configuración no se había destacado en la revisión anterior y es un punto muy fuerte del proyecto.

• Uso de la nueva API funcional de Angular para Inputs/Outputs:

  • En componentes como el formulario de vehículo se utilizan input() y output() en lugar de los decoradores clásicos (@Input, @Output).
  • Esto moderniza el código, reduce boilerplate y encaja perfectamente con la dirección actual de Angular hacia APIs más funcionales.

• Centralización de mensajes y textos:

  • AuthService define un objeto authMessages con etiquetas de campos, mensajes de error y notas, lo que hace que el copy de la UI sea mucho más fácil de mantener o traducir en el futuro.
  • VehicleMessagesService agrupa los textos de formularios, errores y mensajes ARIA, reforzando tanto la consistencia de la interfaz como la accesibilidad.

2.2. Lógica de servicios y estado

• Gestión avanzada del estado en VehicleService:

  • Se usan signals y actualizaciones inmutables para gestionar la lista de vehículos (addVehicles, updateVehicle, updateVehicleLocation, etc.).
  • Los métodos addUserToVehicle y removeUserFromVehicle tienen en cuenta el usuario autenticado (currentUser) para decidir si se debe eliminar todo el vehículo de la lista o solo un usuario concreto, demostrando un modelado de dominio muy cuidadoso.

• Servicio de geolocalización robusto:

  • GeolocationService encapsula la lógica de obtención de coordenadas con una estrategia escalonada (GPS → IP → coordenadas por defecto).
  • Este enfoque reduce la complejidad de los componentes de mapa y mejora la resiliencia ante fallos del navegador o de la API de geolocalización.

---

3. Nuevas oportunidades de mejora

3.1. Calidad de código y arquitectura

• Diseño de la API de algunos servicios (patrón de suscripción):

  • En servicios como el de eventos, varios métodos (loadEvents, addEvent, updateEvent, deleteEvent) se auto-suscriben internamente (subscribe) y no devuelven el Observable al exterior.
  • Esto limita la capacidad de los componentes para:
    • Gestionar estados de carga (loading) y errores de forma homogénea.
    • Componer flujos reactivos más complejos (encadenar varias operaciones, aplicar retry o catchError centralizados, etc.).
  • Sería preferible devolver siempre Observable desde los servicios y dejar la suscripción en los componentes, efectos o una capa de orquestación, manteniendo los servicios más puros y testeables.

• Internacionalización (i18n) por explotar:

  • Aunque la configuración de Angular y la centralización de mensajes en servicios facilitan futuras traducciones, actualmente no hay un sistema de i18n implementado (archivos de mensajes, pipes o librerías de traducciones).
  • Los textos visibles de la UI están mayoritariamente en inglés mientras la documentación y el contexto del proyecto están en castellano/catalán.
  • Próximos pasos razonables serían:
    • Decidir el idioma principal actual de la interfaz y unificarlo.
    • Introducir una solución de i18n (Angular i18n o librerías como @ngx-translate) aprovechando que muchos mensajes ya están centralizados.

3.2. Rendimiento y comportamiento en producción

• Rendimiento potencial del calendario:

  • El componente del calendario refresca la vista eliminando todos los eventos y volviendo a añadir la fuente completa en cada actualización.
  • Con pocos eventos esto es suficiente, pero con un volumen mayor podría penalizar el rendimiento.
  • A medio plazo se podría estudiar:
    • Actualizaciones incrementales (añadir/eliminar solo los eventos que cambian).
    • Uso de eventSources reactivos para reducir redibujos completos.

• Dependencia de un servicio externo de IP en el cliente:

  • GeolocationService consulta una API pública de localización por IP desde el lado cliente.
  • Para un entorno de demo es una solución muy práctica, pero de cara a producción habría que considerar:
    • Términos de uso, cuotas y estabilidad de la API externa.
    • Implicaciones de privacidad (tratamiento de la IP del usuario).
    • Posible migración de esta lógica a un backend propio si se necesita más control.