DEV Community: Geovany

Lo que Apple me enseñó sobre cómo vender sin parecer que vende

Geovany — Tue, 22 Jul 2025 07:56:02 +0000

Esta semana tenemos menos artículos… pero te cuento algo curioso: abrí mi perfil de GitHub y vi que tuve 40 contribuciones en un solo día. Jajaja. Parecía que estaba en una hackathon conmigo mismo.

No fue una semana de lectura intensa, pero sí de mover las manos. Construí cosas, armé showcases para FNDRS, armamos algunos prototipos de ideas interesantes que usamos para mostrar a clientes e hicimos algunas pruebas con uno de nuestros productos con AI.

Siempre hubo lectura. Lectura que ya les he comentado que te paras a reflexionar y decir okay, ¿cómo puedo poner esto en acción con lo que tengo ahorita?

Aún así, me hice el espacio para leer este par de blogs que quiero compartirles.

1. 20 Brilliant Copywriting Tricks You Can Steal From Apple

📖 Link al artículo

Este artículo no es sobre Apple. Es sobre cómo Apple usa el lenguaje para hacerte querer algo sin que te des cuenta de que te lo están vendiendo.

Lo que me llamó la atención fue el ritmo con el que escriben, como si cada frase estuviera pensada para sonar bien en voz alta. También cómo juegan con contrastes: te dicen que algo es potente y simple al mismo tiempo, sin que suene contradictorio. Y evitan palabras vacías tipo “fácil” o “mejor”; prefieren darte algo visual como “funciona en segundos” o “dos veces más rápido”.

No están escribiendo textos, están diseñando el lenguaje. Lo tratan como parte del producto.

Me hizo pensar que muchos de los copies que hacemos para FNDRS explican, pero no despiertan deseo. Explicar está bien. Pero provocar es mejor.

Me armé un resumen personal, como para contártelo mientras caminamos. Y de paso te digo cómo me imaginé aplicarlas...

Ideas sueltas

Después de leer todo esto, me quedaron varias ideas dando vueltas. No como tareas de lunes, sino como cambios de fondo que quiero ver nacer en cómo construimos y presentamos FNDRS:

Quiero que cada propuesta que mandemos suene como si la escribiera alguien que te conoce. Que entienda lo que querés lograr, no solo lo que necesita entregar. Que el copy no parezca una descripción de tareas, sino una invitación a transformar algo juntos.

También me gustaría dejar de pensar en “features” como piezas técnicas. Empezar a pensarlas como superpoderes para quien las usa. En vez de decir “tiene dashboard de control”, decir “vas a poder ver todo en un solo lugar, sin depender de nadie más”.

Y tengo que decirlo: tenemos que matar los textos que suenan a pitch de startup genérico. Si no lo dirías en voz alta con naturalidad, no va.

Quiero que cada propuesta, cada deck, cada demo que salga de FNDRS se sienta inevitable. Como si lo estuviéramos escribiendo sabiendo que la persona al otro lado ya quiere decir que sí.

Por suerte nosotros tenemos a alguien muy talentoso que parece que ha entendido muy bien esta visión de FNDRS y la ha defendido desde un inicio. Agradezco mucho tenerlo como cofundador porque tiene ideas brillantes. No te vende un producto, te vende una experiencia.

Mención especial a Jorge Torres — no necesita títulos, su nombre le es suficiente.

2. How to Validate 3 Startup Ideas in a Weekend

📖 Link al artículo

Este fue el segundo artículo de la semana. Y aunque el título suena casi a clickbait… es súper sólido.

El artículo comparte un caso real donde probaron tres ideas distintas en un solo fin de semana. Y lo interesante no es sólo el framework (confirmar problema, testear solución, landing con tráfico, y un microcompromiso), sino cómo los datos te despejan el humo emocional.

Uno de los proyectos, por ejemplo, tenía todo el sentido: compartir equipo de gimnasio caro entre vecinos. Pero entre los temas de higiene y coordinación, los datos lo tiraron abajo. El segundo, una plataforma de mentoría para programadores potenciada con IA, fue el que mejor resonó. Buen feedback, validación clara, gente dispuesta a pagar. Y el tercero, un servicio para devoluciones automáticas de compras online, tuvo una validación parcial: el problema existe, pero nadie quería pagar.

Eso me dejó pensando en cuántas veces seguimos dándole vueltas a ideas que suenan bien… pero no tienen data que las respalde.

Para FNDRS, esto me inspira a aplicar mini-experimentos para features o ideas nuevas. Hacer un microtest antes de meterle horas de diseño o desarrollo. A veces una landing y una pregunta bien hecha nos puede ahorrar una semana de trabajo.

Cierre

No fue la semana más lectora, pero sí fue una semana de movimiento. Me quedo con esto: no todo se valida con líneas de código, y no todo se vende con una lista de features.

Seguimos construyendo. Con palabras, con manos, y con lo que haya.

Hasta la próxima.

Keep showing up. Your people will find you

Geovany — Fri, 18 Jul 2025 04:03:11 +0000

“You can’t connect the dots looking forward.”

Solo mirando hacia atrás puedes entender cómo llegaste hasta aquí.

Hace unas semanas, me lancé a construir algo nuevo 👇

👉 heyfrwrd.me

Automatizar DMs en Instagram parecía una gran oportunidad.

Los negocios ya están ahí, vendiendo todos los días. Y con lo actual que es la IA, parecía el momento perfecto para lanzar algo.

La idea gustó. A muchos les parecía útil. Pero pronto me enfrenté a una realidad:

Hay demasiadas soluciones genéricas.

Y entendí algo clave:

Los negocios no quieren cambiar todo a un nuevo CRM. Prefieren lo que ya usan o hacerlo ellos mismos.

Y yo tampoco quería construir un bot más que termine olvidado. Quería resolver un problema real, urgente y específico.

Un día publiqué:

“Keep showing up. Your people will find you.”

Y al siguiente conecté con gente con experiencia real vendiendo por Instagram: setters, closers, entrenadores de ventas.

Gente que ya sabe qué scripts funcionan, cómo responder objeciones, cómo convertir leads.

Hablamos, conectamos y decidimos unir fuerzas:

