search

frontendcafe / air-flashcards

https://air-flashcards.netlify.app/
6 stars 2 forks source link

readme

Proyecto Air

App Flashcards

Notion del proyecto

Documentos importantes

Estructura de carpetas

src/ 
└───modules/
│   └───firebase/
|   └───auth.tsx
|   └───firebase-utils.ts
|   └───firebase-types.ts
|   └───...
│   └───Home/
|   └───components/
|   |   └───HomeForm.tsx
|   |   └───homeForm.module.css
|   └───HomeView.tsx
|   └───home-hooks.ts
|   └───home.module.css
|   └───home-utils.ts
|   └───home-types.ts
|   └───...
│   └───collections/
|   └───CollectionDetailView.tsx
|   └───CollectionUpdateView.tsx
|   └───CollectionCreateView.tsx
|   └───Collection-utils.ts
|   └───...
│   └───another-module/
|   └───components/
|   └───...
|   └───AnotherView.ts
|   └───another-store.ts
|   └───...
│   └───shared/
|   └───components/
|   |   └───buttons/
|   |   └───text/
|   |   └───forms/
|   └───SomeComponent.ts
|   └───AnotherUnclassifiedComponent.ts
|   └───assets/
|   |   └───images/
|   |   |   └───logo.png
|   |   |   └───background_main.jpg
|   |   |   └───...

assets carpeta

Carpeta que contienen archivos de imagenes como: png, svg, jpg, etc

modules carpeta

Carpeta principal para especificar modules

shared carpeta

Carpeta para utilidades y components que se deberian compartir atraves de modulos

components carpeta

Componentes de react, pueden ser especificados en shared/components/ o modules/<module-name>/components/

*-utils archivo

Funciones o clases, pueden ser especificados en shared/ o modules/<module-name>/

*.module.css archivo

Archivo css para especificar los estilos del componente o modulo

¿Cómo sé si lo que estoy haciendo va en un módulo aparte o en shared?

Una manera fácil de saber si tu código se comporta como un módulo, es ver si tiene funciones o características que se llaman entre sí para cumplir un propósito. Por ejemplo, el module de Firebase no es un módulo que tenga una vista, pero sí tiene una lógica que necesita tener una capa de abstracción para que los otros módulos puedan acceder a sus funcionalidades fácilmente. En shared principalmente deberían ir componentes, funciones, constantes etc. Que se comportan a nivel de la aplicación y se necesiten en varios módulos a la vez.

Lo ideal si tienes una funcion o componente que veas que se requiera en otro módulo es que muevas esa función a shared, ya que no deberíamos tener imports entre módulos, osea que el módulo de Home no importe nada del Modulo de Login

Variables de ambiente

Crea un archivo .env en el root del proyecto, y agrega los siguientes valores para poder conectarte a Firebase:

NEXT_PUBLIC_FIREBASE_API_KEY=...
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=...
NEXT_PUBLIC_FIREBASE_PROJECT_ID=...
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET=...
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID=...
NEXT_PUBLIC_FIREBASE_APP_ID=...

Podrás encontrar esto también en el archivo .env.example. Para encontrar los valores que debes reemplazar por ... debes acceder a este enlace

Contribuir al Proyecto

Para contribuir al proyecto, lo ideal es basarse en el siguiente paso a paso:

1) Issue

Este es el punto de partida de cualquier tarea. Ingresa al board del proyecto, y asígnate el issue que vayas a realizar. Lo ideal es que sea uno que se encuentre en la columna TODO. Chequea que tenga una descripción clara y apropiada, y un scope bien definido para que cuando hagas los cambios, tanto vos como quien revise tu Pull Request sepa cuál es el objetivo y qué debe aprobar o no aprobar. Si el issue no existe, podés crearlo bajo estos mismos requisitos. Por último, pasá este issue que te asignaste a la columna In Progress.

2) Creá una branch

Deberás pararte en tu branch main, habiendo pulleado los últimos cambios de esa rama, y desde allí, crear una nueva siguiendo la siguiente convención: (Rama-padre)-(Tipo)/(Numero de la issue)-(Descripcion corta)

Ejemplo:

3) A medida que avances, haz commits

Los commits son el historial de un proyecto. Indican qué se hizo a lo largo del tiempo, y tener buenos commits, nos permite tener un mejor control sobre la historia de nuestro código, permitiéndonos volver al pasado y recuperar cambios, volver hacia atrás si algo salió mal en alguno de ellos, y muchas otras ventajas. Al ser el historial del proyecto, también serán el historial de tu Pull Request, así que tratalos con cariño. Además, permiten al reviewer al leerlos, entender cuál fue el proceso mental que siguió el autor para desarrollar ese Pull Request. Para crear commits bonitos, sigue esta convención a la hora de elegirles un mensaje:

  <type>[scope]: <description>

  [optional body]

Por ejemplo: feat(RegisterForm): add prop submitLabel to show in submit button

Puedes incluso ser más específico aclarando exactamente dónde se encuentra el directorio y archivo que modificaste, pero eso dejaría tu commit muy largo, y la idea es que sean algo fácil de leer y entender. Más info sobre Conventional Commits

4) Creá un Pull Request

Puedes crear el Pull Request tanto cuando empieces a codear como al terminar, aunque te recomendamos hacerlo al inicio para poder ir viendo cómo vas avanzando y hacerte comentarios que puedan ahorrarte tiempo. Si lo haces de esta manera, no olvides poner al inicio del nombre del PR [WIP] (Work In Progress), para indicar que aún no está listo para ser revisado. Luego, nómbralo siguiendo la siguiente convención:

[Rama a mergear] [Tipo] [Pequeña descripcion]

Ejemplo:

Responde y debate con tus compañeros las consultas que hagan sobre tu código, y está atento para revisar también los que suben los otros participantes para dar tu feedback. Es PR es el momento en el que chequeamos que lo que llega a main es correcto y hubo personas que validaron esos cambios. Es un momento de enorme aprendizaje así que te recomendamos aprovecharlo. Haz los cambios que hayan considerado necesarios en los comentarios, y luego espera que te lo aprueben al menos dos personas para finalmente, mergear. La idea es que los PR no se traben mucho tiempo para evitar Merge Conflicts.