DEV Community: Josué Oroya

¿Estás aplicando un anti-patrón de arquitectura en el Frontend?

Josué Oroya — Wed, 07 Jan 2026 18:54:16 +0000

Al iniciar un proyecto tanto en el Frontend como en el Backend, generalmente definimos muchos aspectos de nuestro software de acuerdo a los requerimientos que se nos piden. Sin embargo, con el tiempo el proyecto crece y se vuelve más complejo, y es aquí donde pueden aparecer los anti-patrones de arquitectura. En este artículo veremos algunos puntos que pueden diagnosticar que estamos aplicando un anti-patrón de arquitectura en el Frontend sin saberlo, y lo más importante: cómo solucionarlos.

¿Qué es y por qué es importante la arquitectura en el Frontend?

Antes que nada, me gustaría definir un poco acerca de lo que significa arquitectura en el desarrollo de software. Si eres nuevo en el mundo de la programación, es posible que hayas escuchado este término pero no sepas exactamente a qué se refiere.

Arquitectura de software es la estructura de alto nivel de un sistema de software, la disciplina de crear tales estructuras, y la documentación de estas estructuras. — Software Architecture in Practice, Bass et al.

En palabras simples, una arquitectura en el desarrollo de software es la estructura que define cómo se organizarán los diferentes componentes de un sistema y cómo interactuarán entre sí. Además, la arquitectura define las reglas y los principios que guiarán el desarrollo del software.

Una buena arquitectura es fundamental para aplicar y mantener un buen flujo de trabajo para todos los desarrolladores implicados en el proyecto, así como también facilita que nuevos equipos o miembros se sumen al proyecto sin mayores problemas. Además, una correcta arquitectura hace que la base de código sea más mantenible, escalable y testeable. En pocas palabras, incrementa la calidad del software y la productividad de los equipos de desarrollo.

Los pilares de una buena arquitectura Frontend

Para entender mejor qué hace que una arquitectura sea "buena", veamos sus pilares fundamentales:

Pilar	Descripción	Ejemplo práctico
Separación de responsabilidades	Cada módulo tiene una única responsabilidad	Componentes UI separados de la lógica de negocio
Bajo acoplamiento	Los módulos dependen lo menos posible entre sí	Usar interfaces y abstracciones
Alta cohesión	Elementos relacionados están agrupados	Features o dominios bien definidos
Escalabilidad	El sistema puede crecer sin reestructuración mayor	Arquitectura modular
Testeabilidad	Facilidad para escribir y ejecutar tests	Dependencias inyectables

Del otro lado del río: los anti-patrones de arquitectura

Luego de la breve explicación acerca de aplicar una buena arquitectura en el Frontend, es importante hacer una contraposición con los anti-patrones de arquitectura.

Un anti-patrón es una respuesta común a un problema recurrente que es usualmente inefectiva y tiene el riesgo de ser altamente contraproducente. — AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

Para entender mejor el concepto, aplicaremos una hipótesis con su respectiva contra-hipótesis:

Hipótesis: "Una buena arquitectura mantiene un buen flujo de trabajo para todo el equipo de desarrollo".
Contra-hipótesis: "Un anti-patrón de arquitectura puede generar un mal flujo de trabajo para todo el equipo de desarrollo".
Hipótesis: "Una buena arquitectura facilita la incorporación de nuevos miembros al equipo de desarrollo".
Contra-hipótesis: "Un anti-patrón de arquitectura puede dificultar la incorporación de nuevos miembros al equipo de desarrollo".
Hipótesis: "Una buena arquitectura hace que la base de código sea más mantenible, escalable y testeable".
Contra-hipótesis: "Un anti-patrón de arquitectura puede hacer que la base de código sea menos mantenible, escalable y testeable".
Hipótesis: "Una buena arquitectura incrementa la calidad del software y la productividad de los equipos de desarrollo".
Contra-hipótesis: "Un anti-patrón de arquitectura puede disminuir la calidad del software y la productividad de los equipos de desarrollo".

Sinceramente, la primera vez que me planteé estos puntos, quedé sorprendido por lo mal que se oyen las contra-hipótesis. Sin embargo, es importante tener en cuenta que los anti-patrones de arquitectura pueden aparecer en cualquier proyecto sin que nos demos cuenta. Por eso, es importante estar atentos a ciertos puntos que pueden diagnosticar que estamos aplicando un anti-patrón de arquitectura en el Frontend.

¿Estás aplicando un anti-patrón de arquitectura en el Frontend?

Los anti-patrones de arquitectura no son algo que se aplique de manera intencional, sin embargo, ningún proyecto está exento de ellos. A continuación, veremos los anti-patrones más comunes en el desarrollo Frontend y cómo identificarlos:

1. El "Spaghetti Code" o la Gran Bola de Lodo (Big Ball of Mud)

Este es probablemente el anti-patrón más común y peligroso. Se caracteriza por una falta total de estructura visible, donde el código crece de manera orgánica y desordenada.

Síntomas:

No existe una separación clara de capas
Componentes con múltiples responsabilidades (más de 500 líneas)
Dependencias circulares entre módulos
Dificultad para encontrar dónde está la lógica de una funcionalidad
Los cambios en un lugar rompen funcionalidades en otros lugares

Solución:

2. El Componente Dios (God Component)

Un componente que hace demasiadas cosas: maneja estado, hace llamadas a APIs, contiene lógica de negocio, y renderiza UI compleja.

Ejemplo de un God Component (Mal):

// UserDashboard.jsx - 800+ líneas
function UserDashboard() {
  const [user, setUser] = useState(null);
  const [orders, setOrders] = useState([]);
  const [notifications, setNotifications] = useState([]);
  const [settings, setSettings] = useState({});
  const [isLoading, setIsLoading] = useState(true);
  // ... 50 más estados

  useEffect(() => {
    // Fetch user, orders, notifications, settings...
    // Lógica de transformación de datos
    // Manejo de errores
    // WebSocket connections
  }, [/* muchas dependencias */]);

  const handleUpdateProfile = async () => { /* ... */ };
  const handleDeleteOrder = async () => { /* ... */ };
  const handleMarkNotificationRead = async () => { /* ... */ };
  // ... 30 más handlers

  return (
    // 500+ líneas de JSX
  );
}

Solución - Composición y separación:

3. Acoplamiento Excesivo (Tight Coupling)

Cuando los componentes o módulos dependen demasiado de la implementación interna de otros, cualquier cambio se convierte en una pesadilla.

Síntomas:

Cambiar un componente requiere modificar muchos otros
Los tests requieren mockear muchas dependencias
Componentes importan directamente de rutas profundas de otros módulos
Props drilling excesivo (pasar props a través de 5+ niveles)

Solución - Inversión de dependencias:

4. La Carpeta "Utils" o "Helpers" Infinita

Una carpeta que se convierte en el cajón de sastre donde va todo lo que "no sabemos dónde poner".

Estructura problemática (Mal):

src/
├── utils/
│   ├── helpers.js          # 2000 líneas
│   ├── functions.js        # 1500 líneas
│   ├── misc.js             # ???
│   ├── common.js           # Más de lo mismo
│   └── index.js            # Re-exporta todo

Solución - Organización por dominio:

5. El Estado Global Descontrolado (Global State Soup)

Usar estado global para todo, incluso para estado que debería ser local.

Síntomas:

El store global tiene cientos de propiedades
Estado de formularios en Redux/Zustand
Valores temporales o de UI en estado global
Dificultad para rastrear qué modifica qué
Re-renders innecesarios en toda la aplicación

Solución - Separación de responsabilidades de estado:

6. La Abstracción Prematura (Premature Abstraction)

Crear abstracciones complejas antes de que sean necesarias, "por si acaso". Este es un error común cuando se intenta aplicar patrones de diseño sin una necesidad real, muchas veces motivado por:

Haber leído recientemente sobre un patrón de diseño y querer aplicarlo
Miedo a tener que refactorizar en el futuro
Presión por escribir código "profesional" o "escalable"
No distinguir entre complejidad esencial y complejidad accidental

Debo reconocer que he caído en este anti-patrón en varias ocasiones cuando aún tenía poca experiencia en desarrollo de software. En algún momento de mi carrera, me di cuenta que con algunas preguntas simples podía evitar caer en este anti-patrón:

Pregunta	Si la respuesta es NO...
¿Realmente necesito esta abstracción ahora?	Espera a tener el caso de uso real
¿Estoy resolviendo un problema real o uno hipotético?	No resuelvas problemas que no existen
¿Esta abstracción añade valor o solo complejidad?	Mantén la solución simple
¿Puedo implementar esto de manera más simple primero?	Hazlo simple y refactoriza después

La Regla del Tres

Un principio útil para decidir cuándo abstraer es la Regla del Tres:

Ejemplo: Sobre-ingeniería vs. Solución pragmática

Mal - Sobre-ingeniería para un simple botón:

// 8 archivos, 200+ líneas para... un botón
interface IButtonStrategy {
  execute(): void;
}

interface IButtonProps {
  strategy: IButtonStrategy;
  builder: IButtonBuilder;
}

class SubmitButtonStrategy implements IButtonStrategy {
  constructor(private validator: IFormValidator) {}
  execute(): void { /* ... */ }
}

class CancelButtonStrategy implements IButtonStrategy { /* ... */ }
class ButtonStrategyFactory { /* ... */ }
class ButtonBuilder implements IButtonBuilder { /* ... */ }
class AbstractButton extends BaseComponent { /* ... */ }

// Para al final renderizar:
// <button onClick={strategy.execute}>Submit</button>

Bien - Solución simple que resuelve el problema real:

// Un componente, ~30 líneas
interface ButtonProps {
  variant: 'submit' | 'cancel' | 'default';
  onClick: () => void;
  children: React.ReactNode;
  disabled?: boolean;
}

function Button({ variant, onClick, children, disabled }: ButtonProps) {
  const styles = {
    submit: 'bg-blue-500 text-white',
    cancel: 'bg-gray-200 text-gray-700',
    default: 'bg-white border border-gray-300',
  };

  return (
    <button 
      className={styles[variant]} 
      onClick={onClick}
      disabled={disabled}
    >
      {children}
    </button>
  );
}

Principios a seguir

"Make it work, make it right, make it fast" — Kent Beck

"Duplication is far cheaper than the wrong abstraction" — Sandi Metz

La clave está en encontrar el equilibrio: ni sobre-ingeniería ni código duplicado sin sentido. La abstracción correcta emerge cuando tienes suficiente contexto sobre el problema real.

7. El Copy-Paste Driven Development

Copiar y pegar código en lugar de crear abstracciones reutilizables cuando SÍ son necesarias.

Síntomas:

Múltiples componentes con código casi idéntico
Cambios que requieren modificar muchos archivos
Bugs que se arreglan en un lugar pero persisten en otros

Checklist de diagnóstico

Utiliza esta checklist para evaluar tu proyecto:

Pregunta	Bien	Problema
¿Un nuevo desarrollador puede entender la estructura en < 1 hora?	Sí	No
¿Puedes añadir una feature sin modificar código existente?	Sí	No
¿Los componentes tienen < 200 líneas de código?	Mayoría	Pocos
¿Existe documentación de la arquitectura?	Sí	No
¿Los tests son fáciles de escribir?	Sí	No
¿El estado global tiene < 20 propiedades?	Sí	No
¿Las carpetas utils tienen < 10 archivos?	Sí	No

El camino hacia una mejor arquitectura

Si identificaste varios de estos anti-patrones en tu proyecto, no te preocupes. La refactorización es un proceso gradual.

Recomendaciones finales

Documenta tu arquitectura: Usa ADRs (Architecture Decision Records) para registrar el "por qué" de las decisiones.
Establece convenciones: Define una estructura de carpetas clara y consistente.
Revisa el código en equipo: Los code reviews ayudan a detectar anti-patrones temprano.
Mide y monitorea: Usa herramientas como SonarQube, ESLint con reglas de complejidad, y métricas de cobertura.
Aprende de otros: Estudia arquitecturas probadas como Feature-Sliced Design, Atomic Design, o Clean Architecture adaptada a Frontend.

Conclusión

Los anti-patrones de arquitectura son como la deuda técnica silenciosa: no los notamos hasta que el proyecto se vuelve difícil de mantener. La clave está en:

Detectar temprano: Revisa regularmente la salud de tu código
Aprender continuamente: Estudia patrones de arquitectura
Comunicar con el equipo: Las decisiones de arquitectura son decisiones de equipo
Balancear: Ni sobre-ingeniería ni código espagueti

¿Has identificado alguno de estos anti-patrones en tus proyectos? ¡Comparte tu experiencia en los comentarios!

Referencias:

Clean Architecture - Robert C. Martin
Patterns of Enterprise Application Architecture - Martin Fowler
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis - Brown et al.

¿Te gustó este artículo? Sígueme para más contenido sobre arquitectura Frontend y buenas prácticas de desarrollo.

El propósito del Testing

Josué Oroya — Thu, 06 Nov 2025 12:14:33 +0000

En ingeniería de software, todo programa funciona… hasta que deja de hacerlo.

Y cuando lo hace, rara vez avisa.

El testing no existe para demostrar que algo “anda bien”, sino para entender bajo qué condiciones deja de hacerlo.

Es una práctica que revela lo que el entusiasmo del desarrollo suele ocultar: las grietas invisibles en nuestras suposiciones.

El costo real de los errores en producción

Corregir un bug nunca cuesta lo mismo. Según el NIST (National Institute of Standards and Technology), el precio de un error se multiplica a medida que avanza el ciclo de desarrollo:

Etapa	Costo relativo
Diseño	1x
Codificación	5x
Testing	10x
Producción	30x a 100x

Esto no es teoría: es matemática empresarial.

En 2020, el Consortium for IT Software Quality (CISQ) estimó que el costo de software defectuoso para la economía estadounidense fue de $2.08 trillones.

No es que “los bugs cuesten caro”, es que las decisiones sin testing salen carísimas.

Errores que resultaron muy costosos

Knight Capital Group (2012)

Un despliegue incompleto activó código obsoleto y generó pérdidas de $440 millones en 45 minutos.

Una empresa entera colapsó por un flag mal configurado.
Ariane 5 (1996)

Un overflow al convertir un número de 64 bits a 16 provocó la explosión de un cohete valuado en $370 millones.

El código “reutilizado” de Ariane 4 jamás fue testeado bajo las nuevas condiciones.
Therac-25 (1985–1987)

Una máquina de radioterapia administró dosis letales debido a errores de concurrencia.

Seis personas murieron. No por hardware, sino por software no validado.
Toyota (2010)

Un fallo de software en el sistema de aceleración llevó al retiro de 9 millones de vehículos.

Investigaciones posteriores revelaron race conditions y fallos en la gestión de memoria.

El verdadero enemigo: lo que no se ve

En mi experiencia trabajando con equipos distribuidos y productos en producción, aprendí que los peores errores no son los que hacen explotar todo de inmediato.

Son los que parecen inofensivos:

los que corrompen datos lentamente, los que rompen un flujo solo en ciertas condiciones, los que hacen que algo “a veces no funcione”.

Esos son los que degradan la experiencia del usuario y erosionan la confianza en el producto.

Y cuando la confianza se pierde, ni mil tests la recuperan.

Por eso, el testing no es solo un mecanismo técnico:

es la forma en que hacemos visibles las fallas invisibles antes de que lo hagan nuestros usuarios.

El propósito fundamental: gestionar el riesgo

Cada prueba, cada mock, cada test end-to-end tiene un mismo fin: reducir el riesgo.

No testeamos por costumbre ni por obligación, sino porque el software vive en entornos impredecibles:

Los usuarios siempre encuentran combinaciones que nadie anticipó.
Las redes fallan justo en el peor momento.
Los servicios externos cambian sin avisar.
Los requisitos evolucionan mientras el sprint aún está en curso.

Testing no es buscar errores: es mapear la incertidumbre.

Es una forma de humildad profesional —reconocer que el código no es infalible y que las buenas intenciones no previenen bugs.

Testing en el mundo web (mi mundo): la frontera entre frontend y backend

En el desarrollo web moderno, la línea entre frontend y backend se ha vuelto delgada.

Un error en el backend puede romper una vista entera, y una validación omitida en el frontend puede inyectar datos inválidos en la base.

