Guisseee
commented
5 months ago Hola.
El diario no se a que te refieres Alicia, y la parte de servidor la iba a empezar esta semana.
Open AVegMor opened 5 months ago
Guisseee
commented
5 months ago Hola.
El diario no se a que te refieres Alicia, y la parte de servidor la iba a empezar esta semana.
AVegMor
commented
5 months ago Me refiero a esto:
Guisseee
commented
5 months ago ¿El historico de cambios no cuentan los commit del propio github?¿Hay que hacer un archivo aparte en el que vaya escribiendo lo que hago?
rlopdav392
commented
4 months ago DISEÑO / FIGMA
=> prototipo mobile / desktop:
Eso que comentas que ha habido variaciones de diseño, entre fidelidad media y fidelidad alta, es normal, para eso están las diferentes versiones.
Y luego también es normal, los cambios de diseño, entre el prototipo figma y la maquetación CSS.
No obstante, es importante que lo menciones tanto en la documentación como en la presentación.
=> Estructura de tu proyecto figma:
Metes todo en una sola página (componentes y fidelidades).
A mi, personalmente, me gusta más separarlo en diferentes páginas.
No obstante, hay muchos formas de estructurar un proyecto figma, solo para que veas otras formas, esta sería otra estructura:
Un página para cada uno de estos apartados:
Assets / Componentes (en tu caso, "cosas a usar")
Fidelidad baja=> un frame por cada página de tu web
Fidelidad media=> un frame por cada página de tu web
Fidelidad alta => un frame por cada página de tu web
(https://www.youtube.com/watch?v=dz4VnO3_hto)
=> Reusable (Atomic design) => muy bien el uso de componentes maestros para las cards, las imágenes y los iconos. Te ha faltado también hacer componentes cards para la sección de “porque unirte a la familia de fithubx”.
Para diseñar esas cards que siguen un mismo patrón, arriba la imagen con un título y en la parte de debajo de la card, un párrafo, a mí me gusta la estructura que usa este youtuber:
(https://www.youtube.com/watch?v=tvanCYYHfnM)
Yo, por ejemplo, veo más útil usar un layout y dentro del mismo un frame para la imagen, mejor que un grupo.
=> Responsive (responsive design) => importante detallar en la presentación / documentación nivel de responsive de tu prototipo.
=> Interacciones => muy bien el uso de interacciones entre las páginas.
=> Plantilla de átomos: Acuérdate que del diseño figma tiene que salir una plantilla de átomos que luego se actualizará en su maquetación CSS
(https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view)
=> Plugin de accesibilidad=> importante pasarle algún plugin de accesibilidad (able)
=> Patrones / Principios de diseño => importante explicar en la documentación los patrones y principios de diseño usados para el prototipo.
MAQUETACIÓN CSS3
Importante no definas el width de las imágenes desde html, hazlo desde una regla CSS.
https://html.com/attributes/img-width/
=> variables: muy bien el uso de variables para los colors y las fuentes.
=> BEM (block__element—modifier):
Bien el uso del modifier de la metodología BEM en esta regla: user-menu—overlay
Puedes también aplicar element de la medotología BEM en algunas reglas.
Repasamos metodología BEM y te pongo al final de la explicación una extrapolación a tu código, por si te diese tiempo a usarla en alguna regla CSS:
BEM: block__element—modifier
Element es un container dentro de block, que solo puede existir dentro de block, fuera de ese container padre no tiene sentido.
Modifier: es un container que sale de modificar algún atributo de element, se podría decir que es una variante de element, de tal forma que herada de element todos los atributos, y a parte le aplica esa variante.
Extrapolación a tu código:
Nav => nav__enlaces
Card => card__tituloCard
Card => card__contenidoCard
=> SASS: acuérdate del preprocesador de CSS que vimos los últimos días en clase, por si te animas para usarlo en el otro aplicativo, es genial para conseguir más elegancia, ya que, además del uso de variables y del anidamiento de reglas, que ya te lo da el CSS puro, te permite crear bloques de código CSS reusables en diferentes reglas, a través de mixin y extend.
=> Documentación interna: documentado correctamente con comentarios parte CSS.
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (cuantas clases reusas en varios sitios, como los layouts (grid, flex), los botones, las listas, los espaciados (margin, padding),.., si haces uso de variables)
=> Código repetido html:
Al igual que separas el footer en una pieza/componente html aparte, para poder usarla en todas las páginas html, a través de una promesa, pues también podrías hacer lo mismo con el header, es otra pieza de puzzle, que la podemos hacer reusable, de la misma forma que has hecho con el footer.
Esta problemática, verás que ya no te surge con react, ya que en react, el big layout de la página principal, hay que definirlo, si o si, en componentes reusables. (header, main, footer)
=> Arquitectura de ficheros CSS: Es ok
=>SEO / html semántico: acuérdate de poner lo siguiente: title, meta descripción, imágenes con alt no vacío y favicon.
=> Big layout: el big layout, esto es, el super container que se encuentra entre las etiquetas body de una página html, ha de estar estructurado semánticamente bien, por ejemplo, si se trata de la página principal ha de estar divido en un header – main – footer. Y dentro del header han de estar los enlaces a través de un nav.
Eso está ok, yo lo que veo a mejorar, sería dentro del main, yo veo claramente 4 secciones, veo mejor para separar ese contenido, usar section en vez de div genérico, luego ya dentro las section, los div genéricos es ok.
=> Imágenes:
No parece que tengas imágenes de gran peso, solo veo una que es de 1.03MB
Importante pásale algún test de perfomarce (lighthouse, https://tools.pingdom.com/, https://pagespeed.web.dev/)
Si hubiese que optimizar puedes usar el formato webP.
Y comprueba cómo se ven en diferentes resoluciones, si mantienen la calidad o no. En caso de que no, tendrás que crear para una imagen, diferentes versiones según las resoluciones donde se vayan a renderizar, y eso se lo dices al navegador, con la etiqueta html picture => source
=> Responsive design -media querys: Importante detallar en documentación / presentación, pues cuantos breakpoints se han definidos, esto es, para cuantas resoluciones es responsive tu diseño.
=> Responsive design – layout grid / flex: acuérdate de explicar en la documentación / presentación los layouts que tienes implementados en tu página.
=> Responsive design – unidades relativas: haces uso tanto de unidades relativas (rem) como de unidades absolutas (px), esto es ok, si, por ejemplo, te interesa que algunos elementos sean fijos y no dependan del fontsize del navegador.
Pero pruébalo que tal queda, es decir, vete jugando con el Font size del navegador, vete cambiándolo para cada uno de los breakpoints definidos y mira que tal queda tu diseño.
=> Plantilla de átomos: Aquí un ejemplo de una plantilla de átomos con un nivel de detalle alto: (https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view)
Acuérdate que esta plantilla de átomos no es más que una actualización de la plantilla de átomos que salió de la maquetación CSS.
JAVASCRIPT
=> Información dinámica / estática: Dejar bien claro en la presentación / documentación que sección de tu página son dinámicas, se cargan desde servidor, y cuales estáticas. En principio, por lo que he entendido, las cards de los diferentes planes y luego pues el contenido del usuario.
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (uso de funciones, librerías)
=> Documentación interna: se puede documentar con más comentarios javascript.
=> DOM: toda la parte javascript ponla siempre en los ficheros javascript, eventos onload y onClick han de ser tratados desde un addeventlistener en un fichero javascript y no desde HTML.
https://www.tutorialspoint.com/why-is-using-onclick-in-html-a-bad-practice
Importante, repasa que uses delegación, para la gestión de eventos, siempre que se pueda.
=> Arquitectura de ficheros: es OK, un file js por cada componente html.
REACT
Esta parte te faltaría, te adelanto un poco lo que podría llevar:
=>Información dinámica vs estática: Dejar bien claro en la presentación / documentación que sección de tu página son dinámicas, se cargan desde servidor, y cuales estáticas. Si es que tienes alguna parte de información estática.
=> Arquitectura de ficheros: esto es muy fácil, ya que en react cada jsx es un componente. Tendrás un jsx principal (main.jsx) que importará los jsx componentes.
=> Reusabilidad – abstracción código: haciendo uso de children en los componentes.
=> Riqueza React: useState / useEffect / Hooks personalizados / Context API, / UseRef / React-router-dom / react-modal / react-tostity
Pues de lo principal, por lo que veo en el código sería:
=> Crear los JSON de datosCards desde una llamada API a un endpoint laravel.
=> Y lo que comentas, cuando se haya logueado el usuario, que le aparezca pues el plan que tiene.
=> aplicativo React y prototipado figma para la versión mobile. Coge solo una página, la principal por ejemplo y la pasas a mobile.
rlopdav392
commented
4 months ago PATRÓN Z - DOCUMENTAR: IMPLEMENTACIÓN Y MEDIA QUERYS PARA QUE SEA RESPONSIVE PARA MOBILE
Con respecto a tu patrón Z, estaba mirando como lo has implementado, has usado un flexbox, está genial, pero eso lo tienes que explicar, a mi me gusta más un grid, porque en tu caso pues tienes que usar 6 flexbox, pero está ok tambien.
Y luego al hacerlo responsive para dispositivos mobile, estaba comprobando que en la media query, no se te haya olvidado cambiar el orden de tus flex item, y si que lo has hecho, está genial.
Pero si que esto, tendrías que explicar en un pequeño comentario en la media query de 500px, pues diciendo, que a partir de esta resolución, tu flex ya no es una fila con dos columnas, pasa a ser una columna con dos filas, cambiando la propiedad flex-direction. Y el orden de los flex-item lo tienes que cambiar, por lo tanto, a través de la propiedad order.
Y luego en la regla donde estilas la clase ".imagenTexto" también un pequeño comentario CSS, que diga que usas un flex para estilar el patrón Z, nada más.
Dentro de la documentación CSS, a mi me gusta, documentar, entre otros, los siguientes apartados:
Guisseee
commented
4 months ago Muchas gracias por el feedback Rocío, lo tendré en cuenta, con respecto a react ¿sería necesario que hiciera solo la página principal?¿o es necesario hacer todas?. Esa parte no me ha quedado clara del todo.
Y de nuevo gracias por el feedback. Un saludo.
El dom, 26 may 2024 a las 15:09, rlopdav392 @.***>) escribió:
REVIEW PARTE FRONTEND - GUILLE:
DISEÑO / FIGMA
=> prototipo mobile / desktop:
Eso que comentas que ha habido variaciones de diseño, entre fidelidad media y fidelidad alta, es normal, para eso están las diferentes versiones. Y luego también es normal, los cambios de diseño, entre el prototipo figma y la maquetación CSS.
No obstante, es importante que lo menciones tanto en la documentación como en la presentación.
=> Estructura de tu proyecto figma:
Pues hay muchas formas, a mí me gusta esta forma, que también he visto que la recomiendan en Internet: (https://www.youtube.com/watch?v=dz4VnO3_hto) https://www.youtube.com/watch?v=dz4VnO3_hto Un página para cada uno de estos apartados:
-
Assets / Componentes (en tu caso, "cosas a usar")
Fidelidad baja=> un frame por cada página de tu web
Fidelidad media=> un frame por cada página de tu web
Fidelidad alta => un frame por cada página de tu web
=> Reusable (Atomic design) => muy bien el uso de componentes maestros para las cards, las imágenes y los iconos. Te ha faltado también hacer componentes cards para la sección de “porque unirte a la familia de fithubx”.
Para diseñar esas cards que siguen un mismo patrón, arriba la imagen con un título y en la parte de debajo de la card, un párrafo, a mí me gusta la estructura que usa este youtuber:
(https://www.youtube.com/watch?v=tvanCYYHfnM) https://www.youtube.com/watch?v=tvanCYYHfnM
Yo, por ejemplo, veo más útil usar un layout y dentro del mismo un frame para la imagen, mejor que un grupo.
=> Responsive (responsive design) => importante detallar en la presentación / documentación nivel de responsive de tu prototipo.
=> Interacciones => muy bien el uso de interacciones entre las páginas.
=> Plantilla de átomos: Acuérdate que del diseño figma tiene que salir una plantilla de átomos que luego se actualizará en su maquetación CSS (https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view) https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view
=> Plugin de accesibilidad=> importante pasarle algún plugin de accesibilidad (able)
=> Patrones / Principios de diseño => importante explicar en la documentación los patrones y principios de diseño usados para el prototipo.
- Por ejemplo, lo que comentas en el vídeo, que en la sección de “nuestras instalaciones” usas un patrón Z.
MAQUETACIÓN CSS3
Importante no definas el width de las imágenes desde html, hazlo desde una regla CSS.
https://html.com/attributes/img-width/
=> variables: muy bien el uso de variables para los colors y las fuentes.
=> BEM (block__element—modifier):
Bien el uso del modifier de la metodología BEM en esta regla: user-menu—overlay
Puedes también aplicar element de la medotología BEM en algunas reglas.
Repasamos metodología BEM y te pongo al final de la explicación una extrapolación a tu código, por si te diese tiempo a usarla en alguna regla CSS:
BEM: block__element—modifier
-
Element es un container dentro de block, que solo puede existir dentro de block, fuera de ese container padre no tiene sentido.
Modifier: es un container que sale de modificar algún atributo de element, se podría decir que es una variante de element, de tal forma que herada de element todos los atributos, y a parte le aplica esa variante.
Extrapolación a tu código:
-
Nav => nav__enlaces
Card => card__tituloCard
Card => card__contenidoCard
=> SASS: acuérdate del preprocesador de CSS que vimos los últimos días en clase, por si te animas para usarlo en el otro aplicativo, es genial para conseguir más elegancia, ya que, además del uso de variables y del anidamiento de reglas, que ya te lo da el CSS puro, te permite crear bloques de código CSS reusables en diferentes reglas, a través de mixin y extend.
=> Documentación interna: documentado correctamente con comentarios parte CSS.
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (cuantas clases reusas en varios sitios, como los layouts (grid, flex), los botones, las listas, los espaciados (margin, padding),.., si haces uso de variables)
=> Código repetido html:
Al igual que separas el footer en una pieza/componente html aparte, para poder usarla en todas las páginas html, a través de una promesa, pues también podrías hacer lo mismo con el header, es otra pieza de puzzle, que la podemos hacer reusable, de la misma forma que has hecho con el footer.
Esta problemática, verás que ya no te surge con react, ya que en react, el big layout de la página principal, hay que definirlo, si o si, en componentes reusables. (header, main, footer)
=> Arquitectura de ficheros CSS: Es ok
=>SEO / html semántico: acuérdate de poner lo siguiente: title, meta descripción, imágenes con alt no vacío y favicon.
=> Big layout: el big layout, esto es, el super container que se encuentra entre las etiquetas body de una página html, ha de estar estructurado semánticamente bien, por ejemplo, si se trata de la página principal ha de estar divido en un header – main – footer. Y dentro del header han de estar los enlaces a través de un nav.
Eso está ok, yo lo que veo a mejorar, sería dentro del main, yo veo claramente 4 secciones, veo mejor para separar ese contenido, usar section en vez de div genérico, luego ya dentro las section, los div genéricos es ok.
=> Imágenes:
No parece que tengas imágenes de gran peso, solo veo una que es de 1.03MB
Importante pásale algún test de perfomarce (lighthouse, https://tools.pingdom.com/, https://pagespeed.web.dev/)
Si hubiese que optimizar puedes usar el formato webP.
Y comprueba cómo se ven en diferentes resoluciones, si mantienen la calidad o no. En caso de que no, tendrás que crear para una imagen, diferentes versiones según las resoluciones donde se vayan a renderizar, y eso se lo dices al navegador, con la etiqueta html picture => source
=> Responsive design -media querys: Importante detallar en documentación / presentación, pues cuantos breakpoints se han definidos, esto es, para cuantas resoluciones es responsive tu diseño.
=> Responsive design – layout grid / flex: acuérdate de explicar en la documentación / presentación los layouts que tienes implementados en tu página.
=> Responsive design – unidades relativas: haces uso tanto de unidades relativas (rem) como de unidades absolutas (px), esto es ok, si, por ejemplo, te interesa que algunos elementos sean fijos y no dependan del fontsize del navegador.
Pero pruébalo que tal queda, es decir, vete jugando con el Font size del navegador, vete cambiándolo para cada uno de los breakpoints definidos y mira que tal queda tu diseño.
=> Plantilla de átomos: Aquí un ejemplo de una plantilla de átomos con un nivel de detalle alto: (https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view) https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view
Acuérdate que esta plantilla de átomos no es más que una actualización de la plantilla de átomos que salió de la maquetación CSS.
JAVASCRIPT
=> Información dinámica / estática: Dejar bien claro en la presentación / documentación que sección de tu página son dinámicas, se cargan desde servidor, y cuales estáticas. En principio, por lo que he entendido, las cards de los diferentes planes y luego pues el contenido del usuario.
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (uso de funciones, librerías)
=> Documentación interna: se puede documentar con más comentarios javascript.
=> DOM: toda la parte javascript ponla siempre en los ficheros javascript, eventos onload y onClick han de ser tratados desde un addeventlistener en un fichero javascript y no desde HTML.
https://www.tutorialspoint.com/why-is-using-onclick-in-html-a-bad-practice
Importante, repasa que uses delegación, para la gestión de eventos, siempre que se pueda.
=> Arquitectura de ficheros: es OK, un file js por cada componente html.
REACT
Esta parte te faltaría, te adelanto un poco lo que podría llevar:
=>Información dinámica vs estática: Dejar bien claro en la presentación / documentación que sección de tu página son dinámicas, se cargan desde servidor, y cuales estáticas. Si es que tienes alguna parte de información estática.
=> Arquitectura de ficheros: esto es muy fácil, ya que en react cada jsx es un componente. Tendrás un jsx principal (main.jsx) que importará los jsx componentes.
=> Reusabilidad – abstracción código: haciendo uso de children en los componentes.
=> Riqueza React: useState / useEffect / Hooks personalizados / Context API, / UseRef / React-router-dom / react-modal / react-tostity PENDIENTE PARTE FRONTEND - GUILLE:
Pues de lo principal, por lo que veo en el código sería:
=> Crear los JSON de datosCards desde una llamada API a un endpoint laravel.
=> Y lo que comentas, cuando se haya logueado el usuario, que le aparezca pues el plan que tiene.
=> aplicativo React y prototipado figma para la versión mobile. Coge solo una página, la principal por ejemplo y la pasas a mobile.
— Reply to this email directly, view it on GitHub https://github.com/Guisseee/TFG-Guillermo-Jauregui-Lahoz/issues/3#issuecomment-2132236988, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5MWTHIII5MMGDUVKHKSKADZEHUK3AVCNFSM6AAAAABHUTTAIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGIZTMOJYHA . You are receiving this because you commented.Message ID: @.***>
rlopdav392
commented
4 months ago Vale, con hacer una sola página es suficiente, la principal por ejemplo.
Y no es necesario que implementes la conectividad con backend.
Que es lo que quiero ver, entonces en esa parte react:
Pues primero, saber definir la big layout en componentes reusables, haciendo uso de children
Y luego implementar la lógica de los eventos (addEventlistener), haciendo uso del hook useState
Y si te animas también puedes hacer uso de useEffect para lanzar alguna pequeña promesa a un json estático, por ejemplo.
Guisseee
commented
4 months ago Okay Rocio tomo noto y muchas gracias.
El El lun, 27 may 2024 a las 17:34, rlopdav392 @.***> escribió:
Vale, con hacer una sola página es suficiente, la principal por ejemplo.
Y no es necesario que implementes la conectividad con backend.
Que es lo que quiero ver, entonces en esa parte react:
Pues primero, saber definir la big layout en componentes reusables, haciendo uso de children
Y luego implementar la lógica de las interacciones, haciendo uso del hook useStat
Y si te animas también puedes hacer uso de useEffect para lanzar alguna pequeña promesa a un json estático, por ejemplo.
— Reply to this email directly, view it on GitHub https://github.com/Guisseee/TFG-Guillermo-Jauregui-Lahoz/issues/3#issuecomment-2133809540, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5MWTHPPD2JRPJFRG22CFKTZENOBRAVCNFSM6AAAAABHUTTAIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTHAYDSNJUGA . You are receiving this because you commented.Message ID: @.***>
Hola.
Te falta el diario de trabajo. Te falta comenzar a hacer la parte de servidor.