**Módulos**: Siempre trabajaremos con el sistema de Módulos de ECMAScript (ESM) en nuestro código. Aunque aún existen librerías en CommonJS (CJS), podemos usarlas como módulos e importarlas sin usar la sintaxis de `require`.
**Módulos**: Siempre trabajaremos con el sistema de Módulos de ECMAScript (ESM) en nuestro código. Aunque aún existen bibliotecas en CommonJS (CJS), podemos usarlas como módulos e importarlas sin usar la sintaxis de `require`.
**Evitar el entorno global**: Usemos las capacidades de los módulos para mantener nuestro entorno global limpio. No hay necesidad de declarar variables globales que ensucien todo y generar conflictos.
...
...
@@ -20,17 +20,17 @@ Una de las cosas más difíciles en la programación es asignar buenos nombres d
-**Idioma**: Dado que los lenguajes de programación que usamos están en inglés, hemos acordado usar este idioma en nuestro código. Respetamos y nos gusta el idioma en el que hablamos pero el código en "espanglish" puede ser muy molesto y aumentar la carga cognitiva.
-**Variables y funciones**: Usamos **`camelCase`**. Los nombres de variables deben ser sustantivos que describan su contenido (ej., `userId`, `userName`), y los de las funciones, verbos que indiquen lo que hacen (ej., `fetchUsers`, `calculateTotal`, `getSomeShit`)... tener cuidado con palabras genéricas como `info` o `data` y de ser posible optar por algo más descriptivo de la información que contienen.
-**Variables y funciones**: Usamos **`camelCase`**. Los nombres de variables deben ser sustantivos que describan su contenido (ej., `userId`, `userName`), y los de las funciones, verbos que indiquen lo que hacen (ej., `fetchUsers`, `calculateTotal`, `getSomeShit`)... tener cuidado con palabras genéricas como `info` o `data` y de cuando sea posible optar por algo más descriptivo de la información que contienen.
-**Tipos, clases y componentes**: Usamos **`PascalCase`**. Esto ayuda a diferenciarlos del resto del código (ej., `UserType`, `ProductCard`).
-**Constantes de configuración**: Usamos **`SCREAMING_SNAKE_CASE`**. Son constantes que se usan para una configurar un comportamiento del código, su nombre en mayúsculas debe dejar muy claro la info que contienen (ej., `API_URL`, `MAX_RETRIES`, `I_AM_A_MAGIC_NUMBER`).
## Librerías Externas
## Bibliotecas Externas
Importar debe suceder solo cuando algo es realmente necesario. Evitamos importar por importar y nos aseguramos de que las librerías que usamos estén bien mantenidas y sean de alta calidad.
Importar debe suceder solo cuando algo es realmente necesario. Evitamos importar por importar y nos aseguramos de que las bibliotecas que usamos estén bien mantenidas y sean de alta calidad.
Un ejemplo de lo que puede salir mal es el caso de **`left-pad`**. Una librería con una función simple (no más de cinco líneas de código), que, al ser eliminada de NPM(Luego de eso se reforzó la política de no borrado de NPM), causó que miles de proyectos dejaran de compilar. [El chisme completo](https://en.wikipedia.org/wiki/Npm_left-pad_incident).
Un ejemplo de lo que puede salir mal es el caso de **`left-pad`**. Una biblioteca con una función simple (no más de cinco líneas de código y bastante innecesaria si se conocen los métodos para `String`), que, al ser eliminada de NPM(Luego de eso se reforzó la política de no borrado de NPM), causó que miles de proyectos dejaran de compilar. [El chisme completo](https://en.wikipedia.org/wiki/Npm_left-pad_incident).
**Cada dependencia es una responsabilidad.**
...
...
@@ -38,8 +38,8 @@ Por lo tanto:
- Solo importamos cuando la lógica del proyecto no depende de la importación.
- Solo importamos si hemos confirmado que no hay una forma directa o clara de realizar lo que necesitamos con nuestro propio código dentro del tiempo que disponemos.
- Solo importamos librerías que tengan soporte activo (al menos un año).
- Solo importamos librerías con tipado en TypeScript nativo para integrarlas mejor.
- Solo importamos bibliotecas que tengan soporte activo (al menos un año).
- Solo importamos bibliotecas con tipado en TypeScript nativo para integrarlas mejor.
## Accesibilidad
...
...
@@ -73,7 +73,7 @@ Idealmente, los nombres y la estructura de nuestro código deberían ser tan cla
## Aduana: Importaciones y exportaciones
El orden de las importaciones es crucial para la legibilidad y una estructura consistente en todo nuestro codigo, el orden acordado es, primero las **librerías externas** y dependencias de `node_modules`, como `leaflet` o `axios`, seguidas por los **módulos internos**, que son los archivos de nuestro _codebase_ (lo que hay dentro de `src/`), estos últimos siempre deben ser importados con rutas absolutas o alias.
El orden de las importaciones es crucial para la legibilidad y una estructura consistente en todo nuestro codigo, el orden acordado es, primero las **bibliotecas externas** y dependencias de `node_modules`, como `leaflet` o `axios`, seguidas por los **módulos internos**, que son los archivos de nuestro _codebase_ (lo que hay dentro de `src/`), estos últimos siempre deben ser importados con rutas absolutas o alias.
Además, como equipo, evitamos las exportaciones `default` para tener un mejor seguimiento de los elementos. Esto nos asegura que siempre importemos con el nombre exacto (`import { Button } from '...'`), o que si cambiamos el nombre, sea de forma consciente, evitando confusiones.
## Componentes de Función: La preferencia del equipo
No hay razón para seguir escribiendo componentes de clase, son una tecnología vieja que se evitamos en nuestras aplicaciones. Los componentes de función, junto con los _Hooks_, ofrecen una forma más simple y directa de manejar el estado, la sincronización y los efectos secundarios, lo que resulta en un código más limpio y fácil de depurar.
No hay razón para seguir escribiendo componentes de clase, son una tecnología vieja que evitamos en nuestras aplicaciones. Los componentes de función, junto con los _Hooks_, ofrecen una forma más simple y directa de manejar el estado, la sincronización y los efectos secundarios, lo que resulta en un código más limpio y fácil de depurar.
## Estructura y Organización
Los componentes deben tener una única responsabilidad. Los que orquestan, renderizan y hacen malabares al mismo tiempo, fácilmente se convierten en un nido de _bugs_, que fácilmente crean condiciones de carrera o bucles de renderizado.
la estructura de los componentes en el archivodebe ser la siguiente:
la estructura de los componentes en el archivodebe ser la siguiente:
@@ -101,7 +101,7 @@ Y para cierre... del useEffect... si un efecto crea una suscripción o un tempor
## useMemo y useCallback
No agarrarlos por default ni meterlos hasta en la sopa. Estos hooks tienen un costo de memoria y de complejidad que no siempre vale la pena. Úsalos solo cuando sea necesario, parte de esta idea: empezar sin ellos y agrégalos solo cuando veas un problema de rendimiento o un re-render innecesario que impacte el performance o la UX.
No agarrarlos por default ni meterlos hasta en la sopa. Estos hooks tienen un costo de memoria y de complejidad que no siempre vale la pena. Úsalos solo cuando sea necesario, parte de esta idea: empezar sin ellos y agrégalos solo cuando veas un problema de rendimiento o un re-render innecesario que impacte el rendimiento o la UX.
## Código ordenado
...
...
@@ -133,7 +133,7 @@ Para mantener el código claro, un handler debe tener una sola responsabilidad,
### Manejo de Errores Asíncronos
Cada llamada a una API o operación async debe estar envuelta en un bloque try-catch o un chaininng `.then().catch()` apropiado, y los errores deben ser manejados de manera uniforme en toda la aplicación.
Cada llamada a una API u operación async debe estar envuelta en un bloque try-catch o un chaininng `.then().catch()` apropiado, y los errores deben ser manejados de manera uniforme en toda la aplicación.
Una estrategia son los estados de error en hooks personalizados permiten centralizar la lógica de manejo de errores y reutilizarla en múltiples componentes. Lo que ayuda con la consistencia en cómo se manejan los errores en toda la aplicación y facilita el mantenimiento del código.
...
...
@@ -149,7 +149,7 @@ function useFetchData(url: string) {
try{
constresponse=awaitfetch(url);
if(!response.ok){
thrownewError('No se pudo cargar la data.');
thrownewError('No el servidor no retornó la información solicitada.');