Un frontend developer prueba la experiencia: flujos, formularios, accesibilidad, estados límite.

Un backend developer prueba la integridad: transacciones, respuestas, consistencia de datos y resiliencia ante errores externos.

Ambos están del mismo lado: el de quienes quieren dormir tranquilos después del deploy un viernes por la tarde (Por favor, no despliegues un día así).

Una cultura, no una fase

Testing no debería ser un paso al final del sprint, sino una forma de pensar durante todo el desarrollo.

Diseñar código testeable es diseñar código legible, mantenible y confiable.

Automatizar tests no es burocracia: es seguridad futura.

Adoptar una cultura de testing no solo mejora la calidad técnica, sino también la comunicación entre equipos, la velocidad de entrega y, sobre todo, la confianza en el proceso.

Sinceramente, reconozco buenos equipos y buenos líderes cuando al mencionar estimar tests, le dan la prioridad que debe tener.

Epílogo: el tester invisible

El testing no es el 10 de las entregas. No brilla en las demos ni figura en las métricas.

Pero es la base silenciosa sobre la que se sostiene todo lo demás.
Creo que todos hemos trabajado en proyectos que en algún momento se vuelven tan grandes que cualquier mínimo cambio rompe la aplicación, pero coincidentemente, los equipos que aplican un proceso serio de testing pocas veces tienen estos problemas.

Cada vez que un usuario confía, que una API responde bien, que un sistema escala sin romperse,

hay una línea de test que lo permitió.

La AI es perezosa y eso no está mal

Josué Oroya — Mon, 09 Jun 2025 20:10:00 +0000

Hace tiempo que venimos integrando herramientas de inteligencia artificial en nuestro flujo de trabajo diario. Desde ChatGPT hasta modelos más especializados, la AI ha demostrado ser una aliada poderosa para mejorar nuestra productividad y eficiencia. Sin embargo, hay un aspecto que rara vez se menciona: la AI es perezosa por naturaleza. Y eso, lejos de ser un defecto, puede ser una virtud.

Un caso real: cuando la pereza se hizo evidente

En uno de mis proyectos de desarrollo, decidí automatizar la creación de archivos .json de gran volumen, que normalmente se llenaban a mano. La idea era simple: pedirle a ChatGPT (versión 4o) que generara un archivo con una estructura específica y, a partir de ahí, completar los datos necesarios.

Todo iba bien, hasta que noté que la AI no podía generar el archivo completo de una sola vez. En cambio, me entregaba fragmentos que yo debía ensamblar. Por suerte, conocía bien el proyecto y el lenguaje, así que completar el rompecabezas no fue un problema.

Días después, el modelo de datos cambió. Eso implicó actualizar decenas de archivos .interface.ts y .json. Como eran tareas de alta carga y baja complejidad, decidí delegarlas en un Agente AI con prompts bien definidos. Pero, al revisar los resultados, noté algo inquietante: se habían eliminado funciones importantes de mi store con Zustand, funciones que no debían tocarse.

Y ahí entendí el patrón: la AI había tomado atajos. No por maldad, sino porque su diseño la empuja a ser eficiente a cualquier costo. Incluso si eso significa borrar lo que cree innecesario.

Reflexión: ¿defecto o característica?

Lo admito, me enojé. Había confiado en la AI para encargarse de tareas tediosas, y terminé corrigiendo errores evitables. Pero, al analizarlo en frío, me di cuenta de algo importante: la pereza de la AI no es un bug. Es una feature.

La pereza como virtud

La AI está diseñada para optimizar. No busca hacer las cosas bien, sino hacerlas lo suficientemente bien con el menor esfuerzo posible. En vez de recorrer un camino largo y detallado, elige atajos.

Y, si lo pensás, no está tan lejos del mindset de los programadores: evitar el trabajo innecesario, automatizar lo repetitivo, y buscar soluciones simples a problemas complejos. La AI, en esencia, es un programador perezoso con esteroides.

¿Qué significa “pereza” en términos técnicos?

Muchos modelos de AI (y frameworks de programación) aplican un principio conocido como evaluación perezosa (lazy evaluation). En pocas palabras, no se hace nada hasta que realmente se necesita. Esto ahorra recursos y tiempo, pero también puede hacer que algunas cosas se pasen por alto si no se supervisa bien.

La importancia de la supervisión humana

La AI es útil, pero no infalible. Su tendencia a cortar camino puede llevar a errores sutiles pero importantes. Por eso, la supervisión humana no es opcional.

En mi caso, revisar cuidadosamente el código generado me permitió detectar y corregir omisiones antes de que se transformaran en bugs difíciles de rastrear.

La combinación de la eficiencia de la AI y la mirada crítica del desarrollador es lo que realmente genera resultados potentes. La AI no reemplaza al humano, lo potencia. Pero solo si el humano sigue prestando atención.

En resumen

La AI es perezosa. Y eso no está mal. Porque su pereza, bien entendida, es sinónimo de eficiencia. Pero si queremos que sea una aliada y no una saboteadora silenciosa, necesitamos estar atentos. La supervisión no es una carga: es el complemento natural de esta nueva manera de trabajar.

¿La AI se salta pasos? A veces sí.

¿Nos obliga a revisar? Siempre.

¿Vale la pena usarla igual? Sin dudas.

Reflexión final

Hay un pasaje citado en Eloquent JavaScript que me marcó mucho y que suelo repetir en mis clases. Es de Ellen Ullman, y dice:

“Creemos que estamos haciendo la computadora a nuestra imagen… pero no lo estamos. La computadora no es realmente como nosotros. Es una proyección de una parte muy delgada de nosotros mismos: esa porción dedicada a la lógica, el orden, las reglas y la claridad.”

Hoy, cuando reflexiono sobre la “pereza” de la inteligencia artificial, estas palabras cobran aún más fuerza. Lo que llamamos “pereza” en los modelos de AI no es más que una versión amplificada de esa parte del ser humano que intenta optimizar, que busca orden, que elimina lo que considera innecesario para lograr un objetivo con el menor esfuerzo posible.

La AI no es perezosa por descuido. Es perezosa porque está diseñada a imagen y semejanza de nuestra forma más lógica y resolutiva. Porque incluso nosotros, al programar, buscamos siempre esa línea de código menos, ese algoritmo más eficiente, ese truco que nos ahorra tiempo.

La AI no es un espejo completo de la humanidad. Es un espejo afilado de nuestra lógica. Y nuestra lógica, a veces, también prefiere atajos.

Qué es el principio de incertidumbre de un estado en React

Josué Oroya — Wed, 16 Apr 2025 03:03:15 +0000

Principio de incertidumbre de un estado en React

Si has trabajado con React, es probable que hayas tenido problemas con los estados de tus componentes. En este artículo veremos como enfrentar este problema y las distinas formas de solucionarlo.

Hace poco estuve ayudando a un colega con un problema en su aplicación de React. Estaba trabajando con un componente que debía reproducir un video y pausar la reproducción en un segundo determinado. Al principio uno puede pensar que es un problema sencillo, es decir, tienes un simple estado booleano que indica si el video está en reproducción o no. Sin embargo, luego de probar la aplicación, se dió cuenta que en ocasiones el video no volvía a reproducirse por más lógica que le añadiera, incluso GPT le decía que estaba bien, o añadía más lógica y el problema persistía. Entonces, ¿qué estaba pasando? ¿Por qué no podía hacer que su video se reprodujera nuevamente?

En ese momento dijo una frase que me hizo pensar:

"Lo ideal sería que mi componente funcione o no funcione, pero... ¡funciona a veces y a veces no!

Esto me hizo reflexionar, ya que es verdad, cuando desarrollamos componentes que responden a un estado para definir su comportamiento, pero estos terminan teniendo un comportamiento errático, tendemos a pensar que se trata de un bug pero no diagnosticamos el problema correctamente.

Si tu código funciona unas veces y otras no, y esto depende de un estado, entonces podemos decir que el estado se encuentra en un (valga la redundancia) estado de incertidumbre. Esto es lo que yo llamo el principio de incertidumbre de un estado en React.

Ok, quiza esto suene un poco raro, o tan solo pienses que se trata de un bug y ya. Pero ser concientes de que el problema tiene que ver con que el estado se encuentra en un estado de incertidumbre, nos puede ayudar a encontrar la solución.