Ellos traen la experiencia en ventas y yo diseño el producto y construyo la tecnología para hacerlo funcionar.

HeyFrwrd ya no es un bot genérico que responde DMs.

Es un agente de ventas entrenado por humanos reales con experiencia comprobada.

Estamos trabajando con 20 negocios interesados, validando, mejorando la UI e iterando.

Queremos entender qué funciona y cómo llevar esto a algo que realmente impacte.

¿Quieres probarlo o dejar feedback?

👉 heyfrwrd.me

Construiyendo algo o simplemente evitando el fracaso

Geovany — Mon, 14 Jul 2025 15:41:45 +0000

Esta semana estuve más ocupado con cosas fuera del trabajo, lo que hizo que el tiempo se sintiera especialmente valioso. Por eso elegí con cuidado estos cuatro artículos de los que quiero hablar hoy.

1. El onboarding tiene que conectar rápido al usuario con el valor

Me encontré con este gran artículo de Aaron Dinin, PhD: One dull metric eventually determines the outcome for every startup.

Y me hizo pensar mucho en el onboarding de un producto. Algunos están tan bien diseñados que te conectan con el valor desde el primer momento. Pero otros simplemente te pierden o te dejan confundido sobre su propósito. Incluso después de terminar todo el proceso, no entendía realmente qué hacía el producto. Sentí que no se explicaba bien. Me frustré por no entenderlo, lo cerré y me fui.

Curiosamente, unos días después alguien me lo volvió a recomendar y pensé: “Este es justo el producto que necesito.” Le di otra oportunidad, pero otra vez me sentí perdido — las configuraciones no eran simples ni intuitivas. Y ahí entendí: incluso si tenés algo valioso, si tu producto no conecta clara y fácilmente con el usuario desde el inicio, no lo van a terminar usando.

Luego probé una herramienta totalmente distinta, de un campo completamente diferente. Todo era simple, intuitivo. Cada paso del onboarding describía exactamente lo que yo estaba viviendo. Sentí que la herramienta y sus usuarios experimentaban los mismos problemas que yo pensaba que eran solo míos. Al final, todo era claro: qué hacía, cómo lo hacía y por qué lo necesitaba. Todo estaba al alcance y, si no, había una descripción útil o un popover que lo explicaba.

Dos productos, dos conclusiones.

El primero: un gran producto, pero no sentí conexión porque no entendía lo que resolvía.
El segundo: un producto que me generaba dudas. Pero su onboarding me hizo sentir que lo necesitaba, al punto de decir: “Desde ahora no puedo vivir sin esto — necesito pagarlo.”

Hoy veo distinto lo que estoy construyendo. No estoy haciendo un producto para enseñar a usarlo. Estoy haciendo un producto para que el usuario vea el valor — y lo esencial que es para él — ahora mismo.

Y esta frase se me quedó grabada:

"Las mejores startups no ganan por conseguir más usuarios. Ganan por mantener más usuarios."

Podemos generar un gran impacto con un gran producto. Pero también tenemos que movernos a favor de los usuarios que confiaron en nosotros.

2. Seguí en el camino

También encontré este post que me dijo justo lo que necesitaba escuchar: Notes for the entrepreneur in all of us.

Es una colección de ideas que me parece importante recordarme de vez en cuando.

“Solo podés perder lo que tenés, pero no podés perder lo que sos.”

Esa frase me recordó que incluso si pierdo todo —clientes, dinero, proyectos— todavía tengo lo más importante: quién soy. Las habilidades que desarrollé, la claridad que gané en el camino. Podés quitarme todo lo que tengo, pero no lo que soy capaz de volver a construir. Si mañana tuviera que empezar de cero, podría. Porque no se trata de lo que tengo, sino de en quién me convertí al construirlo.

“Si no buscás el riesgo, el riesgo te va a encontrar.” — atribuida a Reid Hoffman

Esto se conecta con otro artículo que leí. Decía que no podés asumir que algo no va a funcionar, ni limitarte a repetir lo que otros ya intentaron. Porque hay muchos caminos hacia el mismo lugar. Y para encontrarlos, hay que tomar riesgos, probar cosas, equivocarse.

“No puedes ser normal y esperar resultados anormales.” — Jeffrey Pfeffer

No puedes jugar siempre seguro y esperar resultados extraordinarios. Si quieres algo fuera de lo común, vas a tener que hacer cosas que no todos se animan a hacer. Y eso incluye exponerte, fallar y probar caminos distintos.

“Solo necesitás tener razón una vez.” — Drew Houston

Últimamente pienso mucho en esto. Fallar mil veces no te invalida si acertás una sola. Esa vez puede cambiarlo todo. Por eso estoy dispuesto a fallar más, a probar escenarios distintos, a buscar esa oportunidad que lo cambia todo.

“No hay una sola forma de hacer las cosas.” — basado en el perspectivismo de Nietzsche

No hay una sola forma de ver las cosas, ni un único camino correcto para construir. Cada uno lo vive desde su perspectiva, y eso también es válido. Esta frase me dio permiso para soltar la necesidad de hacer las cosas “como se supone que deben hacerse.”

“Gradualmente, y luego de repente.”

El progreso se siente lento — hasta que un día todo cambia. Eso es lo que estoy cultivando con leer, con escribir, con hacer contenido. Y pronto voy a probar algo nuevo: grabarme hablando, para entender mejor cómo conectar con los clientes. También lo pienso con FNDRS: al principio, sin clientes ni contactos, todo se siente lento. Pero esto se construye paso a paso. Y aunque sé que falta mucho, no me desanima. Al contrario, me hace sentir que ya estoy en el futuro, recordando con cariño las noches sin dormir, los sacrificios, las tardes largas. Todo lo que hicimos cuando esto recién empezaba.

Muy buena lista. Me la voy a guardar para volver a ella cuando me distraiga y necesite recordar por qué sigo intentando.

3. Escribí aunque nadie escuche… todavía

The guide to exploit the most profitable one-person business niches in 2025.

Este artículo me confirmó algo que escuché hace mucho tiempo: escribir te ayuda a pensar con más claridad.

