Principios para la Gestión de la Deuda Técnica

A continuación se presentan algunos principios:

• La deuda técnica no es una noción abstracta, es algo bien concreto: se puede demostrar que la deuda técnica no es solo una metáfora elegante o un “concepto al aire” sino que tiene manifestaciones reales en el sistema ya sea en el código, arquitectura, o en los procesos. Para poder gestionarla, se necesita identificar donde está y rastrearla (o tracearla).
• La deuda técnica solo existe si incurre en “intereses”: si no se incurre en ninguna forma de interés, generando sobrecostos, impedimentos o riesgos adicionales con el tiempo como entonces probablemente no exista TD. O mejor dicho no está activa, esta situación es para preocuparse. El concepto de “interés” es clave donde lo que hoy no genera problemas, mañana puede empezar a hacerlo. Aquí se debe monitorear las decisiones que toma el equipo.
• Todos los sistemas tienen alguna forma de deuda técnica: es imposible eliminar toda la deuda técnica porque es inherente al desarrollo de software ya sea porque cambian los requisitos, tecnologías, contextos, etc. La clave no es eliminarla, sino gestionar su nivel y su impacto.
• La deuda técnica debe estar vinculada al sistema: esta frase se asocia al concepto de trazabilidad. Para poder actuar, necesito localizarla, saber su causa y su impacto. No sirve de nada decir “hay deuda técnica” si no sabemos dónde ni cómo afecta al sistema.
• La deuda técnica no es sinónimo de mala calidad: no todo lo que llamamos deuda técnica es “mala calidad”. Muchas veces, lo que es mala calidad es lo que está hecho mal desde el inicio, sin justificación y sin plan de corrección. Hay deuda técnica estratégica o aceptable como lanzar una funcionalidad rápido para validar el mercado.
• La deuda técnica en arquitectura es la más costosa de abordar: es la más costosa a nivel costo y esfuerzo. A nivel arquitectónico suele tener un impacto mucho mayor a diferencia de nivel de código, afectando escalabilidad, mantenibilidad, interoperabilidad. Es clave priorizar el pago de deuda antes que crezca e invertir en revisiones periódicas de la arquitectura.
• El código fuente es el principal artefacto, pero no el único: Aunque la mayor parte de la deuda técnica se manifiesta en el código fuente, también puede encontrarse en infraestructura, requerimientos, documentación, casos de pruebas, etc. Esto implica ampliar la visión de deuda técnica más allá del código.
• No existe una métrica absoluta para cuantificar la deuda técnica: no existe una fórmula única o estándar para medir el “monto principal” o los “intereses” de la deuda técnica. Cada sistema, equipo y contexto tienen sus propios criterios. Posiblemente, se deba combinar métricas cuantitativas (complejidad ciclomática, cobertura de tests, issues abiertos) y cualitativas (opinión del equipo, feedback de usuarios), como definir criterios internos de aceptación y tolerancia a deuda técnica.
• La deuda técnica depende de la evolución futura del sistema: Una decisión técnica solo se convierte en deuda técnica si el sistema evoluciona en una dirección que hace esa decisión limitante o problemática. Lo que hoy parece deuda, puede no serlo si el sistema no crece más; o lo que hoy no parece deuda, mañana puede ser un gran problema.

Cuadrante de la Deuda Técnica

Se puede consultar este concepto en el siguiente link de la página oficial de Martin Fowler. Él es un ingeniero de software británico, especializado en análisis y diseño orientado a objetos, UML, patrones de diseño, y metodologías de desarrollo ágil, incluyendo programación extrema (o tambien conocido como XP). También es conocido como uno de los firmantes del Manifiesto Ágil en 2001.

El cuadrante es una forma clara de entender qué tipo de deuda técnica se tiene y cómo se debería abordar. Permite entender ¿qué tan intencional es la deuda? y ¿cuánto riesgo se toma con la deuda? Se cuenta con 2 ejes (riesgo e intencionalidad) formando:

• Si es deliberada o inadvertida, es decir, si se sabía que se estaba generando o no.
• Si es prudente o imprudente, es decir, si se hizo conscientemente, con justificación, o de forma negligente.

• Deliberada + Prudente (ACEPTABLE) → No se tiene tiempo para diseñar. El equipo es consciente de que está tomando deuda porque tiene razones válidas. Posiblemente se corre poco riesgo y se hará mejor o se arreglará más adelante. Son casos donde la deuda no es mala sino que se hace con cuidado. Por ejemplo, se necesita lanzar rápido una aplicación para validar el mercado. El lanzamiento de esta versión es sin tests automáticos porque se necesita feedback rápido.
• Deliberada + Imprudente (PROBLEMÁTICO) → Se sabía que se estaba tomando deuda, pero al equipo no le importó, esta es una forma descuidada y poco profesional. Es la famosa deuda que se toma diciendo: “no me importa”, “no lo se”, “lo haré igual a pesar de las consecuencias”. A pesar de que el código es un desastre, no nos importa, le metemos igual.
• Inadvertida + Prudente (ACEPTABLE) → Se debe embarcar ahora y afrontar las consecuencias. Suele pasar que a veces hay situaciones que no se saben que son deudas. Luego, se entienden y se analiza que es algo razonable que surgió. Por ejemplo, al principio se creía que la arquitectura era la adecuada, pero se aprendió algo nuevo que muestra que se necesita cambiar.
• Inadvertida + Imprudente (PROBLEMÁTICO) → Ahora el equipo sabe cómo debió haberlo hecho. El equipo no sabía que esto era deuda porque no se entendía bien lo que se estaba haciendo posiblemente por ignorancia o falta de experiencia. “No teníamos idea de lo que hacíamos, y ahora nos damos cuenta de que hicimos las cosas mal”

Cuando uno toma decisiones de diseño tiene que ser consciente del tipo de deuda, “marcando una cancha” observando que se toma y cual es el efecto. Este modelo ayuda a no tratar toda la deuda técnica de la misma manera. Como se puede observar, la deuda se prioriza dependiendo del tipo y así evaluar si vale la pena pagar. A veces, entender que no toda la deuda técnica es mala, es una decisión estratégica correcta. El equipo debe reconocer cuándo los problemas vienen por descuido o ignorancia, y reforzar esas capacidades como equipo de trabajo y no buscar culpables.

Conclusión

Se debe educar a todos los miembros de los diferentes equipos de trabajos de los proyectos. Este concepto no es solo conocimiento que deben saber los desarrolladores o líderes técnicos. Por ejemplo para empezar a gestionarla puedo tener una etiqueta “tech debt” en el issue tracker, incluir TD como parte de las hojas de ruta, selección de tecnologías, y otras actividades de planificación del desarrollo.

La deuda técnica es una metáfora poderosa y una realidad inevitable en el desarrollo de software reflejada por las decisiones que se toman, comprometiendo la calidad interna. La deuda técnica es gestionable si es visible, trazable y priorizable pero no todas las que aparecen son malas o urgentes. Su gestión es parte del proceso de evolución del sistema, no solo una tarea puntual que se debe resolver. La clave no es eliminar toda deuda, sino gestionar estratégicamente para que no comprometa la evolución, mantenibilidad y calidad a largo plazo.

Para entender mejor el concepto de la deuda técnica (de ahora en más, DT) se puede citar una analogía con la deuda financiera usando conceptos de la toma de créditos, costos, intereses, pagos periódicos, etc. Por ejemplo, me encuentro en otro país de vacaciones y tengo una tarjeta de crédito. Usarla posiblemente es la forma más rápida de pagar algunas compras. Pero a cambio te comprometes a pagar esa deuda en cuotas con intereses, esto es lo que denominamos deuda financiera. Si no pagas a tiempo, la deuda crece y puede volverse difícil de manejar.

En el desarrollo de software, suele pasar algo similar cuando se toman decisiones rápidas como usar un atajo en el código, postergar la refactorización, no escribir pruebas, etc. ¿por qué haría esto? porque debo entregar más rápido y mostrar algo a los stakeholders. Pero se tiene que saber que en el futuro se tendrá que pagar ese “interés”, es decir más tiempo para corregir errores, menor calidad del producto, más dificultad para agregar nuevas funcionalidades, entre otras. El equipo tiene que ser consciente que a medida que va pasando el tiempo se debe ir mejorando el software y refactorizando porque ese interés tiene que ver con que a cualquiera le va a costar el doble.

¿Qué pasa si no pago mis deudas? Si no pagas la DT a tiempo, es decir, si no refactorizas, no mejoras el diseño, no limpias el código, con el tiempo el “interés” se acumula, o mejor dicho el software se vuelve más frágil, más caro de mantener, y cada cambio que se realice puede “romper todo”.