Principio de incertidumbre de un estado en React

Cuando un componente React se comporta de manera aleatoria ante cambios de estado —funciona a veces y a veces no— estamos frente a un estado en incertidumbre.

Este principio no habla de física cuántica ni del funcionamiento interno de React, sino del momento exacto en que un desarrollador siente que todo está bien en su código, pero el comportamiento no es consistente.

No hay errores visibles, no hay excepciones, y hasta la lógica parece sólida. Pero sin embargo… el componente falla, y lo hace de forma errática. Reproduce un video unas veces sí y otras no. Cambia una clase CSS a veces sí, otras no. La actualización de un booleano simplemente no sucede o si sucede, no se refleja en la UI.

¿Por qué sucede esto?

Ahora que hemos diagnosticado que el problema tiene que ver con un estado en incertidumbre, es hora de ver por qué sucede esto.

1. El estado no se actualiza

El primer problema que puede suceder es que el estado no se actualiza. Esto puede suceder por varias razones, pero la más común es que el estado no se actualiza de forma síncrona. Esto significa que cuando llamas a setState, el nuevo valor del estado no está disponible inmediatamente. En su lugar, React programa una actualización del estado y lo actualiza en un momento posterior. Este es un error muy común sobre todo en principiantes, ya que piensan que el estado se actualiza inmediatamente y no es así.

Ejemplo

const [isPlaying, setIsPlaying] = useState(false);

const handlePlay = () => {
  setIsPlaying(true);
  console.log("¿Está reproduciendo?", isPlaying); // ❌ Siempre muestra: false
};
const handlePause = () => {
  setIsPlaying(false);
  console.log("¿Está reproduciendo?", isPlaying); // ❌ Siempre muestra: true
};

En este ejemplo, el estado isPlaying no se actualiza inmediatamente después de llamar a setIsPlaying. Por lo tanto, cuando intentamos acceder al valor del estado inmediatamente después de actualizarlo, siempre obtendremos el valor anterior.

Solución recomendada

La forma correcta de trabajar con el nuevo valor del estado es esperar a que React haga el render y reaccionar a los cambios con un useEffect:

useEffect(() => {
  if (isPlaying) {
    console.log("El video está en reproducción");
    // reproducirVideo(); ← tu lógica aquí
  }
}, [isPlaying]);

const handlePlay = () => {
  setIsPlaying(true);
};

Nota: Si necesitás hacer algo en el momento justo en que el estado cambia, no lo hagas inmediatamente después de setState. Usá useEffect para esperar a que el nuevo valor esté disponible tras el render.

2. Funciones externas que afectan al estado sin que te des cuenta

A veces no es el setState el que falla, sino una función externa que modifica el valor o el contexto del estado desde afuera, causando que el comportamiento se vuelva errático.

Esto puede pasar cuando:
• Tienes lógica compartida en servicios, utilidades o archivos separados.
• Usas referencias (ref) para acceder al DOM o a valores mutables.
• Tienes callbacks que se ejecutan desde fuera del flujo React (como eventos de terceros o listeners manuales).

Ejemplo

const [isVisible, setIsVisible] = useState(true);

externalController.onToggle(() => {
  setIsVisible(false); // ❗ Pero no sabés que esto se está llamando en otro archivo
});

El estado isVisible cambia “mágicamente”, y tu ni siquiera lo ves en tu componente.

Nota: Este es un error común en aplicaciones grandes, donde el estado se comparte entre varios componentes o servicios. Es importante tener cuidado al modificar el estado desde fuera del flujo de React. (Por cierto, este era el problema de mi colega, el video no se reproducía porque había un listener que lo pausaba desde otro archivo y no se daba cuenta).

Solución recomendada: Encapsular la lógica que modifica el estado

Si una función externa necesita modificar el estado, protege el acceso con una función explícita desde el componente, así controlas cuándo y cómo se cambia:

useEffect(() => {
  const handleToggle = () => {
    console.log("Ocultando componente desde controlador externo");
    setIsVisible(false);
  };

  externalController.onToggle(handleToggle);

  return () => {
    externalController.offToggle(handleToggle);
  };
}, []);

Nota: En este caso, el efecto se encarga de limpiar el listener cuando el componente se desmonta, evitando que el estado quede en un estado de incertidumbre.

Consejo práctico

Si sientes que “el estado cambia solo”, probablemente alguien lo está tocando desde afuera. Audita el código en busca de listeners, servicios o refs que puedan modificarlo por fuera del ciclo de React.

3. Estado sincronizado con props que nunca se actualiza

A veces inicializamos un estado en base a una prop, pero esperamos que ese estado se actualice automáticamente cuando la prop cambie… y no lo hace.

Esto pasa mucho cuando el desarrollador copia una prop en un useState y asume que estarán sincronizados para siempre. Spoiler: no lo estarán.

Ejemplo

const MyComponent = ({ initialValue }) => {
  const [value, setValue] = useState(initialValue);

  return <input value={value} onChange={(e) => setValue(e.target.value)} />;
};

Si initialValue cambia desde el componente padre, value no cambia, porque useState solo toma la prop una vez al inicio. Esto puede generar inconsistencias difíciles de detectar, especialmente cuando usas formularios, modales, o entradas controladas.

Solución recomendada: Sincronizar el estado con useEffect

const MyComponent = ({ initialValue }) => {
  const [value, setValue] = useState(initialValue);

  useEffect(() => {
    setValue(initialValue);
  }, [initialValue]);

  return <input value={value} onChange={(e) => setValue(e.target.value)} />;
};

Nota: En este caso, el efecto se encarga de sincronizar el estado con la prop inicial, asegurando que siempre tenga el valor correcto.

💡 Consejo práctico
Si estás copiando una prop en un state, preguntate:
“¿Esto debería seguir sincronizado o solo es un valor inicial?”
Si quieres que se mantengan sincronizados, necesitas controlarlo manualmente con useEffect.

Este tipo de errores se manifiestan como: “mi input no cambia aunque la prop cambió”, o “el modal no se actualiza cuando cambio los datos”, y pueden ser muy difíciles de diagnosticar si no conoces este patrón.

Conclusiones

Si has llegado hasta acá, antes que nada quiero agradecerte por dedicarme tu tiempo. Espero que este artículo te esté resultando útil.

El principio de incertidumbre de un estado en React no es solo una metáfora divertida —es una herramienta mental útil para diagnosticar esos casos donde “el componente funciona a veces y a veces no”.
Muchos de los errores más difíciles en React no se deben a código incorrecto, sino a expectativas incorrectas sobre cómo y cuándo React actualiza el estado.
Aceptar que el estado puede estar en incertidumbre —que no es inmediato, que puede estar desfasado, que otros efectos lo afectan— te permite salir del ciclo de frustración y pasar al modo detective 😎.

Consejo final

La incertidumbre no siempre es un bug. A veces es una señal de que hay una desincronización entre tu lógica y el ciclo de vida de React.

Configurando un proyecto de React para producción

Josué Oroya — Thu, 24 Oct 2024 21:36:28 +0000

Internet está lleno de tutoriales sobre cómo iniciar un proyecto web con React, sin embargo la mayoría de estos tutoriales son para proyectos pequeños o de prueba. En este tutorial, aprenderás cómo las empresas reales configuran sus proyectos de React para producción utilizando las mejores prácticas.

Requerimientos técnicos

Para seguir este artículo, necesitarás tener instalado las siguientes tecnologías:

Node.js V20.10.0 o superior
Git v2.43.0 o superior
Visual Studio Code v1.94.0 o superior
pnpm

Estas son las versiones que he utilizado para escribir este artículo, pero es posible que funcione con versiones anteriores no muy antiguas o superiores.

¿Por qué pnpm?

Quizás la típica frase que oirás decir a la mayoría de los desarrolladores que usamos pnpm es: "pnpm es más rápido que npm y yarn". Pero en mi experiencia trabajando en la industria, la razón más importante para usar pnpm es que este instala las dependencias de forma plana, lo que significa que no instala múltiples versiones de la misma dependencia. Esto ahorra espacio en disco y reduce el tiempo de instalación de las dependencias. Además, evita problemas de compatibilidad entre las dependencias.