A veces creemos que entendemos algo. Sentimos que ya lo internalizamos. Pero tratá de explicárselo a otra persona — como si fuera una conversación — y enseguida vas a notar dónde están tus vacíos.

Eso es lo que me dio leer y escribir: la oportunidad de enfrentar mis propias dudas. Tropezarme con lo que no entiendo, volver a investigarlo y aprenderlo mejor para poder comunicarlo.

Michael Lim dice:

"No sabés quién sos hasta que escribís."

Porque escribir no es solo publicar. Es ordenar. Es entender. Es procesar. Es convertir ideas sueltas en un camino. Escribir en largo te obliga a pensar con claridad, a encontrar tu voz, a descubrir tu filosofía.

Y si lo hacés todos los días, aunque nadie aplauda, aunque no haya retorno inmediato, algo cambia. Se te aclara la cabeza. Tus ideas se acomodan. Te conocés un poco mejor.

Eso es lo que estoy haciendo con estos textos. Y si algún día alguien los encuentra y le sirven, mejor. Pero mientras tanto, ya me están sirviendo a mí.

Esa es mi apuesta: crear desde la claridad. Desde las ganas de dejar un registro real. No porque se haga viral. Sino porque es verdadero.

4. ¿Estás construyendo o solo evitando fallar?

El último artículo que quiero compartir esta semana me dejó pensando mucho: You’ll never be a great entrepreneur if you’re still trying to get an A.

Porque toca una verdad incómoda que muchos evitamos: queremos que todo salga bien desde el principio. Cuesta soltar la idea de que esto es como la escuela. Que hay una forma correcta, que alguien nos va a calificar, que si fallamos vamos a “reprobar.” Y eso, en el mundo real, es una trampa.

Muchas veces postergamos decisiones, validaciones o lanzamientos porque estamos esperando la “respuesta correcta.”

"El problema es que no están tratando de construir algo. Solo están tratando de hacer las cosas ‘bien’. Pero en el mundo de startups, hacer las cosas ‘bien’ es la forma más rápida de no hacer nada en absoluto."

Y sí. Ese impulso de hacerlo todo bien desde el inicio puede ser justo lo que te impide construir algo valioso. Porque no se trata de que todo funcione. Se trata de probar, fallar y aprender en el camino.

Esta semana voy a proponerle algo nuevo a mi equipo: dejemos de buscar aprobación unánime para cada idea. Demos permiso para probar cosas nuevas sin pasar por todos los filtros. Quizás sea un formato nuevo de blog, un post diferente o un producto mínimo viable que alguien del equipo testea. Quiero que se animen. Que se equivoquen. Que sientan lo que es fallar y volver a intentar. Porque en ese proceso, inevitablemente nos acercamos a lo que sí funciona.

Hay algo poderoso en darnos cuenta de que nadie sabe realmente el camino. Que estamos improvisando. Que fallar no es un desvío — es parte del mapa.

Y si ya fallamos en todas las opciones posibles… entonces la única que queda es la que sí funciona.

Tomá más riesgos — no para fallar, sino porque fallar es el único camino hacia adelante.

Hasta la próxima semana.

Construir para ti vs. construir para otros: la diferencia entre hobby y producto

Geovany — Tue, 08 Jul 2025 05:14:30 +0000

Esta semana estuve más ocupado en reuniones, validaciones y pequeñas tareas que en aprender formalmente algo nuevo o leer artículos. Aun así, entre espacios muertos y filas en el tráfico, pude leer algunos textos muy interesantes. Me pasa mucho que son de esos posts que te hacen cerrar la pestaña, quedarte viendo al techo unos segundos y luego anotar algo en tu libreta. Es como si respondieran una pregunta o inquietud que ya estaba rondando en la cabeza.

También avancé un poco más con El diario de un CEO, que lo vengo leyendo muy lento. Más abajo comento lo que me llevo de ese libro también.

"I Documented Every Founder Mistake for 3 Years" — Michael Taylor

Esta semana se me cruzó muchas veces este pensamiento: ¿estás construyendo el producto porque te gusta a vos, o porque tus clientes realmente lo necesitan? Michael cuenta que pasó tres años observando errores de fundadores. Y la conclusión fue clara: casi todos caen en los mismos huecos. El más común: construir sin tener a nadie esperando del otro lado.

Hablaba de esa sensación de estar haciendo muchas cosas, llenando el día de tareas, avanzando... pero en realidad solo estás ocupado. No es lo mismo que progresar. También deja claro que preguntar si algo "les gusta" no sirve. La validación real es si alguien paga, lo usa, vuelve. Todo lo demás es teatro. Lo más incómodo: muchos productos fracasan porque fueron hechos para una audiencia que solo existía en la cabeza del fundador.

"You're not building a startup. You're rehearsing one."

Esa frase me quedó grabada. Si nadie te pidió esto, ¿por qué estás construyéndolo?

"Why the Best Entrepreneurs Don’t Worry About Building Products" — Aaron Dinin

Este texto es casi una intervención. Me hizo darme cuenta de que a veces sigo pensando como un creador de cosas, no como alguien que resuelve problemas para personas.

Primero tenés que buscar a las personas. No me refiero a una audiencia masiva ni a una comunidad enorme, sino a alguien real, específico, que ya está buscando una solución. Después, con eso claro, construís lo que esa persona necesita.

Porque el producto perfecto, si nadie lo necesita, es como hacer una escultura para exhibirla en tu habitación. Te puede emocionar, puede estar bien hecha, pero nadie más la va a ver.

La pregunta que realmente vale la pena hacerse no es "¿cómo hago esto bien?", sino "¿a quién ya le duele esto hoy?"

"Don’t build a product. Build a customer base."

Esta semana me propongo algo más difícil: resistir la urgencia de construir features con IA, arquitectura compleja o caer en el overengineering, y en cambio, empezar por escuchar mejor.

"97% of You Aren’t Built for This" — Marshall Hargrave

Este fue el más directo. No venía a motivarte. Venía a decirte que esto es duro, solitario y muchas veces absurdo. Que si no estás dispuesto a seguir cuando no tenés ni idea si va a funcionar, entonces tal vez no es lo tuyo.

Lo que más me quedó fue que no hay mapa. Nadie te va a decir si vas bien.

