Digital Market - Frontend

💻 Aplicación Frontend de Digital Market

🛠️ Pasos de instalación:

1. Clone el repositorio en su máquina local utilizando claves SSH.

git clone [email protected]:realDiegoR/digital-market.git

2. Instalar dependencias utilizando el gestor de paquetes PNPM. Si no lo tienes instalado, esta es la guía oficial.

pnpm install

3. Iniciar un entorno de desarrollo y comenzar a realizar cambios.

pnpm dev

📂 Estructura de carpetas

• .github/: incluye datos de configuración del repositorio remoto, como por ejemplo correr pruebas automatizadas.
• .husky/: incluye los "git hooks" del repositorio. Son comandos que se ejecutan antes o después de un comando de git para asegurar que se siguen protocolos en el desarrollo. Por ejemplo, correr eslint antes de un commit.
• public/: archivos que no serán manipulados por Vite. Serán utilizados "como son". Por ejemplo, el archivo favicon.ico.
• .env / .env.example: el archivo .env almacena variables secretas de la aplicación que nadie debe conocer, como podría ser una llave secreta de una API. Como este archivo no se sube al repositorio, debes crearlo tú mismo y rellenar su contenido. El archivo .env.example contiene el nombre de todas las variables que deberías tener en tu archivo .env local.
• src/
  • common/: componentes pequeños y reutilizables en toda la aplicación. No poseen lógica, comúnmente llamados "stateless".
  • components/: componentes medianos y reutilizables en toda la aplicación. Poseen lógica para el correcto funcionamiento de la aplicación, comunnmente llamados "stateful".
  • layouts/: componentes que representan una maquetación reutilizable por varias páginas.
  • hooks/: custom hooks que abstraen lógica de la aplicación de los componentes.
  • constants/: información constante de la aplicación que es mejor abstraerla en su propio módulo para ser reutilizada o intuitiva.
  • services/: funciones asíncronas que cumplen un único propósito.
  • stores/: stores que almacenan los estados globales de la aplicación.
  • pages/: componentes que representan el contenido de una URL.
    • app.jsx: núcleo de la aplicación. Representa cada ruta existente con su información y comportamiento.
  • main.jsx: archivo de entrada de la aplicación. A partir de él se renderiza toda la aplicación cuando se ejecuta pnpm dev/ o pnpm build/.
  • main.css: único archivo CSS de toda la aplicación. Importa todas las clases de Tailwind que se usarán posteriormente.

⚙️ Flujo de trabajo con GitHub

Nombre de commits

Los commits deben ser escritos bajo la convención Conventional Commits. Este artículo lo describe muy bien.

Los nombres de las ramas deben seguir esta convención también. Los dos puntos (:) se reemplazan por un slash (/).

Esta convención ayuda mucho a entender el propósito de cambios y modificaciones.

Ejemplo

• Rama que arregla un typo en la página de Home: fix/typo in homepage
• Commit que agrega un nuevo componente: feat: add button component

Marco de trabajo para trabajar en el código

Para crear y modificar código en este proyecto, se debe seguir el marco de trabajo llamado GitHub Flow.

Reglas a resaltar sobre el GitHub Flow

• Nunca hacer ningún cambio en la rama main. Para hacer cualquier tipo de cambio al código, se debe crear una rama nueva de git.
• Ninguna rama debe ser "mergeada" manualmente a la rama main. Cuando una rama esté lista para ser integrada al proyecto, se debe hacer un push de la rama hacia el repositorio remoto y crear una Pull Request.
• Cada Pull Request (PR) debe ser aprobada por los miembros los líderes de equipo utilizando las herramientas de GitHub y debe pasar las pruebas automatizadas. Si se estos campos se cumplen, la rama puede ser mergeada a la rama main. IMPORTANTE: esto que he mencionado se puede configurar de forma estricta en un repositorio público, pero en repositorios privados se debe tener un plan Team, el cual no tenemos. Por lo tanto, una rama puede ser mergeada sin haber pasado los tests o sin aprobación de un Code Reviewer, o incluso se puede modificar la rama main sin ningún tipo de protección. No permitimos bajo ninguna circunstancia este comportamiento, y sugerimos ser cuidadosos con acciones tomadas en este repositorio de GitHub.
• Cada rama y Pull Request debe cumplir con un solo proposito en especifico. No es el deber ser que en una rama hayan demasiados cambios y nuevo código. Eso puede ser una señal de que se están haciendo muchas cosas distintas en una sola rama.

💻 Construido con

Tecnologías utilizadas en el proyecto:

• React.js → Librería UI.
• React Router DOM → Manejador del enrutamiento y la transferencia de datos entre páginas.
• Zustand → Manejador del estado global de la aplicación.
• TanStack Query (a.k.a. React Query) → Manejador de estados asíncronos.
• Axios → Cliente HTTP utilizado para realizar peticiones asíncronas.
• Tailwind CSS → Framework de CSS. Es altamente personalizable y basado en utility-classes.
• Vite.js → Empaquetador de módulos.
• Vitest/React Testing Library → Corredor de test unitarios y de integración.
• ESLint → Code linting
• Prettier → Formateo de código
• Husky → Git Hooks