La adquisición de deuda puede ser buena para cumplir ciertos objetivos de negocio, salvo la deuda sumado a los intereses que no pueda luego pagarse. Se puede contar con 4 factores:

Principal o capital

• En deuda financiera, sería el dinero que se pidió prestado.
• En deuda técnica, es el trabajo técnico que decidió postergar cómo refactorizar, escribir pruebas, o documentar.

En definitiva, es la causa del problema. Por ejemplo se desarrolló un software que no está bien modularizado o no es difícil de testear.

Existe una diferencia entre una solución deseable y una solución basada en el compromiso que implica un trabajo necesario para “eliminar” la deuda donde en muchas ocasiones implica observar el route cost, es decir hacer un seguimiento desde cuando tomé la deuda.

Interés

• En deuda financiera es lo que pagas de más por usar ese dinero, se calcula sobre el principal.
• En deuda técnica es el costo adicional que acumulas por no resolver esa deuda puede ser el tiempo adicional para entender el código, errores, retrabajo. Por ejemplo, cada vez que tengo que hacer un despliegue al ser un software problemático siempre tengo errores que aparecen.

Existe un esfuerzo extra que se tiene en el sistema, debido a la solución basada en el compromiso y que se acumula a lo largo del tiempo ¿Donde veo este interés? lo más común es en el software. Todo lo que debo pagar en el tiempo por no haber hecho lo que debí haber hecho, es decir no haber elegido la solución buena sino haber elegido la más o menos. Las consecuencias son pérdida de productividad y calidad interna.

Tasa

• En deuda financiera, es el porcentaje anual que determina cuánto crece tu deuda.
• En deuda técnica, es qué tan rápido crece el costo, esto depende de la complejidad del sistema, de cuánta gente toca ese código, de cuánto se expande el proyecto.

Es como una “bola de nieve” cada cambio que se haga crece y se hace más lento porque hay un seguimiento de artefactos y procesos.

Tiempo

• En deuda financiera, es el período durante el cual debes pagar.
• En deuda técnica, es cuánto tiempo pasa sin que se resuelva esa deuda.

A medida que pasa el tiempo, es más difícil y caro. Se debe bajar la complejidad posiblemente re-escribiendo y re-testeando el software que implica tiempo.

Los pagos periódicos o el pago total pueden ser de interés y/o capital. Esto se traduce en reestructuración del sistema, baja de funcionalidad, etc. Es decir, puedo ir haciendo refactoring de a poco, es decir “ir parando la pelota” o hacer un refactoring entero para poder desplegar la solución.

¿La DT es costo o valor?

Mucha de la discusión de TD tiene que ver con su costo, es decir del esfuerzo de realizar desarrollo, mantenimiento, etc. Pero la TD o su pago también puede generar valor, si bien es más difícil de estimar que el costo. Se puede ver cómo son las features en el momento en que son entregados y del nivel de riesgo que se quiera tomar. Aquí es cuando entra la forma de comunicar cómo hacer refactoring.

• Costo — atributos de calidad de mantenibilidad, flexibilidad, evolvability, …
• Valor — atributos como performance, escalabilidad, seguridad, confiabilidad, etc.

¿Cuál es la forma de pagar DT? La DT se paga haciendo refactoring. Normalmente a la DT se la ve con “ojos” de costo, pero también la podría ver como valor. Para que alguien tome un refactoring, se tiene que mostrar que se ganó haciendo esto. Esta parte es la más difícil porque es algo interna, el PO en Scrum no lo ve como valor, no es algo que se ve externamente a través de pantallas. Sin embargo, a veces debo venderlo como valor o como algo que se gana. Y en este punto es clave darse cuenta de que si la DT que estoy evaluando es valor o no, porque si no gano nada, es mejor dejarlo como está.

La idea de la DT es que no se cambian features o no se agregan nuevas, sino que es un cambio organizacional interno. Las DT no son simplemente agarrar y tomarla sabiendo las consecuencias que pueden ocasionar a futuro.

Conclusión

Algunas consideraciones:

• Los eventos pueden o no suceder dependiendo del contexto o de la evolución deseada para el sistema. Esto significa que no toda deuda técnica necesariamente se convierte en un problema. Por ejemplo: si se tiene un código mal escrito pero que ya no se usa termina siendo una funcionalidad obsoleta que nunca genere impacto. Si el sistema evoluciona en una dirección distinta, como decidir reemplazar un módulo por completo, esa deuda se vuelve irrelevante. Así, no todo lo que hoy parece deuda es problemático mañana, porque depende del contexto y las decisiones futuras que se tengan.
• El interés (o su tasa) no es proporcional, ni se aplica a todos los artefactos. A diferencia de la deuda financiera, donde la tasa es fija y conocida, en la deuda técnica, el interés no crece de forma lineal ni constante. Hay partes del sistema o módulos críticos donde una pequeña deuda puede generar enormes problemas, mientras que en otras partes, puede no generar casi ningún costo. El impacto depende del tipo de deuda, dónde está y cuánto afecta la evolución del producto.
• La deuda puede extinguirse, sin pagarse. En software, a veces la deuda técnica desaparece sola. Se recalca “a veces”, no “siempre”. Por ejemplo: se elimina un módulo viejo, y toda la deuda asociada a ella desaparece. O bien, se decide cambiar de tecnología, lo viejo posiblemente ya no importa; los objetivos del producto cambiaron, así ciertas mejoras ya no son necesarias; el sistema murió o quedo obsoleto, la DT muere con el sistema. A diferencia de la deuda financiera, donde siempre hay que pagar o negociar, dónde vienen “2 señores con trajes” a tocarte el timbre. En software puede haber situaciones donde la deuda simplemente deja de existir, porque el contexto cambia.

Es un término que se escucha mucho en la comunidad del desarrollo de software, se refiere al costo implícito de tomar decisiones rápidas en el desarrollo para acelerar la entrega , a costa de la calidad y la mantenibilidad a largo plazo del código. Esto quiere decir que uno toma un atajo sabiendo que tendrá consecuencias más adelante. Muchos dicen: “Estas son las deudas que después pagaremos más adelante”.

Se puede entenderlo como un balance entre velocidad y esfuerzo en el desarrollo cuando se quiere entregar cierta funcionalidad y al mismo tiempo se quiere calidad de software. O mejor dicho de otra manera es entregar algo rápido sin hacer mucho esfuerzo. En esta parte es cuando uno no piensa de forma óptima ni de forma genérica mirando al “todo”.

La Deuda Técnica (de ahora en más, DT) no necesariamente está relacionada con bugs en el software. Esto quiere decir que no todo lo que se hace mal o genera error es DT. Es más, muchas son realizadas de forma consciente y capaz no están hechas de la mejor manera. Hay muchos que se justifican diciendo que todos los sistemas tienen deuda técnica, “¿Porque el nuestro no tendría?” Este no es un buen argumento para justificar la DT.

Este concepto es atribuido por W. Cunningham en 1992 para comunicar el balance entre velocidad y re-trabajo en la entrega de software que funciona y con calidad. Este concepto está relacionado a otros como mantenimiento, evolución de software, obsolescencia, software aging, decay, re-ingeniería, etc.

Existe una definicion de DT más amplia: “In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities primarily, but not only, maintainability and evolvability.” — Krutchen et al., 2019

Aquí te dejo el link del libro de Krutchen que habla de DT: https://ptgmedia.pearsoncmg.com/images/9780135645932/samplepages/9780135645932_Sample.pdf

Decisiones de corto plazo VS largo plazo

Se tiene en cuenta visiones a corto, mediano y largo plazo donde ciertos “futuros” planificados pueden no ocurrir. Uno planifica capaz en sprints con objetivos posiblemente optimistas haciendo “futuros probables” sabiendo que los futuros más lejanos son los posiblemente no se cumplan. Por ejemplo, uno puede pensar en el largo plazo, como aplicar un patrón de diseño pensando que cambiará, un factory o un visitor, cubriendome en lo más posible, pero después no pasaron. Prácticamente, “El equipo trabajó por gusto”. También puede pasar al revés, me concentré en el corto plazo, sabiendo lo que puede pasar.

Puede ser que se tenga una 1° versión de un sistema que está evolucionando. Para la próxima versión, vienen requerimientos, y así se tiene otra versión. En cada evolución del sistema tengo que tomar decisiones, donde “abro el paragua para cubrirme de la lluvia”. Entonces, se puede tener:

• Dolor a corto plazo y placer a largo plazo
• Placer a corto plazo y dolor a largo plazo

Cuando uno acumula DT se genera cierta fricción entre el diseño y desarrollo de software porque al proyecto le cuesta generar más funcionalidades. Es como tener una mochila pesada llena de piedras, nos cuesta ir caminando de forma rápida.

Algunas características de la DT son:

• La DT es contingente ¿Que quiere decir esto? Esto significa que se puede manifestar o no, no es 100% seguro que se manifieste. Cuando uno “patea” algo a futuro no es algo que siempre pasa. Presenta una incertidumbre (o probabilidades) y horizonte de tiempo considerado donde tomar o tener deuda, en principio, no es “ni bueno ni malo”.
• La DT son decisiones subóptimas, conscientes o inconscientes. Como se observa, las deudas pueden tomarse de forma inconsciente pero estas se trata de evitar.
• La DT puede verse como un tipo de planificación estratégica.
• La DT hace referencia a la calidad interna que tiene el software es decir aquellas que el usuario no ve a nivel interfaz del usuario (UI). El problema es que “El sistema funciona igual, solo que adentro tiene algunos problemas”. Si es externa es un bug, defecto funcional o algún requerimiento que no se contemple, no es deuda técnica.

Tipos de deuda técnica

La DT se manifiesta en distintos artefactos como código, diseño, tests, documentación, despliegue, etc. Es así que existe una clasificación de DT dependiendo de donde puede presentarse.

En definitiva hay distintos tipos de DT o “distintos sabores”, todos son malos, o todos nos pueden llegar a perjudicar pero no es que son netamente de código o de diseño.

Entonces, el código es la principal fuente importante (como artefacto), pero no es el único.

Casos de DT

Existe un problema “viejo”, del cuál se ha tomado mayor conciencia en los últimos años que son las técnicas ingenieriles para su gestión que abarca distintos tipos de sistemas , incluso aquellos con AI/ML.

Hay un caso clásico y conocido de DT, relacionado con la Reglas If-then-else, en donde una compañía en Canadá desarrolló un software para sus clientes locales. El inglés fue usado como primer idioma, moneda, etc. Luego, se extendió al resto de Canadá y debió adaptar el software al Francés, es decir tambien el idioma, moneda, etc. La adaptación fue realizada en 1 semana con una variable global. Un mes después, el área comercial vendió el software como multi-lenguaje en Japón donde la adaptación al Japonés se hizo en 1 semana.

La configurabilidad del sistema se hizo un spaghetti por tener varios idiomas. Se debió pensar en alguna solución general para varios idiomas que tengan tantos if, then, else. El spaghetti está dentro del sistema, es algo que no se observa, no es un bug porque sería distinto el caso de que seleccione japonés y me aparezca el sistema en francés.

Los sistemas desarrollados como monolitos presentan este tipo de situaciones. Pero ¿Puedo cambiar a microservicios? y ¿Cuándo? Esa sería una buena pregunta para plantearse, va a depender mucho del contexto. Este tipo de situaciones pasa casi todo el tiempo, porque plantea un retrabajo. El cliente suele pensar que es algo fácil y urgente, diciendo: ¿Por qué no puedes pasar al japonés, si antes pudiste pasar a francés?

El diagnóstico de la DT

Cuando uno quiere hacer un diagnóstico de un sistema que ya existe, y tiene un cierto desarrollo con tems de DT, hacer esto me va a permitir definir causas, consecuencias y síntomas sirve para entender cómo se originó, qué impacto tiene y cómo se manifiesta la deuda.

• Causas: son los factores que originaron la deuda. Necesito las causas porque si tengo problemas tengo que atacar por aquí, si es que puedo atacar. Por ejemplo: apuro por una entrega, falta de conocimiento, cambios de requerimientos, malas prácticas, falta de revisiones de código.
• Consecuencias: son los efectos negativos que trae la deuda si no se aborda. En este punto es clave priorizar para ver si es grave. Por ejemplo: aumento de costos de mantenimiento, la UX se degrada, el timeout es muy alto, menor velocidad de entrega, frustración del equipo, riesgos de fallos en producción.
• Síntomas: son las señales que te muestran que la DT está ahí. Por ejemplo: código difícil de entender, muchas pruebas fallando, tiempos largos para hacer cambios, bugs recurrentes, concurrencias de módulos.

Si se vuelve al ejemplo del sistema multi-lenguaje:

• Causa: Los desarrolladores completaron la 1° versión a tiempo para la
  demo, pero bajo presión de calendario.
• TD. dispersión de lógica para gestión de idiomas en distintos módulos. No se consideró internacionalización.
• Consecuencias: el código es frágil y susceptible a errores (en idiomas anteriores) al querer agregar un nuevo idioma.
• Síntoma: demoras y complicaciones para agregar soporte para un tercer idioma

Otro caso de DT es el famoso caso de la fusión de 2 compañías financieras donde fue necesario integrar sus respectivos sistemas de software. Dado que los sistemas tenían incompatibilidades, se decidió crear un “nuevo sistema” desde cero, con nuevas tecnologías. En poco tiempo, se construyeron 2 sistemas que remplazaron exactamente a los anteriores, a fin de proveer demos a los stakeholders. Las demos tuvieron buena performance

Varios meses después, ambos sistemas seguían en “proceso de integración” pero con problemas serios de interoperabilidad y escalabilidad. Las miles de líneas de código estaban desarrolladas sin una arquitectura planificada. Muchas cuestiones de DT suelen enmarcarse porque no tienen un diseño claro o planificado. Sin embargo, aun teniendo una buena arquitectura se puede tener DT.

Conclusión

En DT parece un problema conocido como “Hitting the wall” donde en un momento no vas ni para atrás ni para adelante. Existe una dificultad de cambiar cosas, de testear, de evolucionar, el famoso “apretas un botón y se rompe todo”. La idea es tratar de frenar antes y “tomar al toro por las astas” porque cuando uno tiene más “cancha” ya empieza a olfatear cuando tiene este tipo de problemas.

The Wall of Technical Debt

Algunas conclusiones de los casos de sistemas que se menciono:

• Demasiada fricción para seguir desarrollando nuevos features y atender atributos de calidad del sistema.
• Es común que el diseño (original) se degrade
• La arquitectura emerge sin una planificación adecuada
• La DT suele existir en situación recurrente de ciertos proyectos o contextos de desarrollo ágil.

Si uno puede olfatear estas cosas, esto implica que puedo identificarlas y existen métricas. Puedo decir ¿De cuánto es mi deuda? Muchas veces pagar esa deuda no depende del proyecto sino posiblemente de un manager donde los desarrolladores deben convencerlos para pagarla, es decir tiene que existir un tiempo para revisar, corregir, replantear, retrabajar y refactorizar porque sino es difícil pagarla.

La idea de tener métricas es observar si la DT va creciendo, disminuyendo o que sucede. En la práctica es difícil tratar de controlar o monitorearla.

En el desarrollo de aplicaciones móviles ademas de React Native, pueden estar entre los reconocidos: Flutter y Cordova. Todos son frameworks para desarrollar aplicaciones móviles multiplataforma, pero tienen enfoques muy distintos.

React Native es una herramienta poderosa que permite a los desarrolladores de software crear aplicaciones móviles multiplataforma, es decir que funcionen tanto en iOS como en Android, utilizando JavaScript. React native es una librería de React, siendo esta última también una librería de JavaScript.

¿Por qué elegir React Native?

• Eficiencia de código: se escribe el código una vez y se ejecuta en dos plataformas, reduciendo los costos de desarrollo.
• Comunidad activa: cuenta con un extenso soporte gracias a una gran comunidad de desarrolladores que aporta soluciones y mejoras.
• Experiencia de usuario: ofrece un rendimiento similar a las aplicaciones nativas, mejorando la experiencia del usuario en iOS y Android.

Para escribir código es necesario tener instalado Visual Studio Code.

Visual Studio Code - The open source AI code editor | Your home for multi-agent development

Esta herramienta es una de la más populares entre los desarrolladores debido a su versatilidad y soporte para extensiones. Tambien, antes de comenzar es clave revisar la documentación oficial de React Native: https://reactnative.dev/

Un dato interesante es que Microsoft desarrollo una extensión de React Native para poder crear aplicaciones nativas para Windows y macOS.

React Native for Windows + macOS · Build native Windows & macOS apps with Javascript and React

¿Qué necesitas antes de empezar a tener tu aplicación React Native?

Antes que nada, se actualiza el índice de paquetes:

sudo apt update

Ahora bien, se necesita Node.js que nos permite crear servidores, aplicaciones web, herramientas de línea de comandos y scripts. Es un entorno de ejecución de JavaScript gratuito, de código abierto y multiplataforma.

Node.js - Run JavaScript Everywhere

En mi caso, estoy usando Ubuntu 22.04.5 LTS de 64-bit que reconoce https://nodejs.org/en/download. Se muestra:

# Download and install nvm:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.2/install.sh | bash

# in lieu of restarting the shell
\. "$HOME/.nvm/nvm.sh"

# Download and install Node.js:
nvm install 22

# Verify the Node.js version:
node -v # Should print "v22.14.0".
nvm current # Should print "v22.14.0".

# Verify npm version:
npm -v # Should print "10.9.2".

Las pruebas en el desarrollo de aplicaciones es interesante e importante, para ello, realice pruebas con un emulador para aplicaciones Android y en el caso de aplicaciones iOS realice la prueba con dispositivo real ya que tengo un Iphone 13 Pro Max. Contar con estos recursos es crucial para aquellos que trabajan con aplicaciones móviles en diferentes sistemas operativos.

Primero, instale Android Studio del sitio oficial:

Cómo descargar Android Studio y App Tools - Android Developers

Expo es un framework de React Native que ofrece funciones como enrutamiento basado en archivos, bibliotecas universales y la capacidad de escribir complementos que modifican el código nativo sin tener que administrar archivos nativos. Ahora bien, la instalación de Expo CLI ha cambiado porque no es necesario instalarlo de forma global en nuestro sistema (antes era así) sino que recomiendan instalarlo por proyecto. De esta forma se evitan conflictos entre diferentes proyectos a la hora de actualizar.

Set up your environment

En mi instalación de Android Studio me faltaban las tools para ello debí ejecutar:

sudo apt-get install android-tools-adb

Además agregé las siguientes lineas al archivo bashrc para configurar la variable de entorno ANDROID_HOME:

nano ~/.bashrc

Al final del archivo se agrega y guarde:

export ANDROID_SDK_ROOT=$HOME/Android/Sdk

export ANDROID_HOME=$HOME/Android/Sdk

export PATH=$PATH:$ANDROID_HOME/emulator

export PATH=$PATH:$ANDROID_HOME/platform-tools

Abrí mi proyecto en Android Studio:

Se puede observar que en el lado derecho se puede ejecutar un emulador de dispositivo. Puedo elegir entre varios dispositivos android, la idea es buscar uno estándar:

Una vez realizada todas estas configuraciones de Node.js y del emulador.

Primera opción: para crear un proyecto minimalista es decir con lo justo para arrancar se debe ejecutar el siguiente comando en la terminal:

npx create-expo-app@latest --template blank

Segunda opción: sin embargo se puede crear una versión actualizada donde se generan más carpetas por default y además se instala TypeScript.

npx create-expo-app@latest

Una vez ejecutado este último comando, se solicita el nombre del proyecto:

Escribo el nombre del proyecto y observamos que se ejecuta npm install para instalar todas las dependencias.

En mi caso al final termino con “found 0 vulnerabilities”

✅ Your project is ready!

To run your project, navigate to the directory and run one of the following npm commands.

- cd My_First_App_React_Native
- npm run android
- npm run ios # you need to use macOS to build the iOS project — use the Expo app if you need to do iOS development without a Mac
- npm run web

La estructura de carpetas es bastante clara:

• app: suele contener las pantallas principales o vistas de la aplicación como Home.tsx, Login.tsx, Profile.tsx). A veces incluye subcarpetas como navigation/, screens/ o routes/.
• assets: contiene todos los archivos estáticos que la aplicación puede usar como imágenes, fuentes, íconos, videos, sonidos, etc.
• components: posee todos los componentes reutilizables de UI, es decir los que se usan en varios lados. Ej: Button.tsx , Card.tsx yHeader.tsx
• constants: contiene las variables que no cambian: colores, rutas, estilos globales, tamaños, etc.
• hooks: comunmente son los Hooks personalizados de React que ayudan a extraer lógica reutilizable de tus componentes.
• node_modules: son todas las dependencias que instalás con npm o yarn.
• scripts: son los scripts personalizados que podés correr con npm run. Por ejemplo: para generar assets, limpiar el cache, o deployar.
• app.json: es la configuración general de la app donde se describe nombre, ícono, tema, orientación, etc. Expo lo usa para compilar tu app para Android, iOS y Web.
• package-lock.json: este archivo es generado automáticamente por npm y asegura que todos los integrantes que trabajen en el proyecto tengan exactamente las mismas versiones de librerías.
• package.json: este archivo es clave porque aquí se definen dependencias, scripts, nombre del proyecto, etc. Cuando se ejecutanpm install, este archivo guía qué se debe instalar.

Ahora bien, se ejecuta:

npm run android

Una vez ejecutado el comando, como no tenía instalado Expo Go en el emulador, automáticamente se instala y se abre la aplicación.

Para pruebas reales, primero se debe asegurar de estar conectado en la misma red einstalar Expo Go en el dispositivo (esto es si quieres hacer pruebas con tu celular, ya sea Android o iOS) y escanear con la cámara el QR que se genera:

Si modificamos el código de app.js

Se puede observar el cambio reflejado:

Existe un problema de lógica pesada, en donde los componentes son más complejos o pesados generando demora de algunos segundos como consultas a API, condicionales, etc. Al tener que renderizar nuestro componente, toda la logica, incluso la complicada tiene que volver a renderizarse y por tanto repetir esa logica pesada.

Podemos consultar:

useEffect - React

Una solución son los efectos que son una herramienta que nos permite encapsular una lógica pesada o demorada y protegerlos para que únicamente se ejecuten cuando lo necesitamos, sin retrasar procesos. Para utilizar los efectos en React, empleamos el hook useEffect.

Al iniciar la página por primera vez se ejecutan todas las funciones, pero al cambiar el estado no siempre se va a volver a correr el código dentro del useEffect, sino que este se volverá a correr únicamente cuando cambie un estado específico que se le indique. Asi se ejecuta únicamente cuando es estrictamente necesario, evitando que se repitan en cada renderización del componente. De esta manera, mejora la eficiencia y rendimiento de nuestras aplicaciones. Por ejemplo:

import React, { useEffect, useState } from 'react';

function Contador() {
  const [contador, setContador] = useState(0);

  useEffect(() => {
    document.title = `Contador: ${contador}`;
  }, [contador]); // solo se ejecuta cuando cambia "contador"

  return (
    <div>
      <p>Has hecho clic {contador} veces</p>
      <button onClick={() => setContador(contador + 1)}>
        Aumentar
      </button>
    </div>
  );
}

Se cuenta con:

• Primer argumento: Recibe una función que encapsula la lógica que queremos ejecutar o una función que es la lógica pesada.
• Segundo argumento: Es un array de dependencias que determina cuándo se debe ejecutar el efecto. Si es un array vacío y actualizamos cualquier estado, no va a volver a correr ese código al renderizar. Si por otro lado el Array contiene un estado o varios estados, entonces la lógica se volverá a correr únicamente cuando el render sea ocasionado por cambios en esos estados que se especifico dentro del array. Es importante recalcar que si no hay ninguna variable en la lista de dependencias, el efecto se ejecutará en cada renderización.

Entonces lo uso cuando quiero realizar:

• Llamadas a APIs
• Escuchar eventos del navegador
• Temporizadores

Al encapsular una parte de nuestra lógica dentro de useEffect, el orden de ejecución cambia. La lógica del efecto se ejecuta después del resto del código en el componente.

console.log('log1');
useEffect(() => {
  console.log('log2');
}, []);
console.log('log3');

Los logs se imprimen en este orden:

1. log1
2. log3
3. log2

Esto ocurre porque el efecto se ejecuta después del render inicial. Al final una vez que se ha cargado por primera vez nuestro componente y llame un re-renderizado para que cambie nuestro mensaje temporal de “cargando” por la información necesaria. El array de dependencias dentro de useEffect decide si el efecto debe ejecutarse después de cada render o sólo bajo ciertas condiciones. Si se proporciona un array vacío, el efecto se ejecuta únicamente una vez, al montar el componente:

useEffect(() => {
  console.log("Efecto con array vacío, ejecutado una vez.");
}, []);

Si incluimos dependencias, el efecto se ejecutará cada vez que las dependencias cambien:

useEffect(() => {
  console.log("Efecto ejecutado cada vez que 'estado' cambia.");
}, [estado]);

