Feedback E2

[barbaraim]

Feedback E2

Bandas

Como recordatorio, estas son las bandas de la E2:

Back FFBG

D: Modelo implementado (entidades y sus asociaciones) + conexión entre back y front (de cualquier tipo pero se establece una)

C: Lógica de logros (puede tener un par de errores). GET para un logro / vista de logros y al menos un POST funcional con solicitud de logro (o similar).

B: Lógica de logros sin errores. Todos los POST que los logros requieran para probar los logros que implementó, puede tener un par de errores. (Debe entregar documentación o json base para que el ayudante pueda probar).

A: ESlint + Gitflow. No hay errores en los endpoints implementados.

Front FFBG

C: Simula el envío de un Logro (creación de logro del admin) desde el frontend. Tiene un GET del estado de los logros que actualiza la vista de logros. Empieza a migrar a React (puede tener fallas)

B: Se puede simular el envío de más de un tipo de solicitud de logro. Empieza a tener un uso de react más avanzado en el tablero (vista logros), especialmente en lo relacionado a componentes. Se actualizan los logros en el perfil.

A: Se pueden realizar algunos tipos de solicitudes de logro, vista de logros que en hover diga qué cumple la persona y qué no y/ó que se ponga en gris los que no tiene. Se actualizan los logros en el perfil, incluso los que se hacen por detrás.

De acuerdo a las bandas su nota es: A.

¡Felicitaciones y muy buen trabajo!

Feedback

• El modelo y backend están funcionando de buena forma 😄 .
• Existen errores menores en el frontend y uso de su aplicación, algunos que necesitaron hotfix 🚑 (barra de búsqueda y subir imágenes muy grandes). Estos no fueron considerados en la corrección. Sin embargo, tengan ojo de que cosas no se rompan cuando hacen una nueva feature (para eso están las pull requests).
• Gracias por incluir documentación 📖 . Sin embargo, esta podría ser más clara. Como tip, les recomiendo utilizar la documentación de Postman. Permite incluir no sólo parámetros y cosas necesarias, sino también descripciones y queries de ejemplo (incluso en distintos lenguajes y distintas librerias. Ej: con axios, con fetch, etc).
• Los felicito por el uso de volúmenes y docker 🐳 . Es una buena práctica, para poder desarrollar en conjunto. Sin embargo, este contenedor contenía VS Pets 🐶 . Aunque a mí en lo personal no me importa esta inclusión (es más, me gusta esta extensión), no todos lo podrían encontrar igual de amigable y divertido.
• Hay una lógica avanzada de los logros 🎖️ , incluyendo el CRUD completo de estos. Se pueden crear por los admins, aceptar solicitudes, se actualizan en el perfil y más. Muy buen manejo de esta lógica. También se ve una lógica avanzada de otros aspectos esenciales de la aplicación, como son los usuarios.
• Buen uso de eslint. El código se ve ordenado y sigue los estándares.
• En el frontend, se ve un uso avanzado de React 🎨 , al igual de crear varios componentes útiles para las distintas vistas. Ya se ve un uso más avanzado de distintos hooks importantes.
• La vista de logros (que había sido acordada para esta entrega) no pudo ser creada a su completitud. Luego de analizar el caso, creo que hacer un árbol que se actualice por si solo era más complejo de lo que habíamos pensado al acordar las bandas. Por ello, creo que lo implementado sí cumple con los requisitos mínimos, e incluso sobresalientes de las bandas. Ya hablamos de cómo enfrentar esta vista para poder tener un producto final más avanzado.
• Algunas sugerencias para el árbol de logros 🌳 : podrían pensar cómo mostrarla teniendo atributos como "siguiente logro" o "logros hijos" y "logros padres". Creo que igual podría ser una lógica más avanzada que lo que tenemos en el curso, pero funciona similar a "seguir" en instagram de cierta forma. Ya representar esto de manera visual es más complicado.
• En términos más visuales, la vista de logros todavía podría ser más user-friendly. A simple vista no se entiende la simbología y no aporta demasiada información al usuario. Los invito a ser creativos en cómo presentar esta información de mejor manera.
• Existe una conexión más avanzada entre frontend y backend. Ya parece una app más robusta, por la incorporación de sesiones y control de qué puede ver cada usuario. Todavía falta un poco de trabajo en esto, pero precisamente es el encargo de la E3.
• En términos visuales, cuidado con el dark-mode vs light-mode 🌙 🌞 . Hay vistas que se ven mucho mejor en uno de los dos, para ambos casos. Por ejemplo, los cuadrados amarillos de logros apenas se ven en light-mode, mientras que el hover de la navbar se pierde en dark-mode. Les recomiendo tener ⚠️ 2 paletas de colores, que se ajusten y que contengan estos casos.
• Ojo con la subida de archivos de los logros . Al subir un archivo así, no solo puede ser que ciertos deploys borren sus archivos o falta de espacio, sino que también puede ser vulnerable a ciberataques.
• Otra cosa que se perdió con el paso a React fue el responsiveness, para que tengan ojo. Esta aplicación pareciera que será ocupada mucho de forma mobile, por lo que es importante este punto. No me funcionó desplegar el navbar en pantallas más pequeñas, por ejemplo.
• Existen varias pull requests sin descripción. Esto es parte de lo que se pide en Gitflow. Les recomiendo incluir templates de pull request en un repositorio. Ejemplo: https://axolo.co/blog/p/part-3-github-pull-request-template. Esto creo que es esencial para su proyecto, considerando que será de open source y otras personas externas podrán hacer pull requests.

¡Mucha suerte y éxito en la E3!