Emprender es exponerte a que todo falle… y seguir. Y al final, la diferencia no la hace la genialidad sino la persistencia. Una persistencia casi irracional.

"There’s no blueprint. You write it as you go."

No es una frase para compartir en LinkedIn. Es algo para repetirse cuando todo esté fallando.

Bonus: El diario de un CEO

(Sigo leyendo este libro, en breve compartiré un resumen más completo. Por ahora solo puedo decir que te obliga a pensar más en negocio que en marketing.)

Hacia dónde apunto ahora

Quiero hablar con usuarios, aunque sea incómodo. No avanzar con funcionalidades sin validación real. Leer menos y actuar más (aunque siga anotando frases motivacionales y bonitas). Y escribir estos aprendizajes aunque nadie los lea. Porque me ordenan.

Lo hago porque quiero moldear mi cuerpo y mi mente para hacer lo absurdo. Quiero exponerme al fallo, a que todo falle, y aun así seguir. No importa si no soy el más listo o el que más ingeniería sabe. Quiero ser el que no se rindió, el que se quedó despierto, el que vio más allá. Quiero ser el que continuó, incluso sin saber exactamente hacia dónde iba.

Hasta la próxima semana.

Enseñando para aprender: el inicio de esta serie

Geovany — Tue, 08 Jul 2025 05:10:22 +0000

Hay una frase que cada cierto tiempo se me repite en la cabeza. La escuché en una canción y se me quedó grabada:

"Aprende a enseñar

Enseñando aprenderás

Tu vida está con quien tú amas más

Hoy todo en lo que sueñas

Y en tu imaginación

Aquí está. Este es el momento.

Realizá tu ilusión."

Por eso decidí comenzar esta serie de publicaciones. Un espacio para procesar lo que voy aprendiendo, cómo lo estoy aplicando, y qué resultados estoy empezando a ver. Cada semana compartiré lo más importante que leí: ideas de artículos, errores que estoy cometiendo, patrones que estoy empezando a notar o fragmentos de libros que estoy leyendo.

Todo esto nace del deseo de afinar mi criterio, fortalecer mi perspectiva y crecer en lo que hago, especialmente en mi rol como cofundador de una agencia de software —FNDRS— donde construimos productos para otras empresas. Pero también de un nuevo capítulo: lanzar mi propio producto. Entrar al mundo startup desde otro ángulo. Ya no solo como constructor, sino como alguien que tiene que colocar una solución en el mercado.

Esta sección no será un diario personal, pero sí una bitácora honesta. Un intento de aprender en público.

Y si estás en algo parecido —empezando un proyecto, un producto, una idea, o simplemente buscando claridad— espero que algo de esto te sirva también.

De un “sí” tímido al giro estratégico: lo que aprendí esta semana

El lunes pasado leí algo que me dejó pensando: decía “sí” a muchas ideas, muchas validaciones... pero rara vez pasaba al “comprar”. Así que empecé a analizar cómo estoy abordando ventas, validación de ideas y hasta relaciones con cofundadores. Esto fue lo más valioso que me llevé esta semana:

La trampa del “sí” fingido

En ventas, un “sí” puede ser una trampa. Muchas veces ese gesto del cliente no significa que esté convencido. Puede que solo quiera terminar rápido la conversación. El artículo que leí lo deja claro: no basta con convencer, hay que crear una experiencia donde decir “sí” lleve naturalmente a la acción —menos fricción, más claridad, más confianza.

Esta semana cambié la forma en que converso con usuarios en heyfrwrd.me. En vez de depender solo de encuestas, hablé directo con ellos. Preguntas abiertas, personales, intentando entender por qué ciertas tareas les consumen tanto tiempo. Y descubrí que cuando hablás como persona —no como formulario—, la gente responde con honestidad.

¿Qué está fallando en tu propuesta?

Otro post me hizo pensar: ¿y si el problema no es el producto ni el precio? ¿Y si simplemente estás resolviendo algo que al usuario no le importa tanto? Tal vez ni siquiera lo reconoce como problema. Una propuesta efectiva no es un pitch cerrado, es una conversación en constante evolución.

Esto lo apliqué directo en la forma en que presento heyfrwrd.me. Cambié el enfoque técnico por frases que los usuarios ya usan. No digo “automatizá tus respuestas”, digo “dejá de gastar media hora diaria contestando lo mismo que podrías automatizar sin esfuerzo”. Esta semana actualicé el copy de la landing y ya estoy testeando la reacción.

Cuando la amistad pesa más que el negocio

Ser amigo de tu cofundador tiene ventajas… pero también riesgos. Evitás conversaciones incómodas, las decisiones se dilatan, los roles se confunden. Una frase del artículo que leí: la confianza no reemplaza la claridad.

Esta semana agendé una conversación pendiente con mis socios. No por conflicto, sino porque es mejor hablar ahora que apagar incendios después. También escribí una lista de decisiones que venimos pateando. Claridad antes que comodidad.

La intimidad como obstáculo silencioso

Las relaciones muy cercanas pueden suavizar demasiado el conflicto. Y en una startup, el conflicto es inevitable. Si no se habla, se acumula como deuda emocional y operativa. También me pregunté: ¿qué significa realmente “tener éxito”? Y ¿hasta dónde quiero llegar con esto?

Escribí sin filtros cuál es mi visión de éxito para FNDRS y para heyfrwrd.me. Ponerlo en palabras me dio claridad sobre qué conversaciones todavía no tuvimos y por qué es mejor tenerlas ahora.

Creciendo orgánicamente en Instagram

Una persona creció de 0 a 220k seguidores sin gastar un centavo. ¿Cómo? Consistencia. Sin preocuparse por hashtags, ni horarios, ni algoritmos. Solo publicando pensando en su audiencia.

Esto me hizo repensar cómo llevamos la marca de FNDRS. Tenemos buenas ideas, pero sin ritmo. Esta semana hice un calendario básico de contenido: tres publicaciones semanales que resuelvan dudas, muestren trabajo o generen conversación. También empecé a sistematizar: plantillas, temas recurrentes y menos decisiones. Mostrarte con constancia puede ser más valioso que brillar una vez.