Creando un nuevo proyecto con Vite

Vite es un nuevo bundler que ha ganado mucha popularidad en la comunidad de React. Vite es mucho más rápido que Create React App y es compatible con TypeScript de forma nativa. Para crear un nuevo proyecto con Vite, simplemente ejecuta el siguiente comando:

pnpm create vite

Veremos las siguientes opciones:

Project name: Nombre del proyecto, para este caso, el proyecto se llamará react-real-world.
Select a framework: Selecciona React.
Select a variant: Selecciona React con TypeScript.

Una vez que hayas seleccionado todas las opciones, Vite creará un nuevo proyecto de React con TypeScript.

Acto seguido, ejecuta los siguientes comandos para instalar las dependencias necesarias:

cd react-real-world
pnpm install

También abriremos el proyecto en Visual Studio Code:

code .

React con SWC o Babel

Vite es compatible con SWC y Babel. SWC es un compilador de JavaScript extremadamente rápido que es compatible con la mayoría de las características de Babel. Sin embargo, Babel es más popular y tiene una comunidad más grande.

En lineas generales, los parámetros más importantes para elegir entre SWC y Babel son:

Velocidad: SWC es mucho más rápido que Babel.
Compatibilidad: Babel es más compatible con las últimas características de JavaScript.
Comunidad: Babel tiene una comunidad más grande y es más popular.

Si tu aplicación será muy grande y compleja y necesitas una velocidad de compilación muy rápida en producción, te recomiendo que uses SWC. Si tu aplicación es pequeña o mediana y necesitas una compatibilidad máxima con las últimas características de JavaScript, te recomiendo que uses Babel.

En todo caso, sería mejor iniciar el proyecto con babel, osea no seleccionar SWC en la creación del proyecto, y luego cambiar a SWC si es necesario, los pasos para hacerlo son muy sencillos.

Configurando ESLint y Prettier con TypeScript para aplicar las mejores prácticas

Ahora que hemos creado nuestro proyecto de React con TypeScript, es hora de configurar ESLint y Prettier para aplicar las mejores prácticas de codificación. Para ello justificaremos ambas herramientas cuando las estemos configurando.

Antes que nada vamos a instalar las dependencias necesarias:

pnpm install --save-dev prettier eslint eslint-plugin-react eslint-config-prettier eslint-plugin-jsx-a11y @typescript-eslint/parser @typescript-eslint/eslint-plugin

Pnpm instalará lo siguiente:

prettier: Herramienta de formateo de código.
eslint: Herramienta de análisis de código.
eslint-plugin-react: Plugin de ESLint para React.
eslint-config-prettier: Desactiva las reglas de ESLint que pueden entrar en conflicto con Prettier.
eslint-plugin-jsx-a11y: Plugin de ESLint para accesibilidad en JSX.
@typescript-eslint/parser: Parser de TypeScript para ESLint.
@typescript-eslint/eslint-plugin: Plugin de ESLint para TypeScript.

El comando --save-dev instala las dependencias como dependencias de desarrollo, lo que significa que no se instalarán en producción. Esto es obligatorio ya que de lo contrario las dependencias se instalarán en producción y aumentarán el tamaño de la aplicación.

Configurando Prettier

Prettier es una herramienta de formateo de código que te permite formatear tu código automáticamente. La motivación detrás de Prettier es que no deberías perder tiempo formateando tu código manualmente, sino que deberías dejar que Prettier lo haga por ti automáticamente. De esta forma, todos los miembros del equipo de desarrollo seguirán el mismo estilo de codificación.

Para configurar Prettier, crearemos un archivo llamdo .prettierrc.json en la raíz del proyecto con el siguiente contenido:

{
  "trailingComma": "all",
  "tabWidth": 2,
  "printWidth": 80,
  "semi": false,
  "singleQuote": true,
  "jsxSingleQuote": true
}

Configurando la extensión de Prettier en Visual Studio Code

Para que Visual Studio Code formatee automáticamente tu código con Prettier, necesitas instalar la extensión de Prettier. Para ello, abre Visual Studio Code y busca la extensión de Prettier en el Marketplace. Una vez que la hayas instalado, Visual Studio Code formateará automáticamente tu código con Prettier cada vez que guardes un archivo.

Sin embargo, es necesario configurar Visual Studio Code para que use Prettier como formateador de código por defecto. Para ello, abre el archivo de configuración de Visual Studio Code escribiendo Ctrl + , si estás en Windows o Cmd + , si estás en macOS o con la ruta Archivo > Preferencias > Configuración para Windows o Code > Preferencias > Configuración para macOS.

Acontinuación, selecciona la pestaña Workspace o Área de trabajo y busca la configuración Format On Save. Asegúrate de que la casilla esté marcada.

Por último, busca la configuración Default Formatter y selecciona Prettier - Code formatter. Esto hará que Visual Studio Code añada una carpeta .vscode en la raíz del proyecto con un archivo settings.json que contiene la configuración de Prettier para el proyecto. De esa manera el equipo de desarrollo seguirá el mismo estilo de codificación.

.vscode/settings.json

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode"
}

Implementando el archivo `.prettierignore`

El archivo .prettierignore es un archivo que le dice a Prettier qué archivos o carpetas debe ignorar al formatear el código. Por ejemplo, si tienes archivos de configuración, archivos de prueba o incluso los de distribución que no quieres formatear, puedes añadirlos al archivo .prettierignore.

Crea un archivo llamado .prettierignore en la raíz del proyecto con el siguiente contenido:

# Ignorar la carpeta dist
dist/

# Ignorar build
build/

Por cierto, la carpeta node_modules/ está ignorada por defecto en Prettier, por lo que no es necesario añadirla al archivo .prettierignore.

Configurando ESLint

Si bien Prettier se encarga de formatear el código automáticamente, ESLint se encarga de analizar el código en busca de errores y malas prácticas. ESLint es una herramienta muy potente que te permite personalizar las reglas de codificación según tus necesidades, aunque sinceramente recomiendo usar un paquete de reglas ya existente como eslint-config-airbnb o eslint-config-standard ya que son en teoría convenciones de codificación que han sido probadas y son utilizadas por la comunidad.

Por defecto a la fecha Octubre 2024, Vite en su versión 5.4.9 crea un archivo llamado eslint.config.js con una configuración básica de ESLint. Sin embargo, vamos a modificarlo de la siguiente manera:

import js from '@eslint/js'
import tsEslint from '@typescript-eslint/eslint-plugin'
import tsParser from '@typescript-eslint/parser'
import prettierConfig from 'eslint-config-prettier'
import jsxA11y from 'eslint-plugin-jsx-a11y'
import reactHooks from 'eslint-plugin-react-hooks'
import reactRefresh from 'eslint-plugin-react-refresh'
import globals from 'globals'

export default [
  {
    ignores: ['dist', 'node_modules'], // Archivos y carpetas ignorados
    files: ['**/*.{ts,tsx,js,jsx}'], // Archivos a lint
    languageOptions: {
      ecmaVersion: 'latest', // Versión de ECMAScript más reciente
      sourceType: 'module', // Módulos ES
      globals: globals.browser, // Soporte para los globales del navegador
      parser: tsParser, // Parser para TypeScript
    },
    linterOptions: {
      reportUnusedDisableDirectives: true, // Detecta directivas deshabilitadas no usadas
    },
    plugins: {
      'react-hooks': reactHooks, // Plugin para React Hooks
      'react-refresh': reactRefresh, // Plugin para React Refresh
      '@typescript-eslint': tsEslint, // Plugin para TypeScript
      'jsx-a11y': jsxA11y, // Plugin para accesibilidad en JSX
    },
    rules: {
      ...js.configs.recommended.rules, // Reglas recomendadas de JavaScript
      ...tsEslint.configs.recommended.rules, // Reglas recomendadas de TypeScript
      ...reactHooks.configs.recommended.rules, // Reglas recomendadas de React Hooks
      'react-refresh/only-export-components': [
        'warn',
        { allowConstantExport: true },
      ],
      '@typescript-eslint/no-unused-vars': 'warn', // Advertencia para variables no usadas en TypeScript
      'jsx-a11y/no-static-element-interactions': 'warn', // Accesibilidad para interacciones de elementos estáticos
    },
  },
  prettierConfig, // Configuración de Prettier añadida directamente
]