Aquí, el efecto se desencadena siempre que el valor de estado se modifica.

Implementar useEffect no solo mejora la eficiencia de nuestra aplicación sino también la experiencia del usuario. Muchas veces, sabemos que se tardaran unos segundos en obtener los datos para luego montarlos en un componente para ser renderizados. La aplicación responde más ágilmente, evitando esperas innecesarias o sobrecarga de procesos. Introduce mejoras simples, pero significativas en el desempeño y usabilidad. Además, asegúrate de mantener una buena práctica en la gestión de estados para ofrecer a los usuarios interacciones fluidas y efectivas.

Conclusión

Los efectos son una herramienta o un react hook que permiten ejecutar cierta parte del código de nuestros componentes para que no se ejecuten cada vez que hacemos render de nuestro componente, sino, dependiendo de ciertas condiciones.

• Se puede enviar un array vacío para indicarle a nuestro efecto que se ejecuta solo una vez, cuando recién hacemos el primer render de nuestro componente.
• Se puede enviar un array con distintos elementos para decirle a nuestro efecto que no solo ejecute el efecto en el primer render, sino también cuando haya cambios en esos elementos del array.
• Si no se envia ningún array como segundo argumento de nuestro efecto, esta función se ejecutará cada vez que nuestro componente haga render (es decir, cada vez que haya cambios en cualquiera de nuestros estados).

El desarrollo de aplicaciones React no termina con la interactividad básica. A medida que una aplicación o software crece, es necesario adaptarse a nuevas prácticas, herramientas y mecanismos de organización que faciliten el desarrollo sostenible y escalable.

En algunas ocasiones, los eventos se envían como props a los componentes, permitiendo que sean manejados de manera centralizada en el componente padre. Para mantener una comunicación fluida entre componentes y estados, se utilizan las props para enviar datos entre ellos.

Sin embargo, este enfoque puede volverse complicado si el número de props es elevado, generando un problema conocido como “prop drilling”. Entonces, prop drilling (o “perforar props”) ocurre cuando se quiere pasar datos a través de varios componentes intermedios que no los necesitan directamente, es decir solo para que lleguen a un componente más profundo que sí los usa. Entonces:

• Los componentes intermedios se ensucian con props que no les importan
• El código es difícil de mantener y escalar
• Aumenta la dependencia entre componentes

Por ejemplo, tenemos este problema:

function App() {
  const usuario = "Emanuel";
  return <Padre usuario={usuario} />;
}

function Padre({ usuario }) {
  return <Hijo usuario={usuario} />;
}

function Hijo({ usuario }) {
  return <Nieto usuario={usuario} />;
}

function Nieto({ usuario }) {
  return <p>Hola, {usuario}!</p>;
}

Aqui todos los componentes deben recibir usuario aunque solo Nieto lo necesita. Se tiene un paso del desarrollo que ocurre cuando necesitamos obtener datos que están en varias capas en el árbol de componentes React, como un “túnel” o “perforación” de props a través de múltiples niveles de componentes. Esto se ve siempre cuando pasamos props entre hijos, luego ese a otros hijos y así sucesivamente. Este fenómeno ocurre cuando se pasa una propiedad (prop) a través de múltiples niveles de componentes, aunque los componentes intermedios no necesiten esa propiedad en particular.

La idea es pasar información de manera más directa entre los componentes.

El prop drilling puede ser una desventaja, como hacer que el código sea más complejo y difícil de mantener, ya que las props deben pasar por varios componentes intermedios, dificultando los cambios en la estructura de los componentes. La idea es mejorar la eficiencia y la escalabilidad del código, ya que el mismo puede ser menos legible y más propenso a errores. Sin embargo, el prop drilling puede ser una solución adecuada en situaciones simples y pequeñas, y no siempre es problemático.

React Context

¿Cuál es la Solución? React Context es una herramienta que permite crear estados globales para evitar el problema de prop driling en nuestras app. Podemos consultar:

Context - React

Entonces, context es un elemento que podemos crear para establecer una comunicación directa entre un componente en un nivel muy alto y uno en un nivel mucho más bajo. De esta manera, podemos acceder a los valores de forma directa. Del ejemplo anterior:

// 1. Crear el contexto
const UsuarioContext = React.createContext();

// 2. Envolver tu árbol de componentes
function App() {
  return (
    <UsuarioContext.Provider value="Emanuel">
      <Padre />
    </UsuarioContext.Provider>
  );
}

// 3. Usar el contexto donde se necesita
function Nieto() {
  const usuario = React.useContext(UsuarioContext);
  return <p>Hola, {usuario}!</p>;
}

Muy similar a una nube donde se puede almacenar funcionalidades, estados, datos, etc. que necesitan ser compartidos entre diferentes componentes de una aplicación. Una analogía, es como una biblioteca compartida, donde quiero compartir recursos como libros, revistas, etc. a compañeros del trabajo. En lugar de pasar los libros de mano en mano entre los compañeros de trabajo, se puede poner todo en una biblioteca compartida en el edificio del trabajo o en englobarlos en un Google Drive, lo que hace que sea más fácil para todos acceder a los recursos que necesitan.

De manera similar, se guardan datos que necesitan ser compartidos entre diferentes componentes de tu aplicación en una “biblioteca compartida”, lo que facilita el acceso a estos datos desde cualquier lugar de tu aplicación sin tener que pasarlos manualmente a través de múltiples niveles de componentes.

useContext

Es altamente recomendable utilizar el hook useContext() al comenzar un proyecto desde cero, ya que es una forma cómoda e incluso estetica. Asi, me permite acceder a un contexto (Context) directamente dentro de un componente. Sin embargo otra forma es usar <TodoContext.Consumer> que es la forma más antigua de trabajar contextos en versiones anteriores de React.

En caso de que no se quiera cambiar los nombres de las propiedades, se puede redefinirlos en el objeto. Algo útil si tenemos que cambiar muchas propiedades en muchos sitios.

1. Creamos el contexto

import React, { createContext, useContext } from 'react';

// Creamos el contexto
const UsuarioContext = createContext();

2. Proveemos el contexto

function App() {
  const usuario = "Emanuel";

  return (
    <UsuarioContext.Provider value={usuario}>
      <ComponentePadre />
    </UsuarioContext.Provider>
  );
}

Provider es lo que "envuelve" los componentes que necesitan acceso al dato.

3. Usamos el contexto

function ComponentePadre() {
  return <ComponenteHijo />;
}

function ComponenteHijo() {
  return <ComponenteNieto />;
}

function ComponenteNieto() {
  const usuario = useContext(UsuarioContext);

  return <p>Hola, {usuario}!</p>;
}

Los Custom Hooks son una forma de reutilizar lógica de componentes en React usando funciones. Como la lógica de la aplicación es compleja, la idea es abstraer esa parte para que quede mucho más limpia y asi poder reutilizar.

Los Hooks son funciones que puedes llamar dentro de componentes funcionales para agregar y manipular características de React, como el estado, el ciclo de vida y los efectos secundarios. Algunos links utiles:

Introducing Hooks - React

Los Hooks más comunes son useState, useEffect y useContext, pero también puedes crear tus propios hooks personalizados, por ejemplo para obtener datos, para mantener un seguimiento de si un usuario está conectado, para conectarse a una sala de chat, para manejar tareas específicas, para una autenticación, para manejar el estado de carga y respuesta, para el manejo de formularios, la gestión de datos, etc. Hay que tener en cuenta:

• Empieza con la palabra use por convención.
• Hay otros hooks como useState, useEffect, useContext, etc.
• Con la abstracción del Hooks nos facilita la lectura del código.
• El código es más modular, legible y reutilizable.
• Permite extraer y reutilizar lógica entre componentes de forma limpia y organizada. Se comparte la lógica y se tiene el código del componente mucho más limpio.
• ¿Cuándo vale la pena implementarlo? cuando sea necesario abstraer una lógica.

Los Hooks son más restrictivos que las funciones regulares. Solo puedes llamar a los Hooks en el primer nivel de tus componentes (u otros Hooks). Esta herramienta te permiten agregar y manejar el estado en componentes funcionales, lo cual antes solo era posible en componentes de clase utilizando el estado del constructor y los métodos del ciclo de vida. Con los Hooks, puedes usar el estado en componentes funcionales sin necesidad de convertirlos en componentes de clase.

