La estructura de carpetas que uso en react - sábado, 24 de febrero de 2024

La estructura de React

Cada quien estructura las carpetas como le gusta o basado en sus necesidades; hoy te voy a contar cómo suelo estructurar mis carpetas.

En este ejemplo, tomaré como referencia la estructura de carpetas de la página de Zeew Space.

Carpetas principales

Las carpetas principales son las que me guían en el orden de mi estructura. Obviamente, hay carpetas que pueden ser opcionales o debemos incluir aunque no lo veamos en este ejemplo.

src
├───components
├───context
├───hooks
├───pages
├───store
├───styles
├───types
└───utils

Components

• components: Aquí es donde guardo todos mis componentes principales, tanto las interfaces de usuario como los bloques de contenido y utilidades.

Y te estarás preguntando, ¿qué son las utilidades? Supongamos que estamos usando fechas, y estas fechas tienen un formato, ya sea una cuenta regresiva o tiempo relativo, algo estilo “hace 3 minutos”. Pues bien, eso lo pongo en un componente porque podría usarlo en otros lugares en caso de necesitarlo. Es aquí donde me refiero a “Componentes de utilidad”.

components
│   ├───layouts
│   ├───ui
│   │   ├───accordion
│   │   ├───cards
│   │   ├───dropdown
│   │   ├───input
│   │   ├───modal
│   │   ├───tabs
│   │   ├───textarea
│   │   └───toggle-group
│   └───utils

Context

• context: Aquí es donde guardo todo lo relacionado con estados globales. Algunos también lo llaman “store”, pero sería más la lógica de los estados globales.

Hooks

• hooks: Para los que son nuevos, los hooks son pedazos de código que realizan alguna lógica importante. Por ejemplo, el “useState” es un hook que nos ayuda a manejar los estados.

Pero muchas veces, creamos hooks personalizados basados en nuestras necesidades, como este ejemplo:

import { useState, useEffect } from 'react';

export const useCountdown = (endDate: Date | string) => {
    // ... (código del hook)
};

Este es un hook personalizado para tener una cuenta regresiva; le pones la fecha y este empieza a hacer su magia.

Pages

• pages: Independientemente de si estoy trabajando en React puro o Next, me gusta tener un orden de las páginas que voy a tener, aunque sea solamente una landing page. Esto me ayuda a saber realmente cuáles son mis páginas y cuáles son configuraciones o archivos iniciales.

├───pages
│   ├───ajustes
│   │   ├───compras
│   │   └───conexiones
│   ├───blogs
│   ├───cursos
│   │   └───[slug]
│   │       └───clase
│   │           └───[id]
│   ├───eventos
│   ├───login
│   ├───mis-cursos
│   ├───register
│   └───user

Store

• store: Como mencioné antes, la lógica de los estados globales. Lo llamo “store” porque ahí pongo todo lo necesario para utilizar estados globales. Aunque esto realmente es opcional, puedes hacerlo en “context” y listo, o incluso en un “customHook”.

Styles

• styles: Esto creo que se explica por sí solo. Aunque realmente soy fan de usar Tailwind, si necesito hacer algunos estilos propios, aquí es donde los guardo, e incluso la configuración de Tailwind.

Types

• types: Cuando trabajo en TypeScript, que es el 90% de todos mis proyectos, tengo una carpeta donde guardo todo el sistema de tipado.

Utils

• utils: Finalmente, tenemos la carpeta de utils, donde guardo todas las constantes, configuración, código de parseo, cosas que me van a ayudar a no repetir código o cambiar de uno a otro. También suelo ordenarlo, aunque suelo usar un archivo único llamado en mayúsculas “CONSTANTS”. En este ejemplo, se separaron las constantes dependiendo de lo que necesitamos al construir la web de Zeew Space.

Y si te preguntas qué son los “MOCKS”, es un JSON de ejemplo de lo que nos mandaría la API, así evitamos hacer peticiones a la API, ya sea para evitar sobrecargarlo por cada reinicio al momento de editar o porque tiene un sistema de autenticación y para evitar logeos o pérdida de datos por sesión. Nos ayuda bastante.

└───utils
    ├───CONSTANTS
    └───Mocks

En conclusión

Esta es la estructura que suelo usar. Tuve que enseñarle al equipo cómo estructurar el proyecto, ya que saben tocar código, pero hubo problemas al tener demasiadas carpetas o archivos, o se volvió complicado entender dónde está cada cosa.

Al final, cada quien es libre de estructurarlo como guste. En lo personal, creo que si alguien que no ha tocado el proyecto se une y solo con ver la estructura sabe dónde está cada cosa, considero que es una buena estructura.