La configuración propuesta es bastante sólida y sigue prácticas modernas para proyectos de React con TypeScript utilizando ESLint. Vamos a justificar algunas de las decisiones tomadas:

1. Uso de plugins

React Hooks y React Refresh: Estamos utilizando los plugins correctos para optimizar el comportamiento de React Hooks y asegurar la actualización rápida con React Refresh. Estos son esenciales para una experiencia de desarrollo rápida en entornos de React.
TypeScript: Usar @typescript-eslint/eslint-plugin junto con @typescript-eslint/parser es la forma correcta de integrar TypeScript en ESLint.
Accesibilidad (jsx-a11y): Incluir eslint-plugin-jsx-a11y es una excelente práctica para asegurar que tu aplicación React siga buenas prácticas de accesibilidad.

2. Soporte para Prettier

Incluir eslint-config-prettier al final del arreglo es lo correcto. Esto asegura que las reglas de estilo y formato de Prettier no entren en conflicto con las reglas de ESLint, permitiendo que Prettier maneje el formato del código y ESLint se centre en la calidad del código.

3. Ignorar archivos

ignores: ['dist', 'node_modules']: Este uso de ignores es correcto y moderno, ya que .eslintignore ha sido reemplazado por la propiedad ignores en las configuraciones planas.

4. Configuración de reglas

Recomendadas: Se ha configurado correctamente las reglas recomendadas de JavaScript, TypeScript y React Hooks.
Reglas personalizadas: Las reglas personalizadas como '@typescript-eslint/no-unused-vars': 'warn' están bien configuradas para evitar que las variables no usadas rompan la compilación, pero sigan mostrando advertencias. También, se añadió reglas para la accesibilidad ('jsx-a11y/no-static-element-interactions': 'warn') es una excelente opción para garantizar que los componentes cumplan con los estándares de accesibilidad.

Probando la configuración de ESLint y Prettier

Para probar la configuración de ESLint y Prettier, bastará con ejecutar el siguiente comando:

ESLint

pnpm eslint './src/**/*.{ts,tsx,js,jsx}' --fix

Prettier

pnpm prettier --write .

Si todo está configurado correctamente, ESLint y Prettier formatearán y analizarán tu código sin errores. Si hay errores, ESLint y Prettier te mostrarán mensajes de error en la consola y te indicarán cómo solucionarlos.

Añadiendo scripts de ESLint y Prettier al `package.json`

Para facilitar el uso de ESLint y Prettier, añadiremos scripts al archivo package.json que nos permitirán ejecutar ESLint y Prettier con un solo comando.

{
  "scripts": {
    "lint": "pnpm eslint './src/**/*.{ts,tsx,js,jsx}' --fix",
    "format": "pnpm prettier --write ."
  }
}

Después de añadir los scripts, ahora tenemos que asegurarnos de que estos se ejecuten antes de crear un commit que sería el paso previo a enviar el código a nuestro repositorio remoto y posteriormente a producción. Para ello, vamos a instalar la dependencia husky que nos permitirá ejecutar scripts antes de realizar un commit.

Configurando Husky para ejecutar ESLint y Prettier antes de hacer un commit

Husky es una herramienta que te permite ejecutar scripts antes de realizar un commit en Git. Esto es útil para asegurarte de que tu código cumple con las reglas de ESLint y Prettier antes de enviarlo a tu repositorio remoto.

Para evitar accidentes, podemos configurar Husky y lint-staged, que se ejecutan antes de confirmar nuestro código en Git y garantizan que Prettier y ESLint se ejecuten correctamente en el código fuente antes de confirmarlo.

Inicializar git en el proyecto

Ya que estamos usando Vite, este bundle no inicializa un repositorio git por defecto, por lo que debemos hacerlo manualmente. Para ello, ejecuta el siguiente comando:

git init

Instalar Husky y lint-staged

Vamos a instalar las dependencias necesarias:

pnpm install --save-dev husky lint-staged

Configurar Husky y lint-staged

Abre el archivo package.json y añade las siguientes configuraciones:

{
  "lint-staged": {
    "*.ts": ["eslint --fix", "prettier --write"],
    "*.tsx": ["eslint --fix", "prettier --write"]
  }
}

Esta configuración le dice a lint-staged que ejecute ESLint y Prettier en los archivos .ts y .tsx antes de confirmarlos en Git.

Nota: Como puedes ver, estamos separando los archivos .ts y .tsx para darle más flexibilidad y granularidad a la configuración. Puedes añadir más extensiones de archivos si lo necesitas. Esto nos permitirá la posibilidad de aplicar reglas específicas y diferentes para cada tipo de archivo. Sin embargo, si deseas aplicar las mismas reglas a todos los archivos, puedes usar *.{ts,tsx}.

Inicializar Husky

Para inicializar Husky, ejecuta el siguiente comando:

pnpm exec husky init

Nota: el comando pnpm exec ejecuta un comando en el contexto de un paquete, en este caso, husky. Puedes consultar los comandos disponibles en la documentación oficial de Husky si estás usando npm o yarn.

El comando anterior creará un archivo llamado .husky/pre-commit en la raíz del proyecto con el siguiente contenido:

pnpm test

Este comando ejecutará los tests antes de confirmar el código en Git. Sin embargo, vamos a modificarlo para que ejecute ESLint y Prettier en su lugar.

Modificar el archivo `.husky/pre-commit`

Abre el archivo .husky/pre-commit y modifícalo de la siguiente manera:

npx lint-staged

Este script ejecutará lint-staged antes de confirmar el código en Git. lint-staged ejecutará ESLint y Prettier en los archivos .ts y .tsx antes de confirmarlos.

Asegurarse de que Husky se instale cuando se clone el repositorio

Ya que es probable que en un proyecto real se clone el repositorio en diferentes máquinas, es importante que Husky se instale automáticamente en cada máquina. Para ello, añade el siguiente script al archivo package.json:

{
  "scripts": {
    "prepare": "husky install"
  }
}

Bonus: Configurando una convención de commits con Commitlint

Commitlint es una herramienta que te permite configurar una convención de commits en tu proyecto. Esto es útil para asegurarte de que todos los commits sigan un formato específico y sean fáciles de leer.

Instalar Commitlint

Vamos a instalar las dependencias necesarias:

pnpm add --save-dev @commitlint/{cli,config-conventional}

Luego crear un archivo llamado commitlint.config.js en la raíz del proyecto usando el siguiente comando:

echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

Esto creará un archivo commitlint.config.js con la configuración de Commitlint con el siguiente contenido:

export default { extends: ['@commitlint/config-conventional'] }

Configurar Husky para ejecutar Commitlint antes de hacer un commit

Ahora toca configurar Husky para que ejecute Commitlint antes de hacer un commit. Para ello, crearemos un hook llamdo commit-msg que se ejecutará antes de confirmar el mensaje del commit. Usaremos el siguiente comando para crear el hook:

echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Este comando crear un archivo .husky/commit-msg en la raíz del proyecto con el siguiente contenido:

npx --no -- commitlint --edit $1

Este script ejecutará Commitlint antes de confirmar el mensaje del commit en Git. Commitlint comprobará que el mensaje del commit siga la convención de commits configurada en el archivo commitlint.config.js.

Nota: Esta configuración está disponible para la version 9 de Husky, si estás usando una versión anterior, puedes consultar la documentación oficial de Husky para obtener más información.

Convención de commits

La convención de commits que estamos utilizando es la convención convencional de Angular. Esta convención es muy popular y es utilizada por muchas empresas y proyectos de código abierto. A continuación mencionaremos algunos ejemplos de commits que siguen esta convención:

feat: Nueva funcionalidad.
fix: Corrección de errores.
docs: Cambios en la documentación.
style: Cambios que no afectan el código (espacios en blanco, formato, etc.).
refactor: Cambios en el código que no corrigen errores ni añaden funcionalidades.
perf: Cambios en el código que mejoran el rendimiento.
test: Añadir o modificar pruebas.
chore: Cambios en el proceso de construcción o herramientas auxiliares y bibliotecas.
revert: Revertir un commit anterior.
ci: Cambios en la configuración de CI/CD.
build: Cambios en la configuración de construcción.