• useState: permite agregar y actualizar el estado en componentes funcionales. Recibe un valor inicial y devuelve un array con dos elementos: el estado actual y una función para actualizarlo.
• useEffect: permite ejecutar efectos secundarios en componentes funcionales. Puedes usarlo para realizar tareas como hacer llamadas a API, suscribirte a eventos o limpiar recursos. Se ejecuta después de que el componente se haya renderizado.
• useContext: permite acceder al contexto de React en componentes funcionales. Te da acceso al valor actual del contexto definido en un componente superior utilizando el componente Context.Provider.
• useRef: permite mantener una referencia mutable en componentes funcionales. Puede ser útil para acceder directamente a un elemento del DOM o para almacenar valores que persisten a través de re-renderizados.

Los Hooks solo pueden ser llamados en el nivel superior de un componente de función y no dentro de bucles, condiciones o funciones anidadas. Por ejemplo:

import { useState } from "react";

function useContador(valorInicial = 0) {
  const [contador, setContador] = useState(valorInicial);

  const incrementar = () => setContador(contador + 1);
  const decrementar = () => setContador(contador - 1);
  const resetear = () => setContador(valorInicial);

  return { contador, incrementar, decrementar, resetear };
}

Se puede usar en un componente:

function Contador() {
  const { contador, incrementar, decrementar, resetear } = useContador(5);

  return (
    <div>
      <h2>Contador: {contador}</h2>
      <button onClick={incrementar}>+</button>
      <button onClick={decrementar}>-</button>
      <button onClick={resetear}>Reset</button>
    </div>
  );
}

Conclusión

Algunas consideraciones sobre el uso de Custom Hooks:

• Decidir cuándo implementar Custom Hooks depende del criterio y la experiencia del desarrollador. No hay una regla estricta, pero en general se recomienda crear un custom hook cuando: se tiene lógica de estado o efectos que se repite en varios componentes, separar la lógica de negocio del componente de UI, la lógica empieza a crecer y hace que el componente principal se vuelva difícil de leer
• La abstracción de lógica compleja en Custom Hooks puede facilitar el mantenimiento y la legibilidad del código. Con custom hooks se permite ocultar los detalles y mostrar solo lo que importa en el componente.
• La práctica y la experimentación son esenciales para desarrollar un buen criterio sobre cuándo y cómo usar Custom Hooks. Algunos errores comunes al principio pueden ser crear hooks demasiado genéricos (que no aportan valor real), abstraer cosas que solo se usan una vez y crear hooks que hacen demasiadas cosas distintas.

Introducción

React JS trabaja con estados que son esenciales para controlar y almacenar información que cambia conforme a las interacciones de los usuarios. Es importante en aplicaciones interactivas donde el estado debe actualizarse para reflejar cambios en la Interfaz del Usuario (UI), como entradas de búsqueda o clics en botones. Se puede tener:

• Estado local: es la información almacenada a nivel de componente, accesible solo dentro del componente donde se define.
• Estado global: es la información compartida entre múltiples componentes de la aplicación.

Utilizar estados no solo optimiza la forma en que se gestionan los datos dinámicos, sino que también garantiza que los componentes se rendericen correctamente cada vez que los datos cambian. Se puede consultar:

• Estado del componente - React
• ¿Qué es el estado en React?

Entonces, un estado es una herramienta que permite manejar y almacenar información susceptible a cambios por las interacciones de los usuarios.

useState

El hook useState es una herramienta para manejar estados locales. Con useState se puede crear y actualizar estados de nuestra aplicación.

Donde:

• state es la variable que contiene el estado actual. Es una buena práctica utilizar el prefijo “is” para variables de estado booleanas, ya que hace que el código sea más legible y autodocumentado. En este caso puede serisState que indica claramente que se trabaja con un estado que puede ser verdadero o falso.
• setState es la función que nos permite actualizar ese estado
• false es el valor con el que comienza nuestro estado

Algunas características:

• El estado es inmutable, es decir que no se puede actualizar directamente. Se necesita una función actualizadora que garantice el manejo correcto de su actualización (setSearchValue).
• Al crear un estado, la representación es un array, donde el primer elemento es el valor del estado y el segundo es el actualizador del estado ([searchValue, setSearchValue]).
• Se puede tener un valor inicial como un string vacío, null, o cualquier tipo de dato con el cual se espera trabajar inicialmente (useState(‘ ’)).

import React, { useState } from 'react';

// Creación de un estado para un input de búsqueda
const [searchValue, setSearchValue] = useState('');

// Conexión del estado con el valor de un input
<input value={searchValue} onChange={(event) => setSearchValue(event.target.value)} />

Cada vez que un estado cambia, React automáticamente vuelve a renderizar el componente que lo contiene. De esta forma, la interfaz de usuario está siempre actualizada con la información más reciente. Esto es posible gracias a que cada tiempo que se actualiza el estado, React dispara un re-render, actualizando solamente las partes del DOM que lo requieren. React mejora la eficiencia mediante el uso de un virtual DOM que actúa como una representación en memoria del DOM real:

• La forma de actualización: es decir la optimización de los cambios que se aplican primero al virtual DOM. Solo cuando se detectan diferencias relevantes en este, se actualizan las partes específicas del DOM real. Nunca se debe modificar directamente la variable de estado (por ejemplo count), sino utilizar la función “setter” (por ejemplo setCount) proporcionada por el hook useState.
• El forma de renderización: es decir el renderizado eficiente, mejorando el desempeño y la velocidad de respuesta de la interfaz. Cada vez que el estado cambia, React vuelve a renderizar el componente automáticamente.

La reacción a cambios de estado mediante el virtual DOM es clave para aplicaciones modernas y responsives, asegurando recursos computacionales optimizados y una experiencia de usuario fluida. Cada estado y cada render optimizado mediante esta técnica contribuyen al objetivo de React que es construir UI rápidas y eficientes.

Comunicación de estados entre componentes

La comunicación de estados entre componentes es crucial para interactuar los componentes padres con sus componentes hijos para crear aplicaciones dinámicas y robustas. Por ejemplo, se puede usar el método filter en los arrays para seleccionar solo los to-dos que contengan el valor del estado searchValue. Así se elabora el nuevo estado derivado:

const searchedTodos = todos.filter(todo => 
  todo.text.toLowerCase().includes(searchValue.toLowerCase())
);

La diferencia entre los métodos toLowerCase() y toLocaleLowerCase() en JavaScript está relacionada con la forma en que se procesan los caracteres en mayúsculas y acentuados en diferentes idiomas. toLowerCase() convierte una cadena de texto en minúsculas, utilizando las reglas de conversión que se aplican a los caracteres ASCII (caracteres en inglés y otros idiomas europeos que no tienen acentos)

De esta manera, convierte una cadena de texto en minúsculas utilizando las reglas de conversión específicas del idioma y la ubicación (localización) en la que se está ejecutando el código. Esto significa que, en función de la localización, algunos caracteres con acentos o diacríticos (como la letra “á” en español) pueden ser convertidos a su equivalente en minúsculas, mientras que otros caracteres pueden permanecer sin cambios. Asi, nos aseguramos de que el filtrado no sea sensible a mayúsculas y minúsculas. En lugar de renderizar directamente el array de todos por defecto, ahora debemos asegurar que la lista muestre solo los resultados filtrados que coincidan con el valor de búsqueda del usuario:

return (
  <TodoList todos={searchedTodos} />
);

Por ejemplo si tengo una aplicacion de completar tareas (to-dos), para permitir que las tareas se completen, es esencial saber en qué momento actualizar el estado de nuestra lista de tareas. Aquí vamos a necesitar un poco de ayuda de nuestro buen amigo setTodos, la función del estado que mantiene viva la lista.

1. Identificar el Evento: Debemos establecer la actualización del estado (setTodos) cuando el usuario interactúa con el elemento específico que indicará que la tarea está completa.
2. Implementar onClick en el ítem: En cada todoItem, dentro del archivo todoItem.js, podemos añadir la interacción onClick para que al hacer clic en el icono de completar (una “V” temporal), se dispare la función de actualización.
3. Definir una nueva función: En vez de pasar directamente setTodos, podemos encapsular la lógica de completado dentro de una función especial que se puede llamar completeTodo.

const completeTodo = (text) => {
  const newTodos = [...todos];
  const todoIndex = newTodos.findIndex(todo => todo.text === text);
  newTodos[todoIndex].completed = true;
  setTodos(newTodos);
};

Una vez definida la constante como parámetro enviamos text por ser nuestra clave en el caso de los to-dos, luego se usa la expresión extendida de JS con … es decir traeremos todo el array to-dos para crear un nuevo array. En la siguiente linea tenemos un filtro por el Index que se define para obtener el todo que se busca.