Entre otras ideas, esto fue lo más valioso que me llevé esta semana. Algunas ya las estoy poniendo en práctica. Otras me siguen dando vueltas. Lo importante es seguir afinando, ajustar lo que no funciona y compartir lo que sí.

Enlaces a los artículos mencionados

Cuándo usar Custom Hooks en React y Cuándo No

Geovany — Mon, 30 Jun 2025 19:14:26 +0000

Recientemente, me encontré con una publicación titulada "¿Why now devs use custom hooks instead services in React? (perspective of pre-hooks React developer). La perspectiva presentada me pareció bastante intrigante. El autor comenta cómo los desarrolladores que comenzaron su viaje directamente con React tienden a depender en gran medida de custom hooks para diversas funcionalidades o servicios.

Inicialmente, pensé que esta perspectiva podría ser subjetiva o limitada a los desarrolladores dentro del círculo del autor. Sin embargo, llegue a explorar esto más a fondo en Reddit, donde encontré otra publicación que planteaba "Cuando es recomendable utilizar custom hooks". Para mi sorpresa, la mayoría de las opiniones fueron que siempre se debería utilizar.
Así que me pareció un tema muy interesante del que investigar, ademas de agregar ciertas opiniones personales y recomendaciones.

Primero que nada, ¿Cuál es la recomendación de React?

Los Custom Hooks en React son funciones JavaScript que siguen una convención de nombre específica: deben comenzar con "use" (por ejemplo, useEffect, useState). Estas funciones permiten encapsular lógica compleja y reutilizable en componentes de React. Según la documentación oficial de React, los Custom Hooks están diseñados para compartir lógica entre componentes de React sin la necesidad de copiar y pegar código.
Cuando se trata de utilizar Custom Hooks, React sugiere seguir algunas prácticas recomendadas:

**1. Convención de Nombres: **Los Custom Hooks deben comenzar con la palabra "use" para que React pueda identificarlos y aplicar ciertas optimizaciones.

2. Extraer Lógica Reutilizable: Utiliza Custom Hooks para extraer lógica que se repite en múltiples componentes. Esto ayuda a mantener un código más limpio y modular.

**3. No Introducir Estado Global: **Evita introducir estado global en Custom Hooks, ya que esto puede complicar la gestión del estado y llevar a efectos secundarios inesperados.

Entonces, ¿Cuando se recomienda utilizar Custom Hooks?

Entonces una vez definido lo que es un custom hook podemos empezar a definir puntos claves y escenarios en los que podemos utilizarlos:

1. Abstracción: Cuando la lógica de un componente se vuelve demasiado compleja, extraerla en un custom hook puede mejorar la legibilidad y el mantenimiento. Al abstraer los detalles de implementación, los custom hooks permiten que los componentes se centren en sus responsabilidades principales, promoviendo una separación más clara de las preocupaciones. Por otro lado, no siempre es necesario o beneficioso utilizarlos.

Ejemplo de cuando usar custom hooks: ✅
Supongamos que tenemos un componente UserList que muestra una lista de usuarios y realiza una llamada a una API para obtener los datos. La lógica de obtener los datos y manejar posibles errores se ha vuelto demasiado compleja y queremos abstraerla en un Custom Hook llamado useFetchUsers.

Ejemplo de cuando no es necesario usar un custom hook: ❌
Supongamos que tenemos un componente LoginForm que maneja la autenticación de usuarios. La lógica de validación de datos y el manejo del estado del formulario se manejan fácilmente dentro del propio componente, y no hay necesidad de extraerla en un Custom Hook.

En este caso, la lógica del formulario de inicio de sesión es lo suficientemente simple como para ser manejada dentro del componente LoginForm sin la necesidad de utilizar un Custom Hook. La abstracción adicional podría introducir complejidad innecesaria y hacer que el código sea menos claro y mantenible.