Si intentamos hacer un commit que no siga esta convención, Commitlint nos mostrará un mensaje de error y no nos permitirá confirmar el código en Git como se muestra en la siguiente imagen:

Para corregir el error, simplemente debemos seguir la convención de commits y volver a intentar hacer el commit.

git commit -m "docs: document for the project"

Link al repositorio remoto

Puedes ver el resultado final haciendo clic en el siguiente link:
Repositorio remoto

Conclusiones

En este artículo, hemos aprendido cómo configurar un proyecto de React para producción utilizando las mejores prácticas. Hemos configurado Prettier y ESLint para aplicar las mejores prácticas de codificación, Husky y lint-staged para ejecutar ESLint y Prettier antes de hacer un commit, y Commitlint para configurar una convención de commits en nuestro proyecto.

Espero que este artículo te haya sido útil y te haya ayudado a configurar tu proyecto de React para producción. Si tienes alguna pregunta o sugerencia, no dudes en dejar un comentario.

Entendiendo la metodología BEM

Josué Oroya — Sat, 18 Feb 2023 18:08:25 +0000

Ya sea durante nuestro aprendizaje o en la misma práctica laboral es probable que nos hallamos encontrado con un problema a la hora de nombrar nuestras clases de css. En este artículo conoceremos la metodología más usada para nombrar nuestras clases, BEM.

Con proyectos muy pequeños, asignar clases a las etiquetas de html suele ser un trabajo sencillo, y es que no tenemos que pensar tanto a la hora de nombrarlas, sin embargo, cuando nuestro proyecto escala empezamos a notar cierta dificultad e inconsistencia con las clases que vamos nombrando. Es por eso que es muy común ver un HTML de la siguiente manera.

  <header class="box-top">
      <img
        src="https://res.cloudinary.com/ionicimagesbank/image/upload/v1676553696/material/tutorials/Sample_Logo_mvdjix.png"
        alt=""
        class="logo"
      />
      <nav>
        <ul class="list">
          <li class="element-1">
            <a href="">features</a>
          </li>
          <li class="element-2">
            <a href="">pricing</a>
          </li>
          <li class="element-3">
            <a href="">community</a>
          </li>
          <li class="element-4">
            <a href="">support</a>
          </li>
        </ul>
      </nav>

      <button class="btn-register">register</button>
    </header>

Este es un pequeño ejemplo del HTML correspondiente al diseño de una barra de navegación, además previamente se puede apreciar una imagen previa.

Como se puede apreciar, hay muchas cosas que se podrían mejorar pero quisiera enfocarme solo en la problemática que viene después. El elemento <li class='elemento-1'> y los demás están definidos como elementos de algo, es decir como los elementos de list, el problema surge si quiero tener una lista de elementos de otra cosa, ¿Podré usar element-1 ? La respuesta es un sí a medias, lo podré usar siempre y cuando en el css combine selectores, porque de lo contrario tendré elementos de distintos tipos pero con clases nombradas igual.

Metodología BEM

(Block Element Modifier)

Esta metodología tiene un enfoque basado en componentes para el desarrollo web. Básicamente, se trata de dividir en bloques independientes cada subdivisión de nuestro layout.

Bloque:

Contenedor o contexto donde se encuentra un elemento. Conforma la raíz de una clase. El nombre del bloque describe su propósito, es por eso que para nombrar esta clase debemos hacernos la siguiente pregunta: ¿Qué es?

    <nav class="links-container">
      <a>Home</a>
      <a>Login</a>
      <a>Register</a>
    </nav>

Como se ve en la imagen anterior, tengo una etiqueta <nav> la cual tiene como fin contener un numero de links de navegación, haciendo este ejercicio, el nombre elegido sería links-container o contenedor de links

Elemento

Es una pieza del bloque. Se puede decir que el bloque es el contenedor principal y los elementos son las piezas que lo conforman. Este concepto de elemento no puede aplicarse sin antes haber definido un bloque que lo contenga.
Al igual que el bloque, el nombre del elemento también describe su propósito. Es por ello que también nos haremos la siguiente pregunta: ¿Qué es?

  <nav class="links-container">
      <a class="links-container__link">Home</a>
      <a class="links-container__link">Login</a>
      <a class="links-container__link">Register</a>
    </nav>

Para construir el nombre de la clase para un elemento será necesario anteponer el nombre del bloque seguido de dos guiones bajo, es decir:

nombre-del-bloque__nombre-del-elemento

Modificador

Un modificador define la apariencia, estado o comportamiento de un bloque o un elemento. Como un ejemplo puntual, podríamos tener un contenedor de links: Home | Login | Register
Es probable que estos tres elementos, tengan que compartir el mismo estilo pero en el caso del register, este tendría una leve variación, ya que al inducir a una acción como registrarse será necesario hacerlo más llamativo. Por lo tanto, para nombrar dicha clase tendremos que preguntarnos: ¿Cómo se ve?

  <nav class="links-container">
      <a class="links-container__link">Home</a>
      <a class="links-container__link">Login</a>
      <a class="links-container__link links-container__link--red">Register</a>
    </nav>

Para la construcción del nombre de esta clase tendremos que anteponer el nombre del bloque seguido de dos guiones bajo, el nombre del bloque seguido de dos guiones del medio y por último el nombre de nuestra clase.

nombre-del-bloque__nombre-del-elemento--nombre-del-modificador

Conclusión:

La metodología BEM nos abre un sin fin de posibilidades para nombrar clases de una manera consecuente y ordenada. Además, debido a su combinación de palabras, también nos proveerá de clases con más especificidad si es que además combinamos selectores en el css.

VueJS - Día 01

Josué Oroya — Fri, 02 Sep 2022 00:13:56 +0000

[toc]
Bienvenidos a nuestro día 1 con VueJS. Para empezar, vamos a considerar los siguientes requerimientos:

Node JS
npm
git

Creación de un proyecto en VueJS

Podremos instalar y crear un nuevo proyecto en VueJS desde la página oficial: https://vuejs.org Entonces usaremos el siguiente comando:

npm init vue@latest

Al correr este comando vamos a crear un nuevo proyecto en VueJS, por lo que veremos en nuestra consola la siguiente interfaz:

✔ Project name: … <your-project-name>
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit testing? … No / Yes
✔ Add Cypress for both Unit and End-to-End testing? … No / Yes
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes

Scaffolding project in ./<your-project-name>...
Done.

Si no estamos seguros de alguna configuración, basta con elegir NO y continuar con la siguiente configuración. Más adelante podremos incluir lo que nos haga falta a nuestro proyecto.

Veremos que se creará una carpeta con el nombre de nuestro proyecto en VueJS, por lo cual será necesario ingresar e iniciar nuestro proyecto mediante los siguientes comandos:

cd <your-project-name>
npm install
npm run dev

Aún no estamos en condiciones de realizar un build de nuestro proyecto, pero aún así dejo el comando para hacer el build de nuestra aplicación:

npm run build

Usando la CLI de VueJS

Además de las configuraciones mencionadas anteriormente, podemos hacer uso del CLI de VueJS, un CLI significa "interfaz de línea de comandos", y es una herramienta sumamente importante a la hora de automatizar la creación y actualización de proyectos con un determinado framework.

Podemos instalar nuestra CLI de VueJS desde su página oficial: https://cli.vuejs.org En todo caso, usaremos el siguiente comando:

npm install -g @vue/cli

Una vez que hayamos instalado el CLI, podremos iniciar un nuevo proyecto en VueJS con el siguiente comando:

vue create 01-first-app

Lo que veremos a continuación es que el CLI nos proveerá de tres opciones para iniciar nuestro proyecto:

Vue CLI v5.0.8
? Please pick a preset:
  Default ([Vue 3] babel, eslint)
  Default ([Vue 2] babel, eslint)
> Manually select features

Las dos primeras son pre configuraciones para trabajar con Vue 2 o Vue 3, ambas son versiones de VueJS muy usadas. Mientras escribo este material, Vue 2 continúa siendo la versión más usada, sin embargo en un futuro no muy lejano primará Vue 3 en la mayoría de proyectos con este framework.

Para esta instancia usaremos la opción 3 que es la de seleccionar las características de forma manual.