En el nuevo elemento encontrado lo definimos con el estado completed como true y definimos el array original con el nuevo, para finalmente enviamos un console.log para verificar que el estado se modifico de acuerdo a nuestra logica.

4. Asignar la función al evento: Dentro de los props del todoItem, encierra completeTodo dentro de una arrow function para retrasar su ejecución hasta que ocurra el evento:

<TodoList>
  {searchedTodos.map(todo => (
    <TodoItem
      key={todo.text}
      text={todo.text}
      completed={todo.completed}
      onComplete={() => completeTodo(todo.text)}
      onDelete={() => deleteTodo(todo.text)}
    />
  ))}
</TodoList>

const deleteTodo = (text) => {
  const newTodos = [...todos];
  const todoIndex = newTodos.findIndex(
    (todo) => todo.text === text
  );
  newTodos.splice(todoIndex, 1)
  setTodos(newTodos);
  console.log('Hola llego aquí');
}

Tambien, podemos agregar delete todo porque eliminar una tarea es tan esencial como completarla. De esta manera este enfoque asegura que la función se ejecute sólo en respuesta a eventos reales, evitando errores excesivos en React.

Conclusión

Los desarrolladores deben dominar el manejo de estados, ya que es esencial para crear aplicaciones React de tipo robustas y reactivas. Se debe entender que es un mecanismo para almacenar información que puede cambiar durante el ciclo de vida de un componente. Comprender cómo funciona la actualización del estado y cómo afecta al renderizado de componentes es esencial para desarrollar aplicaciones reactivas.

Los estados locales son extremadamente versátiles y pueden utilizarse en numerosos escenarios:

• Formularios: permiten almacenar valores de los campos mientras un determinado usuario lo completa.
• Toggles: para manejar estados activado e desactivado (como menús desplegables)
• Filtros: para almacenar filtrado en listas o colecciones
• Paginación: para mantener el número de página actual
• Cargas de datos: para indicar si los datos están cargando, se han cargado correctamente o ha ocurrido un determinado error

El manejo de estados es una habilidad fundamental en React que te permitirá crear interfaces dinámicas y reactivas. Dominar el uso de useState es solo el primer paso para aprovechar todo el potencial que React ofrece para el manejo de datos en tus aplicaciones.

Podemos encontrar la documentación oficial: https://react.dev/learn/responding-to-events

El desarrollo de aplicaciones web con React.js va más allá de estilizar componentes y estructuras siguiendo un esquema de diseño. Aquí es crucial la reacción dinámica de las interacciones de los usuarios. Los eventos nos sirven para detectar acciones del usuario en interacción con nuestra aplicación.

Es importante que una aplicación escuche eventos por algunas razones:

• Dinamismo: permitiendo que tu aplicación reaccione a las interacciones de los usuarios.
• Interactividad: mejora la experiencia del usuario brindando respuestas inmediatas a sus acciones.
• Control del flujo de datos: facilita la gestión de cómo y cuándo se debe ejecutar un código específico ante un evento determinado.

React.js convierte los atributos prefijados con ‘on’ (como onClick y onChange) en “event listeners” con JavaScript. Es decir será transformado a un AddEventListener (escuchador de eventos). React implementa un sistema de eventos sintéticos que actúan como una capa de abstracción usando Camel Case. Es decir, la primera letra de cada palabra en mayúscula, excepto la primera, que se escribe en minúscula. Por ejemplo: se pueden tener:

• Eventos de ratón: onClick, onMouseOver, onMouseOut
• Eventos de formulario: onChange, onSubmit, onFocus, onBlur
• Eventos de teclado: onKeyDown, onKeyPress, onKeyUp
• Eventos de clipboard: onCopy, onCut, onPaste

Para poder ejecutar los eventos en React, se deben usar arrow functions con la estructura () => {} de esta manera React entiende y no ejecuta de manera inmediata las funciones.

Por ejemplo:

const handleClick = () => {
  console.log('Le diste click');
};

// Al renderizar el botón en JSX
<button onClick={handleClick}>Haz clic aquí</button>

Otro ejemplo:

<input type="search" placeholder="Search..."
        onChange={(event) => {
          console.log('Escribiste en el Todo Search')
          console.log(event)
          console.log(event.target);
          console.log(event.target.value);
        }} />

Dentro del fragmento de código se puede mostrar por consola el evento con las diferentes propiedades que se necesita. El evento como tal nos muestra la propiedad SyntheticBaseEvent que es contenedor de todas las propiedades del evento, siendo mas sepecifico target que nos muestra el elemento con el cual se esta interactuando y finalmente value que especificamente y en tiempo real nos muestra el valor enviado por el evento.

Entonces, cuando se trabaja con eventos en React.js, se gestiona un tipo especial de objeto llamado SyntheticBaseEvent que permite asegurar la compatibilidad con todos los navegadores.

En ocasiones, para inputs se utiliza onChange para capturar cambios en tiempo real y manipular datos como texto escrito por el usuario.

const handleInputChange = (event) => {
  console.log('Escribiste:', event.target.value);
};

<input type="text" onChange={handleInputChange} />

target hace referencia desde donde se disparo el elemento HTML. Así permite seguir cada letra escrita o borrada en tiempo real, esencial para funciones como buscadores o filtros de datos.

Después de capturar un evento y obtener los datos necesarios, se debe continuar esos datos a otros componentes y actualizar la UI. Esa comunicación y actualización está facilitada por una herramienta fundacional en React que son los estados.

Conclusión

La gestión de eventos en React es una habilidad fundamental para crear aplicaciones interactivas y dinámicas. A través de los eventos, podemos capturar las acciones del usuario como clics, entradas de texto o movimientos del ratón, y responder a ellas de manera eficiente. React simplifica este proceso con su sistema de eventos sintéticos, permitiéndonos crear interfaces de usuario altamente responsivas con un código limpio y mantenible.

Los eventos en React nos permiten crear aplicaciones verdaderamente interactivas, respondiendo a las acciones del usuario de manera más eficiente. La combinación de eventos sintéticos y estados de React proporciona una forma poderosa de construir interfaces de usuario dinámicas con un código limpio y mantenible.

Como conclusión se puede tener:

• JavaScript nativo mejorado: React asegura que el código solo se ejecute cuando el evento sea disparado por el usuario.
• Eventos como funciones: Siempre encapsula el código en una función para diferir su ejecución hasta que el usuario realice la acción deseada, como un clic.

Tambien se puede consultar:

SyntheticEvent - React

¿Qué son los componentes?

Se cuenta con la documentación oficial en https://react.dev/reference/react/Component

Un componente es una pieza reutilizable de código o una unidad básica de construcción en el desarrollo de aplicaciones web modernas que define cómo se ve una parte de la interfaz (UI, por sus siglas en inglés, Interfaz de Usuario) y cómo se comporta. Se puede pensar como una función o clase que devuelve JSX (una mezcla de JavaScript y HTML). La idea es que cuente con dos características:

• Se basa en la reusabilidad, es decir no repetir código.
• Más fácil de mantener.
• Interactiva.
• Pueden recibir props, es decir datos externos.
• Pueden tener su propio estado interno, es decir states.

Funcionan como piezas de Lego que, al unirse, forman estructuras más complejas y funcionales.

• Identificar partes individuales de la interfaz (cards, headers, footers, etc.).
• Construir cada parte de forma aislada.
• Combinar estas partes para crear la aplicación completa.

Desarrollar en React se basa en un paradigma llamado Desarrollo Basado en Componentes. La reusabilidad o reutilización es clave para el dearrollo web eficiente y mantenible. Los componentes reutilizables son estructuras de código que pueden utilizarse múltiples veces en una aplicación, cambiando únicamente ciertos elementos internos como textos, imágenes o estilos. Esto nos permite mantener la consistencia en nuestra interfaz y ahorrar tiempo de desarrollo.

Por ejemplo, si necesitamos crear varias tarjetas (cards) en nuestra aplicación, en lugar de escribir el código HTML para cada una de ellas, podemos crear un componente base y simplemente modificar su contenido según sea necesario.

Hay una diferencia con los elementos que tiene React trabajando con JS convirtiendo esos elementos en etiquetas HTML. Un componente puede ser tan pequeño como un botón o tan grande como toda una página web. Por ejemplo:

function Saludo(props) {
  return <h1>Hola, {props.nombre}!</h1>;
}

Luego podés usar este componente así, podemos pasar propiedades al componente como si fueran atributos de HTML:

<Saludo nombre="María" />

Entonces podemos terminar renderizando:

<h1>Hola, María!</h1>

¿Cómo terminó llamando a un componente? Escribiendo su nombre con la siguiente sintaxis < Componente1 />. Lo mas comun es tener un index.js en /src donde se tiene App con mayúscula y creamos una variable root.

La función App es un componente de React ¿Cómo se esto? porque App está con letra mayúscula y la convención es que si comienza se comienza con mayúscula es un componente. Entonces, por conveción siempre los creamos utlizando PascalCase, es decir, “La Primera Letra De Cada Palabra En Mayúscula y Juntas”. Ejemplo: TodoList

De esta manera se puede ver localmente:

Hay que tener en cuenta que puedo tener header, img, div, etc. pero no es un archivo HTML sino JS. Lo que sucede es que JSX me permite combinar JS con XML, por eso hay mucha nomenclatura que cambia como por ejemplo en vez de “class” es “className”. El archivo JSX en un navegador se convierte todo en HTML.

Presentando JSX - React

Entonces, JSX es una extensión de la sintaxis de JS creada por Facebook o Meta. Su principal función es escribir código HTML dentro de archivos JavaScript facilitando la creación de componentes. JSX funciona como un Pre-Procesador ya que transforma el código .jsx a código JavaScript que pueda interpretar el browser, esto sucede gracias a un compilador, es decir Babel.

Los componentes son creados utilizando el metodo “react.createElement” , a través de Clases o por funciones.

De forma declarativa:

function Component() {
  return ( ... JSX ) 
}

Utilizando Arrow Functions:

const Component = () => {
  return ( ... JSX ) 
}

Tambien, podemos llamar un componente de react con otro componente de react.

import logo from './argisl.png';
import './App.css';

function App() {
 return (
   <div className="App">
     <TodoItem /> // AQUI ES DONDE TENEMOS EL OTRO COMPONENTE
     <header className="App-header">
       <img src={logo} className="App-logo" alt="logo" />
       <p>
         Bienvenidos a ArgisLab
       </p>
       <a
         className="App-link"
         href="https://platzi.com/reactjs"
         target="_blank"
         rel="noopener noreferrer"
       >
         Learn React
       </a>
     </header>
   </div>
 );
}
function TodoItem(){
 return (
   <li>
       <span>V</span>
       <p>Llorar con la llorona </p>
       <span>X</span>
   </li>
 );


}
export default App;

Props

En React, “props” es una abreviatura de “properties” o “propiedades”, se utiliza para pasar datos de un componente padre a un componente hijo. Las props son un mecanismo fundamental para lograr la reutilización y la composición de componentes. Cuando se crea un componente en React, se necesiten comunicarse y compartir información. De esta manera, se construyen interfaces de usuario (UI) dinámicas y escalables sin repetir código innecesariamente. Esta capacidad de crear estructuras base puede adaptarse a diferentes contextos.

Es decir, se puede pasar datos y funciones como props, que son de cualquier tipo de valor, como números, cadenas de texto, booleanos, objetos o incluso funciones. El valor puede cambiar de forma dinámica, en lugar de contenido estático o “hardcoded”.

Las props (propiedades) son similares a los parámetros en funciones, pero aplicadas a componentes:

<TodoCounter completed={16} total={25} />

Aquí, TodoCounter recibe dos props: completed y total. Estas se accesan en el componente mediante la destructuración:

const TodoCounter = ({ completed, total }) => (
  <h1>Has completado {completed} de {total} todos</h1>
);

Como podemos observar, se puede utilizar el mismo componente dos veces, pero teniendo diferentes valores para sus props. Esto nos permite mantener la misma estructura pero con contenido personalizado para cada instancia.

La prop children es una propiedad especial que automáticamente encapsula todo lo que está entre las etiquetas de apertura y cierre de un componente:

<TodoList>
  <TodoItem ... />
  <TodoItem ... />
</TodoList>

React convierte automáticamente el contenido en la prop children, que podemos utilizar dentro de nuestro componente. Asi, React transforma automáticamente a todo lo que se encuentre dentro del componente padre en un elemento “children” , es decir todo lo que se encuentre dentro de una etiqueta de apertura <Component> y una etiqueta de cierre </Component> para React será “children”:

// 1 forma 
const TodoList = ({ children }) => (
  <ul>{children}</ul>
);

// 2forma
function TodoList({children}){
 return (
   <ul>
     {children}
   </ul>
 );
  }
  export { TodoList };

// 3forma
function TodoList(props){
  return (
    <ul>
      {props.children}
    </ul>
  );
  
  }
  
  export { TodoList };

React Fragments

Podemos mirar el siguiente link: https://react.dev/reference/react/Fragment

React Fragments (<React.Fragment>) permite retornar múltiples elementos sin producir nodos extra en el DOM. Es útil para no llenar nuestro HTML de div innecesarios y puede verse así:

return (
  <React.Fragment>
    <Header />
    <MainContent />
    <Footer />
  </React.Fragment>
);

De este modo, se mantiene una estructura limpia y clara en el DOM. Recibe en el return y encapsula todos los componentes para mostrar. En el HTML, el React.Fragment está oculto. Se puede envolver todos los componentes JSX dentro de un contenedor padre, esto es debido a que React necesita envolver esos componentes para renderizarlos, y asi no crear nodos innecesarios en el DOM.

Renderización de arrays y property key

Cuando se trabajan con listas, es esencial proporcionar una prop key única para cada elemento. Esto facilita la eficiencia y orden del sistema de renderizado de React:

const todos = defaultTodos.map((todo, index) => (
  <TodoItem key={index} text={todo.text} completed={todo.completed} />
));

Aquí, nos aseguramos de que cada TodoItem tenga una key única, usando un índice o algún identificador único relevante. Es necesario una key porque ayuda a React a identificar qué elementos han cambiado, añadido o eliminado. Esto optimiza la actualización de listas y es una práctica recomendada para evitar advertencias en la consola y mejorar el rendimiento de la aplicación.

Las props transforman componentes con datos estáticos en entidades dinámicas y personalizables. Con React Fragments y la renderización mediante arrays, podemos tener un marco flexible y poderoso para el desarrollo de aplicaciones.

Conclusión

La modularidad y reusabilidad de los componentes permite:

• Identificar partes individuales de la interfaz como cards, headers, footers, etc.
• Abordar problemas más pequeños y manejables a diferencia de abordar todo de una vez
• Construir piezas de software de forma aislada
• Mayor facilidad para mantener y actualizar
• Combinar estas partes para crear la aplicación compleja y completa
• Mantener un código más limpio y organizado
• Reducir la duplicación de código
• Crear interfaces consistentes
• Ahorrar tiempo de desarrollo

Los componentes representan un cambio de paradigma respecto a la programación web tradicional. Al adoptar este enfoque modular, no solo escribimos menos código cómo algo monólitico, sino que se desarrollan aplicaciones más mantenibles, escalables y fáciles de entender.

HTML (Hypertext Markup Language)

Es el lenguaje de marcado estándar para crear páginas web. Define la estructura y presentación del contenido en una página web. HTML utiliza una sintaxis basada en etiquetas, donde los elementos se encierran entre etiquetas de apertura y cierre. Se utiliza de forma general en el desarrollo web para definir la estructura y presentación de una página.

JSX (JavaScript XML)

Es una extensión de JavaScript que te permite escribir código similar a HTML dentro de JavaScript. JSX proporciona un enfoque más declarativo y basado en componentes para la creación de componentes de interfaz de usuario. JSX permite la incrustación de expresiones y lógica de JavaScript dentro de la estructura de la interfaz de usuario, ya que HTML no ofrece esta funcionalidad directamente. HTML utiliza una nomenclatura de atributos en minúsculas y con guiones, mientras que JSX utiliza Camel Case para los nombres de atributos.

Esta sintaxis híbrida lo que hace que React sea tan poderoso y a la vez accesible para desarrolladores que ya conocen estas tecnologías.

La creación de componentes en React representa un cambio de paradigma respecto a la programación web tradicional. Al adoptar este enfoque modular, no solo escribimos menos código, sino que creamos aplicaciones más mantenibles, escalables y fáciles de entender. La sintaxis JSX parece extraña al principio, pero rápidamente se convierte en una herramienta intuitiva que acelera el desarrollo de interfaces de usuario complejas. Tanto HTML como JSX se utilizan para construir interfaces de usuario en el desarrollo web. Tanto en HTML como en JSX, se pueden aplicar estilos y asignar clases a los elementos para definir su apariencia. Ambos son interpretados y renderizados por los navegadores web.