2. Lógica repetitiva: Debería de considerarse el uso de custom hooks cuando se observe que la lógica se repite en varios componentes. Esta es una oportunidad perfecta para escribir un custom hook que encapsule esa lógica, haciendo que su código sea DRY (Don't Repeat Yourself) y más fácil de mantener.

Ejemplo de cuando usar custom hooks: ✅
Supongamos que tenemos dos componentes CounterA y CounterB que comparten la lógica para manejar el estado de un contador. La lógica de incremento, decremento y reinicio del contador se repite en ambos componentes. Es una oportunidad perfecta para crear un Custom Hook llamado useCounter que encapsule esta lógica.

Ejemplo de cuando no es necesario usar un custom hook: ❌
Supongamos que tenemos dos componentes ProductList y Cart que muestran una lista de productos y un carrito de compras, respectivamente. Cada componente tiene una función fetchData que realiza una llamada a la API para obtener datos. Aunque la lógica de llamada a la API es similar en ambos componentes, no es necesario encapsularla en un Custom Hook, ya que la implementación de cada llamada puede diferir según el contexto.

3. Compartir lógica entre componentes: Los custom hooks facilitan el intercambio de lógica entre componentes no relacionados. Esto es particularmente útil para implementar cuestiones transversales como la autenticación, la tematización o la internacionalización, asegurando la coherencia en toda la aplicación.

Ejemplo de cuando usar custom hooks: ✅
Supongamos que tenemos un componente Header que muestra un botón de inicio de sesión y un componente Sidebar que muestra el nombre de usuario una vez que el usuario ha iniciado sesión. Ambos componentes necesitan acceder al estado de autenticación y a las funciones para iniciar y cerrar sesión.

En este ejemplo, el Custom Hook useAuth encapsula la lógica de autenticación, permitiendo que los componentes Header y Sidebar compartan fácilmente la misma lógica sin acoplamiento directo.

Ejemplo de cuando no es necesario usar un custom hook: ❌

Supongamos que tenemos un componente Form que maneja la lógica de un formulario de registro de usuarios. La lógica específica del formulario, como la validación de campos y el envío de datos, es única para este componente y no se comparte con otros componentes en la aplicación.

En este caso, la lógica específica del formulario está completamente contenida dentro del componente Form. No hay necesidad de extraer esta lógica en un Custom Hook ya que no se comparte con otros componentes y no se beneficiaría de su reutilización. Mantener la lógica dentro del componente hace que el código sea más claro y mantenible en este contexto.

⚠️ Usar custom hooks con cautela ⚠️ Recomendaciones Personales

Ciertos puntos que recomiendo a tener en cuenta cuando se este trabajando con custom hooks:

1. Optimización prematura: Importante resistir la tentación de crear custom hooks para cada pieza de lógica. La optimización prematura puede generar complejidad y abstracción innecesarias, lo que dificulta la comprensión y el mantenimiento del código. En lugar de ello, hay que favorecer a la simplicidad y la claridad hasta que los patrones de repetición surjan orgánicamente.

**2. Lógica específica del componente: **No toda la lógica garantiza la extracción en un custom hook. Si una parte de la lógica está estrechamente relacionada con un componente específico y es poco probable que se reutilice en otro lugar, puede ser más apropiado mantenerla dentro del propio componente, evitando abstracciones innecesarias.

3. Custom hooks demasiado abstractos: Los custom hooks demasiado abstractos con demasiadas responsabilidades pueden volverse difíciles de manejar y de entender. Habrá que a apuntar a logica de responsabilidad única que encapsule inquietudes específicas, promoviendo la claridad y la Componentización.

Pensamientos Finales

Ahora que hemos revisado todos estos ejemplos, espero que esta vez si puedas elegir entre si es un caso valido para poder usar custom hooks o no, centrándonos en su propósito inicial de abstracción y reutilización de código.
No podemos quitar que los Custom Hooks han demostrado mucha importancia en el desarrollo actual de React, porque ofrecen una manera elegante y eficiente de compartir lógica entre componentes. Ya sea para abstraer lógica compleja, eliminar la repetición de código o facilitar el intercambio de funcionalidades entre componentes no relacionados.
Personalmente, creo que es importante saber entender estos conceptos para saber cuándo mantener nuestra lógica en nuestros servicios y cuándo utilizarlos como Custom Hooks. Me considero muy fan de manejar la mayoría de la lógica como un servicio y solo utilizar Custom Hooks para casos específicos muy comunes, hooks comunes como:** useFocus, useWindowSize, useFormUpdate**. Estos son ejemplos de hooks que suelo usar con frecuencia en mis proyectos y que me ayudan a manejar cierta lógica compartida entre componentes.

En otro blog podríamos profundizar en cómo implementar estos hooks si te parece interesante 🎯

Mastering React: A Simplified Guide for Folder Structure

Geovany — Wed, 20 Mar 2024 22:10:53 +0000

Have you ever found yourself in the situation of wanting to start a new React project and, for whatever reason, you can't determine how you should structure it from the beginning to avoid having to think about it throughout the project and focus directly on the quality of your code? Let me tell you, this is quite common in software development. However, as you continue developing projects of different sizes, you will realize that over time you will do it automatically, without thinking about it as much, because you will already have some notion of how your project will grow.

In this guide, you will find simple examples from real projects and, finally, a recommendation that I would like you to pay attention to in order to determine if it is useful to you, along with an explanation of how to divide each folder and what each one should contain.

Understanding the Importance of Folder Structure

Before going into the details, it's important to understand why a well-planned folder structure is necessary in React development. For this, I like to divide it into four central points:

Modularity: 🚀

Modularity is the cornerstone of a robust folder structure. By dividing your application into smaller, reusable modules, you not only enhance code reusability but also facilitate maintenance and updates. Each module should encapsulate a specific functionality or feature, allowing for clear separation of concerns. In short, let's follow best practices by dividing each thing in its place.

Separation of Concerns: 🧠

Separating different aspects of your application's functionality into distinct directories promotes clarity and reduces complexity. For instance, separating UI components from business logic, stylesheets, and utility functions allows developers to focus on specific areas of the application without becoming overwhelmed. This separation fosters better code organization and facilitates collaboration among team members.

Scalability: 📈

A well-designed folder structure should be scalable and capable of adapting to growth and expansion as your project evolves. As new features are added and requirements change, your folder structure should remain flexible enough to adapt without requiring a major reorganization. By anticipating future changes and designing with scalability in mind, you can ensure that your project's structure remains agile and responsive. This greatly depends on the developer's experience in being able to anticipate the project's needs.

Folder Structure I use

For recent projects, I've been using almost the same folder structure. Some minor modifications have been made, but as I mentioned earlier, this will largely depend on the project you're developing.

Project #1

Project #2

So, as you can see, some of them have some folders, and others don't have any. What should I do, and where should I choose?

First of all, remember that your project structure will always be evolving, so I recommend starting with something.

Here is the initial extended folder structure that I typically consider:

.
├── tests
|   └── e2e/
|   
└── src/
    ├── api
    ├── assets/
    ├── components/
    ├── hooks/
    ├── layout/
    ├── pages/
    ├── routes/
    ├── store/
    ├── styles/
    └── utils/

A more detailed description of what each of them should contain to ensure you have a clear idea of how to organize your project:

e2e/: This directory contains end-to-end tests (E2E), which simulate user interactions with your application from start to finish. With tools like Cypress or Playwright, you can write tests that mimic the real user behavior and verify that your application works correctly in a production-like environment.

api/: This directory contains modules responsible for handling API requests and interactions. Separating API-related logic into its own directory helps maintain a clear separation of concerns and facilitates code management with server calls.

assets/: Here, aim to store static assets such as images, fonts, and other resources used in your application.

components/: This is where you'll store reusable user interface components. These components can range from simple buttons and input fields to more complex elements such as navigation bars and cards.

hooks/: It's very common to have a dedicated directory to store custom hooks, such as useFetch() or useWindowSize(), along with other custom hooks you may need in your application.

layout/: In a Front-End application, it's crucial to consider the layouts or designs that define the overall structure of your application. These layouts are often highly reusable, so I recommend storing any styles that repeat in your application here. Design components encompass elements such as headers, footers, sidebars, and other structural elements shared across multiple pages or views of your application.

pages/: The pages/ directory is where you'll store top-level page components representing different routes or views in your application. Each page component corresponds to a specific URL route and typically encapsulates the layout and content of that route.

routes/: This directory contains route configuration files that define the mapping between URL routes and corresponding page components. Route configuration files often use libraries like React Router to set up client-side routing in your application.

store/: This directory contains modules related to state management using libraries such as Redux or MobX. State management modules define actions, reducers, and selectors to manage application state predictably and centrally.

styles/: Here, global style sheets, theme files, and other style-related resources used in your application are managed.

utils/: This directory contains utility modules that encapsulate common functionalities and helper functions used throughout your application. Utility modules provide reusable logic for tasks such as formatting, validation, and data manipulation.

Conclusion:

To conclude, I'd like to emphasize that creating an effective folder structure for your React projects is an ongoing process. As you dive into practice and encounter different types of projects, you'll gain experience and refine your skills in this aspect.

A reflection I'd like to share is that, in the world of software development, the best way to learn is by facing challenges head-on. If you come across something you're unsure about, I encourage you to try tackling it on your own first. If you find yourself stuck, don't hesitate to turn to blogs, videos, or repositories for guidance and learn from the experience of other developers.

Personally, early in my career, I found a lot of inspiration by observing how others coded. Exploring repositories from other developers or organizations provided me with ideas on how to structure my own projects. Over time, I've adopted and adapted different approaches based on my needs and preferences, enriching my skill set and development style.

I sincerely hope this guide has been helpful in your development journey. Remember, the best way to learn is always through experimentation and embracing mistakes. Don't be afraid to try new things and be willing to learn from your mistakes along the way.

Your ability to grow and improve as a developer depends on your willingness to face new challenges and learn from them!

Como configurar Prettier y no morir en el intento, extensiones de VSCode que te ayudarán 🤯

Geovany — Wed, 06 Mar 2024 04:34:48 +0000

Hola 👋, imagina el siguiente escenario: tienes un equipo de trabajo centrado en crear código limpio y mantenible, pero lo más importante es que este código debe ir a producción lo antes posible y sin errores.

Ahora bien, cualquiera podría sugerir comenzar con pruebas unitarias, pruebas de integración, pruebas end-to-end, y demás.

Sin embargo, a menudo olvidamos algo fundamental: la estructura del código. Para asegurarnos de que nuestras pruebas funcionen correctamente y de que nuestros componentes estén bien escritos, es crucial mantener una estructura coherente durante todo el desarrollo.

Afortunadamente, existen herramientas que nos ayudan a mantener consistencia y seguir estándares durante el desarrollo.

Entre estas herramientas destacan ✨ ESLint ✨ y ✨ Prettier ✨. Aunque la comunidad de desarrolladores debate sobre qué reglas deben usarse y cuáles no, podemos confiar en estas herramientas para mantener una armonía entre los desarrolladores de nuestro código.

A continuación, te presento una guía básica sobre la instalación, configuración de archivos Prettier y configuración del formateo en tu editor. En este caso, usaremos VSCode para que el formateo se realice automáticamente. Además, como bonificación ✅, te recomendaré algunas extensiones de VSCode que me han sido de gran ayuda.

Empecemos definiendo ¿Qué es Prettier y por qué es tan genial? 😎

Prettier es una herramienta que formatea automáticamente tu código para cumplir con un conjunto predefinido de reglas de estilo

¡Y lo hace de manera consistente! Imagina nunca tener que preocuparte por la indentación, los puntos y comas, o la longitud máxima de línea nuevamente. Prettier se encarga de todo esto para que no tengas que complicarte la vida.

Ahora que hemos establecido una definición básica, ¡vamos a comenzar!

Paso 1: Instalación

Primero, necesitas instalar Prettier en tu proyecto. Puedes hacerlo fácilmente usando npm:



npm install --save-dev prettier

Paso 2: Configuración básica

Ahora que Prettier está en tu proyecto, necesitas configurarlo. Prettier es conocido por su configuración "sin configuración". Es confuso pero basicamente esto significa que viene con un conjunto de reglas predeterminadas que son ampliamente aceptadas por la comunidad. Pero, si deseas personalizar algunas cosas, puedes crear un archivo .prettierrc en la raíz de tu proyecto y agregar tus preferencias allí.

Si te sirve esta es la configuracion que suelo usar:



{
  "semi": false,
  "trailingComma": "none",
  "tabWidth": 2,
  "singleQuote": false,
  "jsxSingleQuote": false,
  "bracketSameLine": true,
  "bracketSpacing": true,
  "printWidth": 130,
  "arrowParens": "always"
}

⚠️🚨 Nota Importante ⚠️🚨: Si ya estás trabajando en un equipo, es muy probable que estas reglas ya estén definidas por los desarrolladores. Por lo tanto, cualquier cambio que desees proponer a estas reglas deberías consultarlo primero con tu equipo. De lo contrario, podrías causar conflictos innecesarios. En caso de que estes desarrollando tu proyecto por tu cuenta dale viaje 👍

Paso 3: Integración con tu editor de código

Aquí viene lo masiso. Para sacar el máximo provecho de Prettier, es crucial integrarlo con tu editor de código favorito. Afortunadamente, Prettier ofrece extensiones para una amplia gama de editores, desde Visual Studio Code hasta Sublime Text y más allá.

Aqui las mas recomendadas:

En caso de que estés integrándolo con ESLint, es necesario instalarlo también para que nos alerte sobre posibles errores.

Por ahora, esas serían todas las extensiones que necesitaríamos.

Paso 4: Formatea tu código

Ahora viene la parte más gratificante: ¡formatear tu código con solo usar Command + S! Simplemente abre tu archivo en el editor y guarda el documento. Verás cómo tu código se transforma mágicamente en una obra maestra de legibilidad y coherencia.

Pasaras de esto ❌:

A esto ✅:

Ahora sí podrás dormir feliz por las noches al ver que tu código se formatea solo.

🚨🚨 Recomendaciones finales 🚨🚨

Quizás llegaste hasta aquí y te diste cuenta de que guardar el documento no hizo lo que esperabas. Sin embargo, no te preocupes, tengo más soluciones para evitar que te vuelvas loco por esto. Ten en cuenta los siguientes consejos:

Agrega Prettier como tu formateador por defecto

Esto lo puedes hacer de la siguiente manera:

Haz clic derecho sobre tu código.
Luego, haz clic en Format Document with...
Selecciona Prettier como tu formateador por defecto.

Ahora si, intenta salvar tu archivo y este debería de formatearse automáticamente.

Revisa tu configuración de VSCode

command + shift + p (mac os) | windows + shift + p (windows)
Abre tu configuración JSON

Ahora, si estás intentando usar Prettier en JavaScript, busca tu configuración para JavaScript y asegúrate de tener defaultFormatter configurado como el formateador de Prettier, y también formatOnSave configurado como true para que pueda formatearse al guardar.

Si quieres detalles más claros, la extensión de Prettier tiene una configuración más detallada también.

En caso de que desees otra configuración para otro lenguaje o alguna configuración extra, la puedes encontrar en su documentación.

Extension que te puede salvar de enviar código mal formateado a tus PRs

Te recomiendo encarecidamente la extensión Error Lens. Con esta extensión, tendrás una visualización de los errores directamente en tu editor, lo que te permitirá solucionarlos antes de enviar tus commits. Es una forma más fácil de identificar qué puede estar causando los errores y abordarlos de manera proactiva.

En Conclusión: Vive Feliz, Codifica Feliz

Y así, descubrimos lo cool que puede llegar a ser Prettier para poner fin a los interminables disputas sobre el formato del código. Ahora nos podemos enfocar en lo que realmente importa: crear software increíble sin perder tiempo en detalles tediosos.

Entonces, la próxima vez que te encuentres en medio de debates sobre la indentación y los puntos y comas, recuerda que existe Prettier. Tu mente (y tus colaboradores) te lo agradecerán. 😊

En caso que quieras integrarlo con ESLint te dejo un video excelente donde se explica la integración paso a paso:

https://www.youtube.com/live/EEDRcolSHms?si=Aw48p9sJ_A8bHRkn

Understanding State Management in React: Avoiding Pitfalls with Custom Hooks

Geovany — Sat, 17 Feb 2024 20:04:49 +0000

Hi Devs 👋 (@mgeovany on GitHub ) I'm immersed in the world of fintech startups, working on an exciting mobile app project using React Native. Along the way, I've realized the importance of documenting my development journey. Sharing insights and solutions not only helps junior developers but also deepens my understanding and advances my career.

Feel free to drop any comments or suggestions below. 🚀

Introduction

As junior developers, one of the common stumbling blocks we encounter in React development is managing state effectively, particularly when it comes to sharing state between components. In this blog post, we'll delve into a common issue faced by many developers and explore a solution that not only fixes the problem but also provides valuable insights into proper state management in React.

Identifying the Problem:

Imagine you're working on a React application where you have a main component rendering different parts of the UI based on certain conditions. You also have a custom hook responsible for managing some state outside of the main component. Additionally, you have another component, let's call it EmailVerification, which is conditionally rendered within the main component. This EmailVerification component contains a button that should update the state managed by the custom hook. However, despite updating the state, the UI does not reflect the changes as expected.
So we will have something like this:

App.tsx

export const App = () => {
  const { emailVerified, checkEmailVerified } = useEmailVerification();

  return (
    <div>
      {emailVerified && <div>Start contract</div>}
      {!emailVerified && (
        <EmailVerification />
      )}
    </div>
  );
};

EmailVerification.tsx

export const EmailVerification = () => {

  const { checkEmailVerified } = useEmailVerification();

  return <button onClick={checkEmailVerified}>Refresh</button>;
};

useEmailVerification.ts

export const useEmailVerification = () => {
  const [emailVerified, setEmailVerified] = useState<boolean>(false);

  const checkEmailVerified = () => {

    // here we would have the logic to handle the email verification
    const userEmailVerified = true;

    setEmailVerified(userEmailVerified);
  };

  return { emailVerified, checkEmailVerified };
};

Understanding the Issue:

The root cause of this problem lies in the fact that multiple instances of the custom hook are being used independently in different components. Each instance maintains its own state, which leads to inconsistencies when updating the state in one component but expecting changes to reflect in another.

When you create a custom hook, you're essentially encapsulating stateful logic within it. When this hook is called within a component, React creates a separate instance of the state associated with that hook for each component instance that uses it. This means that each component instance that uses the custom hook will have its own isolated state, independent of other component instances.

This behavior is crucial for ensuring that each component maintains its own internal state and does not interfere with the state of other components. It's a fundamental principle of React's component-based architecture, where components are designed to be self-contained and modular.

The Solution:

To address this issue, we need to ensure that both components share the same state. One approach is to lift the state up to a common parent component and pass down the state and its update function as props to the child components. By doing so, we establish a single source of truth for the state, ensuring consistency across the application.

Implementing the Solution:

In our case, we refactored the code to remove the instances of the custom hook from the EmailVerification component and instead passed down the state and its update function from the main component. This allowed both components to share the same state, ensuring that updates in one component are reflected in the other.

So the new version of the code will look like this:

App.tsx

export const App = () => {

  // Custom hook called on the parent component and passed as props to EmailVerification
  const { emailVerified, checkEmailVerified } = useEmailVerification();

  return (
    <div>
      {emailVerified && <div>Start contract</div>}
      {!emailVerified && (
        <EmailVerification
          emailVerified={emailVerified}
          checkEmailVerified={checkEmailVerified}
        />
      )}
    </div>
  );
};

EmailVerification.tsx

export const EmailVerification = ({ emailVerified, checkEmailVerified }) => {
  // No new instances of the custom hook
  const handleContinueButton = async () => {
    checkEmailVerified();
    if (emailVerified) {
      console.log('email verified', emailVerified);
    }
  };

  return <button onClick={handleContinueButton}>Refresh</button>;
};

Conlusion:

Initially, I assumed that understanding how each instance of a custom hook maintains its own state was pretty straightforward in React. But as I delved deeper, I discovered that even seasoned developers might overlook this behavior, leading to misconceptions about shared state.

It's fascinating to see that React's documentation dedicates a special section to this topic, emphasizing its importance.

References:

React Documentation: https://react.dev/learn/reusing-logic-with-custom-hooks#custom-hooks-let-you-share-stateful-logic-not-state-itself