Vue CLI v5.0.8
? Please pick a preset: Manually select features
? Check the features needed for your project: (Press <space> to select, <a> to toggle all, <i> to invert selection,
and <enter> to proceed)
>(*) Babel
 ( ) TypeScript
 ( ) Progressive Web App (PWA) Support
 ( ) Router
 ( ) Vuex
 ( ) CSS Pre-processors
 ( ) Linter / Formatter
 (*) Unit Testing
 ( ) E2E Testing

Por el momento solo elegiremos Babel y Unit Testing. La selección se hace presionando "space" .
Continuaremos presionando "Enter"

Vue CLI v5.0.8
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Unit
? Choose a version of Vue.js that you want to start the project with
> 3.x
  2.x

A continuación elegiremos la versión 3 de Vue JS y como herramientas para test Jest

Vue CLI v5.0.8
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Unit
? Choose a version of Vue.js that you want to start the project with 3.x
? Pick a unit testing solution: (Use arrow keys)
> Jest
  Mocha + Chai

Por último, el CLI nos preguntará si queremos usar un archivo dedicado para guardar esta configuración o si preferimos usar el package.json

Elegiremos usar un archivo dedicado.

¡Listo! Ya tenemos nuestro primer proyecto en VueJS creado con el CLI. Ahora vamos a abrirlo y para eso al igual que el ejemplo anterior usaremos los siguientes comandos:

cd 01-first-app
npm run serve

Dos formas de crear un proyecto con React JS

Josué Oroya — Thu, 01 Sep 2022 23:10:10 +0000

Existen muchas formas de crear una aplicación con React JS, sin embargo quisiera compartir la forma más usada y la forma que deberíamos probar usar a partir de ahora.

Hace algunos años la única manera de crear un proyecto con React JS era crear el proyecto desde cero, archivo por archivo a través de la configuración de webpack, lo cual sinceramente es una locura, aunque como punto a favor, se tenía un control total.

Hoy en día la manera más sencilla de crear un proyecto de react js es usando el comando

npx create-react-app nombre-de-app

Y es que este comando hace algo tan increible como crear una aplicación de react js desde cero, al cual le podremos asignar un nombre en lugar de "nombre-de-app".

Pero no todo acaba ahí, hace poco se ha sumando una herramienta muy buena e increíblemente rápída llamada Vite JS. Los invito a ver este video 😉

React JS & Tailwindcss - 01-Instalación

Josué Oroya — Thu, 01 Sep 2022 23:05:39 +0000

Instala Tailwindcss en tu proyecto de React JS y usa uno de los mejores frameworks para estilar.

React JS - Clase 2

Josué Oroya — Wed, 27 Jul 2022 13:39:00 +0000

Hola a todas y todos. He creado este foro en dev.to para atender las consultas que puedan surgir respecto al curso que dicto actualmente. Debido a que es un foro público, por favor no compartan información sensible como datos personales, etc. Pueden dejarme sus comentarios debajo de esta publicación y con gusto les estaré respondiendo a la brevedad.

Elegí dev.to ya que más allá de ser gratuito, también podrán acceder a muchos post de la comunidad de desarrolladores, además podrán escribir código acá o adjuntar imágenes para realizar sus consultas.

Cualquier sugerencia que tengan es bienvenida 😊

Les dejo el componente que creamos hoy:

Count.jsx

import React, { useState } from 'react';
import './styles/Count.css'

const Count = ({ initial, stock }) => {

    const [ count, setCount ] = useState(initial);

    const addCount = (num) => {
        console.log('Se ejecuta addCount');
        setCount(count + num);
    }

    return(
        <div className="count-container">

            <div className="count-container__count">{count}</div>

            <div className="count-container__controls">
                <button 
                    disabled={count===initial}
                    className="controls__button"
                    onClick={()=>{addCount(-1)}}               
                >
                    -
                </button>
                <button
                    disabled={count===stock} 
                    className="controls__button"
                    onClick={()=>{addCount(1)}}
                >
                    +
                </button>
            </div>

        </div>
    )
}

export default Count;

Count.css

.count-container{

    width: 100%;
    min-height: 400px;
    text-align: center;

}

.count-container .count-container__count {
    font-size: 8rem;
}

.count-container .count-container__controls {

}

.count-container .count-container__controls .controls__button{
    font-size:4rem;
    padding:9px 12px;
    cursor: pointer;
}

Si bien les dije que vamos a crear un repositorio de github, se me ocurrió que podemos ver cómo subir nuestro repo en github para la siguiente clase, así que lo haremos la próxima semana.

Acá les dejor un ejemplo que hice para el contador de un e-Commerce

Tip CSS: Usando "position" para centrar un elemento dentro de su contenedor

Josué Oroya — Mon, 19 Jul 2021 12:38:16 +0000

Post en desarrollo

Usa variables en CSS sin dependencias

Josué Oroya — Mon, 19 Jul 2021 12:25:16 +0000

Esta es una prueba inicial...
Nota en desarrollo.

DEV Community: Josué Oroya

¿Estás aplicando un anti-patrón de arquitectura en el Frontend?

¿Qué es y por qué es importante la arquitectura en el Frontend?

Los pilares de una buena arquitectura Frontend

Del otro lado del río: los anti-patrones de arquitectura

¿Estás aplicando un anti-patrón de arquitectura en el Frontend?

1. El "Spaghetti Code" o la Gran Bola de Lodo (Big Ball of Mud)

2. El Componente Dios (God Component)

3. Acoplamiento Excesivo (Tight Coupling)

4. La Carpeta "Utils" o "Helpers" Infinita

5. El Estado Global Descontrolado (Global State Soup)

6. La Abstracción Prematura (Premature Abstraction)

La Regla del Tres

Ejemplo: Sobre-ingeniería vs. Solución pragmática

Principios a seguir

7. El Copy-Paste Driven Development

Checklist de diagnóstico

El camino hacia una mejor arquitectura

Recomendaciones finales

Conclusión

El propósito del Testing

El costo real de los errores en producción

Errores que resultaron muy costosos

El verdadero enemigo: lo que no se ve

El propósito fundamental: gestionar el riesgo

Testing en el mundo web (mi mundo): la frontera entre frontend y backend

Una cultura, no una fase

Epílogo: el tester invisible

La AI es perezosa y eso no está mal

Un caso real: cuando la pereza se hizo evidente

Reflexión: ¿defecto o característica?

La pereza como virtud

¿Qué significa “pereza” en términos técnicos?

La importancia de la supervisión humana

En resumen

Reflexión final

Qué es el principio de incertidumbre de un estado en React

Principio de incertidumbre de un estado en React

Principio de incertidumbre de un estado en React

¿Por qué sucede esto?

1. El estado no se actualiza

Ejemplo

Solución recomendada

2. Funciones externas que afectan al estado sin que te des cuenta

Ejemplo

Solución recomendada: Encapsular la lógica que modifica el estado

Consejo práctico

3. Estado sincronizado con props que nunca se actualiza

Ejemplo

Solución recomendada: Sincronizar el estado con useEffect

Conclusiones

Consejo final

Configurando un proyecto de React para producción

Requerimientos técnicos

¿Por qué pnpm?

Creando un nuevo proyecto con Vite

React con SWC o Babel

Configurando ESLint y Prettier con TypeScript para aplicar las mejores prácticas

Configurando Prettier

Configurando la extensión de Prettier en Visual Studio Code

.vscode/settings.json

Implementando el archivo .prettierignore

Configurando ESLint

1. Uso de plugins

2. Soporte para Prettier

3. Ignorar archivos

4. Configuración de reglas

Probando la configuración de ESLint y Prettier

Añadiendo scripts de ESLint y Prettier al package.json

Configurando Husky para ejecutar ESLint y Prettier antes de hacer un commit

Inicializar git en el proyecto

Instalar Husky y lint-staged

Configurar Husky y lint-staged

Inicializar Husky

Modificar el archivo .husky/pre-commit

Asegurarse de que Husky se instale cuando se clone el repositorio

Bonus: Configurando una convención de commits con Commitlint

Instalar Commitlint

Configurar Husky para ejecutar Commitlint antes de hacer un commit

Convención de commits

Implementando el archivo `.prettierignore`

Añadiendo scripts de ESLint y Prettier al `package.json`

Modificar el archivo `.husky/pre-commit`