Pero en esta área nuestro equipo si tiene opiniones y acuerdos que modifican las reglas base y responden a el cómo vemos el código y las experiencias que hemos tenido.
Pero en esta área nuestro equipo si tiene opiniones y acuerdos que modifican las reglas base y responden a cómo vemos el código y las experiencias que hemos tenido.
**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.
**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 ensucian todo y crean potenciales conflictos..
**Clases con propósito**: No creemos clases solo para encapsular un conjunto de variables y funciones, eso lo puede hacer mejor un módulo. Las clases deben cumplir un propósito de arquitectura, como implementar un patrón de diseño (di tu un _singleton_) o manejar un estado interno complejo y persistente.
...
...
@@ -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 cuando sea 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 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`).
-**Constantes de configuración**: Usamos **`SCREAMING_SNAKE_CASE`**. Son constantes que se usan para 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`).
## Bibliotecas Externas
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 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).
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 paquetes en 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.**
...
...
@@ -47,9 +47,9 @@ Construir una interfaz de usuario no es solo cuestión de estética. La accesibi
**HTML Semántico**: Usa las etiquetas correctas (`<button>`, `<nav>`, `<article>`, ... ) en lugar de `<div>` como mantequilla en restaurante francés. El HTML semántico es clave para construir aplicaciones web accesibles desde el inicio, ayudando a los lectores de pantalla a entender la estructura de la página, facilitando la navegación con tecnologías asistivas y mejorando el SEO. [Aquí hay una pequeña guía](https://webdesign.solomon.ng/html-and-css/semantic-html/semantic-html.html).
**Atributos `aria-*`**: Una vez que nuestro documento está bien estructurado, los usuarios con tecnologías asistivas deben ser capaces de comprender los cambios que introducimos en el documento a través de las interacciones. Aquí es donde entra `aria-*`, que complementa lo que el HTML no cubre. Sin embargo, _no aria is better than wrong aria_(Es mejor no tener aria a tener uno mal escrito). Si no entiendes el atributo, investiga antes de usarlo. [Esta es una buena introducción a ARIA](https://accessibilityfordevelopers.com/guide-to-aria/) y [aquí está la guía de MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA), que es más amigable que las especificaciones de la W3C.
**Atributos `aria-*`**: Una vez que nuestro documento está bien estructurado, los usuarios con tecnologías asistivas deben ser capaces de comprender los cambios que introducimos en el documento a través de las interacciones. Aquí es donde entra `aria-*`, que complementa lo que el HTML no cubre. Sin embargo, _no aria is better than wrong aria_(Es mejor no tener aria a tener uno mal escrito). Si no entiendes el atributo, investiga antes de usarlo. [Esta es una buena introducción a ARIA](https://accessibilityfordevelopers.com/guide-to-aria/) y [aquí está la guía de MDN](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA), que es más amigable que las especificaciones de la W3C.
**Manejo de Foco**: Es clave que todo lo que se puede hacer con el _mouse_ también se posible hacerlo con el teclado. Asegúrate de que los elementos sean enfocables y que el orden del foco sea lógico.
**Manejo de Foco**: Es clave que todo lo que se puede hacer con el _mouse_ también sea posible hacerlo con el teclado. Asegúrate de que los elementos sean enfocables y que el orden del foco sea lógico.
@@ -74,13 +74,13 @@ El uso de literales es recomendado para un conjunto de valores fijos y acotados.
**`any`**: **NO USARLO NUNCA**, salvo que estemos en proceso de migrar algo de JS a TS. Es la peor práctica y anula completamente el propósito de TypeScript.
**`unknown`**: Este es el tipo de dato que debes usar cuando no sabes qué tipo va a entrar. Después, usa _type narrowing_ para trabajar con el valor.
**`unknown`**: Este es el tipo de dato que debes usar cuando no sabes qué tipo va a entrar. Después, usa _type narrowing_ para trabajar con el valor. si tienes dudas sobre _type narrowing_ esta [guía rápida sobre type narrowing](https://dev.to/hichembenchaabene/typescript-type-narrowing-a-comprehensive-guide-4kkm) es bastante completa y rápida de leer.
**`never`**: Se usa para indicar que una función **nunca** retorna un valor (ej., una función que siempre lanza un error o entra en un bucle infinito).
## Helpers y Tipos Utilitarios
**Type Guards**: Son funciones especializadas que validan y refinan el tipo de un valor en tiempo de ejecución. Estas nos sirven para retener la info del tipo en la ejecución y tienen la firma característica `(myValue: unknown): myValue is Type`, donde el valor de retorno booleano determina si TypeScript debe tratar el valor como el tipo especificado. Son fundamentales para trabajar de forma segura con datos de origen incierto, como respuestas de APIs, entrada del usuario, o cualquier valor de tipo unknown o any
**Type Guards**: Son funciones especializadas que validan y refinan el tipo de un valor en tiempo de ejecución. También son usadas en _type narrowing_ y nos sirven para retener la info del tipo en la ejecución y tienen la firma característica `(myValue: unknown): myValue is Type`, donde el valor de retorno booleano determina si TypeScript debe tratar el valor como el tipo especificado. Son fundamentales para trabajar de forma segura con datos de origen incierto, como respuestas de APIs, entrada del usuario, o cualquier valor de tipo unknown o any
summonEntity({name:"Asmodeo",powerLevel:666});// → "Asmodeo aparece con poder 666"
```
**`Partial`, `Pick`, `Omit`, and shit...**: Los tipos utilitarios de TypeScript son poderosos. En lugar de crear un tipo nuevo cada vez que necesitas una variante de un tipo ya existente, usar utilitarios.
**`Partial`, `Pick`, `Omit`, and shit...**: Los tipos utilitarios de TypeScript son poderosos. En lugar de crear un tipo nuevo cada vez que necesitas una variante de un tipo ya existente, usar los utilitarios para crear un tipo derivado, [acá un ejemplo](https://youtube.com/shorts/4CYkhXIDxeQ?si=YwakdrVEdq2LGjxS).
---
[Volver al menú principal](../frontend-structure.md) | [Siguiente: Buenas Prácticas en React](./5-buenas-practicas-en-react.md)
@@ -72,7 +72,37 @@ function idToDemonName(id: number): string {
El JSX no es entorno amable para leer, por lo que el `return` debe ser lo más limpio posible. Toda la lógica compleja como los cálculos de estado, la preparación de datos, las condiciones de renderizado y los _handlers_ debe hacerse antes del `return`.
Por una cuestión de claridad y consistencia, evitamos los `early returns` en los componentes y centralizar la lógica de lo que se renderiza o no al final del componente.
Por una cuestión de claridad y consistencia, evitamos los `early returns` en el renderizado de componentes. En su lugar, centralizamos toda la lógica de lo que se renderiza al final. Sin embargo, ojo, los `early returns` en otras funciones están totalmente permitidos, recomendados, aplaudidos y premiados con carita feliz. A esto nos referimos con `early returns` en el renderizado de componentes:
```tsx
// Componente malo, pao pao, eso no se hace
functionMyBadComponent(){
// la logica del componente, hooks and shit...
if(withoutBaphometInYourHeart){
return(
<h1>Un retorno precoz</h1>
)
}
// otras vainas
return(
<h1>El retorno final del componente</h1>
)
}
// Componente bueno y con carita feliz
functionMyGoodComponent(){
// Toda la lógica del componente y la vaina
return(
{iHaveBaphometInMyHeart
?<h1>Soy lo que sale si Baphy está en mi corazón</h1>
:<h1>Aunque no tienes a Baphy en tu corazón, el componente está bien</h1>
}
)
}
```
El `return` debe contener únicamente:
...
...
@@ -93,7 +123,7 @@ Para manejar el estado, usamos `useState` para estados simples, como booleanos,
## Sincronización (`useEffect`)
Dejemos de pensar en `useEffect` como una simple herramienta para efectos secundarios, tomémoslo como un mecanismo de para la sincronización del componente con sistemas externos (fetch, localstorage, etc). Como se sugiere [You might not need an effect](https://react.dev/learn/you-might-not-need-an-effect), a menudo no se necesita un efecto, por lo que es vital usarlo solo cuando es necesario y para lo que fie creado.
Dejemos de pensar en `useEffect` como una simple herramienta para efectos secundarios, tomémoslo como un mecanismo para la sincronización del componente con sistemas externos (fetch, localstorage, etc). Como se sugiere [You might not need an effect](https://react.dev/learn/you-might-not-need-an-effect), a menudo no se necesita un efecto, por lo que es vital usarlo solo cuando es necesario y para lo que fue creado.
Para mantener la claridad y la consistencia, haz que cada `useEffect` se encargue de un solo aspecto. Si un componente necesita múltiples `useEffect`, esto podría ser un indicio de que está asumiendo demasiadas responsabilidades y que la arquitectura debe ser revisada.
...
...
@@ -133,9 +163,9 @@ Para mantener el código claro, un handler debe tener una sola responsabilidad,
### Manejo de Errores Asíncronos
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.
Cada llamada a una API u operación asíncrona debe estar envuelta en un bloque try-catch o un encadenado`.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.
Una estrategia son los estados de error en hooks personalizados que 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.
@@ -8,7 +8,7 @@ Escribe código para humanos. La legibilidad y sostenibilidad son más important
Gestiona las dependencias de forma responsable y prioriza la accesibilidad partiendo de estructurar un HTML semántico. En TypeScript no des lugar a `any`; preferiere `unknown` y la validación de tipos. En React, escribe componentes de Función con una sola responsabilidad y escribe el JSX libre de lógica compleja...
Maneja los errores de forma explícita para ofrecer una buena experiencia de desarrollo tus compañeros y una de usuario más robusta.
Maneja los errores de forma explícita, para ofrecer una buena experiencia de desarrollo a tus compañeros y una experiencia de usuario robusta.
## Índice de Contenidos
...
...
@@ -33,18 +33,18 @@ Maneja los errores de forma explícita para ofrecer una buena experiencia de des
-[Vamo' a calmarno'](./front/4-buenas-practicas-en-typescript.md#vamo-a-calmarno)
-[Constantes con enums y posibilidades con literales](./front/4-buenas-practicas-en-typescript.md#constantes-con-enums-y-posibilidades-con-literales)
-[`any`, `unknown` y `never`](./front/4-buenas-practicas-en-typescript.md#any-unknown-y-never)
-[Helpers y Tipos Utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
-[Helpers y Tipos utilitarios](./front/4-buenas-practicas-en-typescript.md#helpers-y-tipos-utilitarios)
5.[Buenas Prácticas en React](./front/5-buenas-practicas-en-react.md)
-[Componentes de Función: La preferencia del equipo](./front/5-buenas-practicas-en-react.md#componentes-de-función-la-preferencia-del-equipo)
-[Componentes de función: La preferencia del equipo](./front/5-buenas-practicas-en-react.md#componentes-de-función-la-preferencia-del-equipo)
-[Estructura y Organización](./front/5-buenas-practicas-en-react.md#estructura-y-organización)
-[Props: Cómo pasar y gestionar propiedades](./front/5-buenas-practicas-en-react.md#props-cómo-pasar-y-gestionar-propiedades)
-[Manejo de Estados: Estrategias claras](./front/5-buenas-practicas-en-react.md#manejo-de-estados-estrategias-claras)
-[Manejo de estados: Estrategias claras](./front/5-buenas-practicas-en-react.md#manejo-de-estados-estrategias-claras)
