Forem: John Serrano (DEV)

Aprende lógica de programación: la base para convertirte en programador

John Serrano (DEV) — Sat, 20 Sep 2025 21:06:26 +0000

¿Quieres aprender a programar y no sabes por dónde empezar?

La respuesta es sencilla: lógica de programación.

Este es el punto de partida para adentrarte en el mundo de la informática y el desarrollo de software. En este artículo descubrirás qué es la lógica de programación, qué papel juegan los algoritmos, cómo aplicarlos a tu vida diaria y dónde puedes comenzar a entrenar estas habilidades.

¿Por qué la lógica de programación es tan importante?

Antes de aprender un lenguaje como JavaScript, Python o C#, necesitas algo más fundamental: aprender a pensar como programador.

La lógica de programación es la base que te permite dar instrucciones claras y ordenadas a una computadora para que pueda ejecutar una tarea. No importa con qué lenguaje comiences; todos comparten la misma lógica.

Además, hay dos aliados que te serán de gran ayuda en este camino:

Las matemáticas: porque entrenan tu capacidad de razonar con reglas y estructuras.
El inglés: porque la mayoría de lenguajes de programación y documentación están escritos en este idioma.

¿Qué es la lógica de programación?

La lógica de programación es la técnica para organizar y planificar instrucciones en una secuencia coherente con el fin de resolver un problema o alcanzar un objetivo.

En otras palabras: es aprender a traducir ideas en pasos claros que una computadora pueda entender y ejecutar.

El reto del programador es estructurar esas instrucciones de manera precisa, porque las máquinas no entienden mensajes subjetivos. Para ellas, cada paso debe estar escrito en el orden correcto y sin ambigüedades.

¿Qué es un algoritmo?

Un algoritmo es una secuencia de pasos finitos y ordenados que permiten resolver un problema o completar una tarea.

Piensa en un algoritmo como una receta de cocina: te dice qué hacer, en qué orden y con qué ingredientes.

Ejemplo: Algoritmo de las papas fritas

1. Tomar las papas  
2. Pelar las papas  
3. Cortarlas en tiras  
4. Colocar aceite en un sartén y encender la estufa  
5. Esperar a que el aceite esté caliente  
6. Poner las papas en el aceite  
7. Aguardar 10 minutos  
8. Retirar y servir

¿Fácil, verdad? Ese es un algoritmo. Si cambiaras el orden por ejemplo, intentar freír las papas antes de cortarlas el resultado sería incorrecto. Lo mismo sucede en programación.

Con el tiempo, los algoritmos pueden representarse de varias formas:

Textuales (como el ejemplo de arriba).
Gráficas, usando flujogramas.
Pseudocódigo, una forma intermedia entre el lenguaje humano y el código real.

Variables y constantes

En programación, además de los pasos lógicos, necesitas manejar datos. Para eso existen variables y constantes.

Una variable es un espacio donde guardas información que puede cambiar.
Una constante es un valor fijo que no cambia durante la ejecución del programa.

👉 Siguiendo el ejemplo de las papas fritas:

El aceite es una variable, porque puede estar frío o caliente.
El tiempo de cocción es una constante, ya que siempre tarda aproximadamente lo mismo.

La lógica en tu rutina diaria

La lógica no se limita al mundo del software. Sin darte cuenta, ya aplicas algoritmos todos los días.

Por ejemplo, tu rutina al despertar puede verse como un algoritmo:

Apagar la alarma
Levantarte de la cama
Cepillarte los dientes
Preparar el desayuno
Vestirte

Incluso aquí puedes identificar variables y constantes: el clima del día puede variar (variable), pero cepillarte los dientes siempre es un paso fijo (constante).

Ejercicios como este son una gran forma de entrenar tu razonamiento lógico antes de dar el salto al código.

¿Dónde aprender lógica de programación?

Hoy tienes a tu alcance una infinidad de recursos gratuitos y de pago para aprender lógica de programación:

Code.org: una plataforma educativa pensada para principiantes, con cursos estructurados que van desde lo básico hasta conceptos más avanzados. Es utilizada en miles de escuelas y ofrece un camino guiado para aprender ciencias de la computación.

Codewars: ideal para quienes ya tienen una base y quieren practicar con retos de programación. Sus katas te permiten mejorar progresivamente y comparar tus soluciones con las de otros programadores. Visita mi perfil.

Cursos online: en plataformas como Coursera, Platzi, Udemy o incluso YouTube.

Comunidades digitales: foros, Discords y grupos en redes sociales donde puedes resolver dudas y compartir tus avances.

Mi recomendación personal

Si quieres seguir aprendiendo lógica de programación y programación en general, te invito a explorar dos recursos que preparo con mucho detalle:

📖 Mi blog: John Serrano
— artículos fáciles de entender, desde fundamentos hasta temas avanzados.

🎥 Mi canal de YouTube: John Serrano Dev
— videos prácticos donde explico paso a paso con ejemplos reales.

Conclusión

La lógica de programación es el primer escalón en la carrera de todo desarrollador.

Es la habilidad que te permitirá pensar en soluciones, diseñar algoritmos y después llevarlos a cualquier lenguaje de programación.

Recuerda:

Practicar es la clave.
Equivocarte es parte del proceso.
Aprender lógica es aprender a pensar como programador.

Ahora que conoces la base, el siguiente paso es poner manos a la obra y comenzar a practicar. 🚀

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

Arquitectura Hexagonal con React y TypeScript: guía paso a paso (enfoque pragmático)

John Serrano (DEV) — Sat, 16 Aug 2025 16:20:53 +0000

Inspirado por enfoques pragmáticos: menos capas, más claridad. Aquí no seguimos el “purismo” hexagonal; tomamos lo que aporta valor en UI y evitamos sobre-ingeniería.

Objetivo: que alguien que está aprendiendo pueda aplicarlo en 1 tarde.

Historia de usuario

“Como usuario quiero entrar a la Home y ver un listado de productos con:

nombre
imagen
precio

Tenemos una API que expone /products.”

Pasemos a código.

Capas (lo justo y necesario)

Dominio: tipos y reglas (casi siempre son simples en UI).
Aplicación: casos de uso (orquestan llamadas).
Infraestructura: HTTP/SDKs, errores, auth.
UI: componentes React.

Nota importante:
Si el proyecto crece o necesitas intercambiar fuentes de datos, añades un repositorio como puerto. Más abajo verás un ejemplo de cómo sería el funcionamiento y por qué conviene hacerlo en ese momento (no antes).

Dominio: ¿tipo o clase?

Regla práctica: empieza con tipos. Si luego necesitas comportamiento/validación compleja, refactorizas a clase.

// src/domain/Product.ts
export type Product = {
  name: string;
  image: string;
  price: number;
};

Infra: un cliente HTTP pequeño (adapter)

Aísla fetch/axios en un único punto. Centralizas errores y auth. Si cambias fetch por axios, solo tocas aquí.

// src/infrastructure/APIClient.ts
export class APIClient {
  constructor(private readonly baseUrl: string, private readonly fetchImpl: typeof fetch = fetch) {}

  async get<T>(path: string): Promise<T> {
    const res = await this.fetchImpl(`${this.baseUrl}${path}`);
    if (!res.ok) {
      // Manejo de errores muy simple para el ejemplo
      const msg = `HTTP ${res.status} al GET ${path}`;
      throw new Error(msg);
    }
    return res.json() as Promise<T>;
  }
}

Aplicación: caso de uso mínimo

Empieza simple: sin repositorio. Orquesta la llamada y devuelve dominio directamente.

// src/application/ListProducts.ts
import type { Product } from "../domain/Product";
import { APIClient } from "../infrastructure/APIClient";

export class ListProducts {
  constructor(private readonly api: APIClient) {}

  async execute(): Promise<Product[]> {
    // Aquí podrías mapear/filtrar/ordenar si hace falta
    return this.api.get<Product[]>("/products");
  }
}

¿Qué es un DTO y cuándo usarlo?

DTO (Data Transfer Object) es un objeto “de transferencia de datos”. Su objetivo es:

Formatear o adaptar datos para una capa específica (p. ej., la UI).
Ocultar detalles del dominio que no quieres exponer.
Combinar/dividir datos que vienen de distintas fuentes.

Cuándo NO usar DTO:

Si la UI necesita exactamente los mismos campos del dominio, añadir DTO genera ruido y “capas por capas”.

Cuándo SÍ usar DTO:

Si necesitas cambiar nombres/formatos (p. ej., price en centavos → cadena “$12.99”).
Si quieres estabilizar la UI frente a cambios del dominio o de la API.
Si debes ocultar campos sensibles.

Ejemplo con DTO y mapeo en el caso de uso:

// src/application/ProductDTO.ts
export type ProductDTO = {
  name: string;
  imageUrl: string;   // renombrado para la UI
  displayPrice: string; // precio formateado
};

// src/application/ListProductsWithDTO.ts
import type { Product } from "../domain/Product";
import type { ProductDTO } from "./ProductDTO";
import { APIClient } from "../infrastructure/APIClient";

export class ListProductsWithDTO {
  constructor(private readonly api: APIClient) {}

  async execute(): Promise<ProductDTO[]> {
    const products = await this.api.get<Product[]>("/products");
    return products.map(p => ({
      name: p.name,
      imageUrl: p.image,
      displayPrice: `$${p.price.toFixed(2)}`,
    }));
  }
}

Idea práctica:

Empieza sin DTO.
Si la UI empieza a necesitar transformaciones repetidas, crea un DTO y mueve la transformación al caso de uso.

UI: un componente que llama al caso de uso

Mantén la UI enfocada en presentar datos y gestionar estado/errores.

// src/ui/HomePage.tsx
import React, { useEffect, useState } from "react";
import type { Product } from "../domain/Product";
import { APIClient } from "../infrastructure/APIClient";
import { ListProducts } from "../application/ListProducts";
// Si prefieres DTO, importa ListProductsWithDTO y ProductDTO en su lugar.

const api = new APIClient(import.meta.env.VITE_API_URL ?? "https://api.example.com");
const listProducts = new ListProducts(api);

export const HomePage: React.FC = () => {
  const [products, setProducts] = useState<Product[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    let mounted = true;
    (async () => {
      try {
        const data = await listProducts.execute();
        if (mounted) setProducts(data);
      } catch (e: any) {
        if (mounted) setError(e?.message ?? "No se pudo cargar productos");
      } finally {
        if (mounted) setLoading(false);
      }
    })();
    return () => { mounted = false; };
  }, []);

  if (loading) return <p>Cargando…</p>;
  if (error) return <p style={{ color: "crimson" }}>{error}</p>;

  return (
    <div>
      <h1>Productos</h1>
      <ul>
        {products.map((p, index) => (
          <li key={p.name} data-testid={`product-id-${index}`}>
            <img src={p.image} alt={p.name} width={80} height={80} />
            <h3>{p.name}</h3>
            <p>Precio: ${p.price}</p>
          </li>
        ))}
      </ul>
    </div>
  );
};

¿Cuándo añadir repositorios (puertos) “hexagonales”?

Añádelos cuando:

necesites más de una fuente de datos (REST, GraphQL, IndexedDB, memoria),
quieras desacoplarte fuertemente del backend,
o quieras tests de aplicación ultra rápidos sin MSW.

Recuerda la nota de arriba: “Si el proyecto crece o necesitas intercambiar fuentes de datos, añades un repositorio como puerto.” Aquí abajo verás un ejemplo de cómo sería el funcionamiento.

Puerto de repositorio (dominio)

// src/domain/ProductRepository.ts
import type { Product } from "./Product";

export interface ProductRepository {
  getProducts(): Promise<Product[]>;
}

Implementación HTTP del repositorio (infra)

// src/infrastructure/HttpProductRepository.ts
import type { Product } from "../domain/Product";
import type { ProductRepository } from "../domain/ProductRepository";
import { APIClient } from "./APIClient";

export class HttpProductRepository implements ProductRepository {
  constructor(private readonly api: APIClient) {}
  getProducts(): Promise<Product[]> {
    return this.api.get<Product[]>("/products");
  }
}

Caso de uso usando el puerto (aplicación)

// src/application/ListProductsWithRepo.ts
import type { Product } from "../domain/Product";
import type { ProductRepository } from "../domain/ProductRepository";

export class ListProductsWithRepo {
  constructor(private readonly repo: ProductRepository) {}
  execute(): Promise<Product[]> {
    // Si solo delega, cuestiónate si esta capa aporta valor (Middle Man).
    return this.repo.getProducts();
  }
}

Composición (decides la fuente en un único lugar)

// src/app/composition.ts
import { APIClient } from "../infrastructure/APIClient";
import { HttpProductRepository } from "../infrastructure/HttpProductRepository";
import { ListProductsWithRepo } from "../application/ListProductsWithRepo";

const api = new APIClient(import.meta.env.VITE_API_URL ?? "https://api.example.com");
const repo = new HttpProductRepository(api);

// Si quisieras memoria, bastaría con cambiar la implementación del puerto:
// const repo = new InMemoryProductRepository([{ name: "A", image: "/a.png", price: 10 }]);

export const listProducts = new ListProductsWithRepo(repo);

Cómo funciona en la práctica:

La UI usa listProducts.execute().
Si mañana cambias de REST a GraphQL o a IndexedDB, implementas otro repositorio y no tocas ni UI ni casos de uso (salvo wiring).

(Mis) Problemas con ejemplos

No hay suficiente complejidad de dominio

Si tu caso es casi-CRUD y el reto principal está en la UX/estado, no en reglas de negocio, muchas capas añaden fricción sin beneficio.

Ejemplo suficiente para empezar:

// src/application/ListProducts.ts
import type { Product } from "../domain/Product";
import { APIClient } from "../infrastructure/APIClient";

export class ListProducts {
  constructor(private readonly api: APIClient) {}
  execute(): Promise<Product[]> {
    return this.api.get<Product[]>("/products");
  }
}

Simple, testeable (stub de APIClient o MSW) y sin “capas por capas”.
Cuando aparezca complejidad real (paginación, filtros, cacheo, merge de fuentes), puedes introducir repositorios y casos de uso más ricos.

Interfaces inútiles

Crear interfaces “por si acaso” suele ser ruido. La regla práctica:

Crea una interfaz si y solo si:
- tendrás 2+ implementaciones, o
- buscas desacoplarte del backend/cliente HTTP.

Anti‑ejemplo con una interfaz sin valor:

// src/domain/UselessProductRepo.ts
import type { Product } from "./Product";

export interface ProductRepository {
  getProducts(): Promise<Product[]>;
}

// Única implementación y uso en un solo lugar -> poco valor
export class HttpProductRepository implements ProductRepository {
  getProducts(): Promise<Product[]> {
    return fetch("/products").then(r => r.json());
  }
}

Alternativa más simple:

// src/application/ListProductsSimple.ts
import type { Product } from "../domain/Product";
import { APIClient } from "../infrastructure/APIClient";

export class ListProductsSimple {
  constructor(private readonly api: APIClient) {}
  execute(): Promise<Product[]> {
    return this.api.get<Product[]>("/products");
  }
}

Capas estrictas: tipos de retorno y “Middle Man”

DTO vs Dominio: si Product y ProductDTO tienen los mismos campos, el DTO no aporta valor.
“Middle Man”: un caso de uso que solo delega al repositorio sin añadir semántica es un code smell.

Anti‑ejemplo (Middle Man):

// src/application/ListProductsMiddleMan.ts
import type { Product } from "../domain/Product";
import type { ProductRepository } from "../domain/ProductRepository";

export class ListProductsMiddleMan {
  constructor(private readonly repo: ProductRepository) {}
  execute(): Promise<Product[]> {
    // Indirección sin abstracción: no aporta nada.
    return this.repo.getProducts();
  }
}

Cómo aportar valor real en la capa de aplicación:

// src/application/ListProductsEnriched.ts
import type { Product } from "../domain/Product";
import type { ProductRepository } from "../domain/ProductRepository";

export class ListProductsEnriched {
  constructor(private readonly repo: ProductRepository) {}
  async execute(query?: { minPrice?: number; sort?: "asc" | "desc" }): Promise<Product[]> {
    let products = await this.repo.getProducts();

    if (query?.minPrice != null) {
      products = products.filter(p => p.price >= query.minPrice!);
    }
    if (query?.sort) {
      products = products.sort((a, b) => query.sort === "asc" ? a.price - b.price : b.price - a.price);
    }
    return products;
  }
}

DTO solo cuando transforme algo:

// src/application/ListProductsToDTO.ts
import type { Product } from "../domain/Product";
import type { ProductDTO } from "./ProductDTO";
import type { ProductRepository } from "../domain/ProductRepository";

export class ListProductsToDTO {
  constructor(private readonly repo: ProductRepository) {}
  async execute(): Promise<ProductDTO[]> {
    const products = await this.repo.getProducts();
    return products.map(p => ({ name: p.name, imageUrl: p.image, displayPrice: `$${p.price.toFixed(2)}` }));
  }
}

Pros de “saltar capas”:

Menos indirection.
Código más fácil de seguir. Contras:
Requiere criterio para no perder consistencia.

Repositorios en frontend: cuándo sobran y cómo simplificar

Muchas veces:

hay una sola fuente (tu API),
queries simples,
y el repositorio se usa en un solo punto.

En esos casos, puedes ir directo con un APIClient y mantener testabilidad.

Anti‑ejemplo importando axios en la aplicación:

// src/application/ListProductsAxiosInline.ts
import type { Product } from "../domain/Product";
import axios from "axios";

export class ListProductsAxiosInline {
  async execute(): Promise<Product[]> {
    const res = await axios.get<Product[]>(`https://.../products`);
    return res.data;
  }
}
// Funciona, pero mezclas infraestructura (axios) en aplicación.

Mejor: encapsula axios en un adapter y centraliza errores.

// src/infrastructure/APIClientAxios.ts
import axios, { AxiosError } from "axios";

export class NotFoundError extends Error {}
export class ApiError extends Error {}

export class APIClientAxios {
  constructor(private readonly baseUrl: string) {}

  async get<T>(path: string): Promise<T> {
    try {
      const res = await axios.get<T>(`${this.baseUrl}${path}`);
      return res.data;
    } catch (e) {
      const err = e as AxiosError;
      if (err.response?.status === 404) throw new NotFoundError("Recurso no encontrado");
      throw new ApiError(err.message);
    }
  }

  // more methods: post, put, delete...
}

Caso de uso usando el adapter:

// src/application/ListProductsWithAPIClientAxios.ts
import type { Product } from "../domain/Product";
import { APIClientAxios } from "../infrastructure/APIClientAxios";

export class ListProductsWithAPIClientAxios {
  constructor(private readonly api: APIClientAxios) {}
  execute(): Promise<Product[]> {
    return this.api.get<Product[]>("/products");
  }
}

Ir “al límite”: instanciar internamente el cliente.

// src/application/ProductListSelfContained.ts
import type { Product } from "../domain/Product";
import { APIClientAxios } from "../infrastructure/APIClientAxios";

export class ProductListSelfContained {
  private api = new APIClientAxios(import.meta.env.VITE_API_URL ?? "https://api.example.com");

  execute(): Promise<Product[]> {
    return this.api.get<Product[]>("/products");
  }
}
// Ojo: dependencia oculta -> más difícil de testear y de cambiar en composición.

Testing cuando no hay repos:

Opción A (recomendada): tests sociables con MSW sobre la UI (sección “Testing” al final).
Opción B: stub del adapter en tests de aplicación.

// src/application/__tests__/ListProductsWithAPIClientAxios.spec.ts
import type { Product } from "../../domain/Product";
import { ListProductsWithAPIClientAxios } from "../ListProductsWithAPIClientAxios";

class FakeAPI {
  constructor(private readonly data: Product[]) {}
  async get<T>(_path: string): Promise<T> {
    return this.data as unknown as T;
  }
}

test("devuelve productos desde el adapter", async () => {
  const fake = new FakeAPI([{ name: "A", image: "/a.png", price: 10 }]);
  const usecase = new ListProductsWithAPIClientAxios(fake as any);
  await expect(usecase.execute()).resolves.toHaveLength(1);
});

Si más adelante necesitas intercambiar fuentes (REST/IndexedDB/memoria), entonces sí: introduce el puerto ProductRepository y obtendrás tests de aplicación ultrarrápidos con una implementación en memoria.

Testing

Aplicando hexagonal junto al patrón repositorio te permite crear tests unitarios que cumplan con el acrónimo FIRST:

Fast: rápidos para obtener feedback veloz.
Isolated: aislados de DB/red.
Repeatable: mismo resultado siempre.
Self-validating: se validan solos (asserts claros).
Timely: idealmente antes de desarrollar (TDD).

Con el enfoque simplificado propuesto, así cumplo gran parte:

Tipos de tests (filosofía):

“Write tests. Not too many. Mostly integration” (Kent C. Dodds).
Yo lo adapto a: “Write tests, mostly sociable tests”.
- En esta historia de usuario, prefiero tests sociables de UI con un servidor HTTP simulado que devuelva respuestas predefinidas.

Trade-off:

Al levantar un servidor HTTP simulado, quizá pierdas algo de “F” (velocidad). Lo asumo porque el test es más representativo.

Herramienta:

MSW (Mock Service Worker): mokea a nivel de red, no tu código.

Cómo testear esta funcionalidad:

Omito unitarios “puros” de aplicación si no hay lógica (evito tests que solo replican una llamada).
Escribo tests de UI que cubren el flujo principal y el de error, falseando la API con MSW.
Para mayor seguridad antes de desplegar: tests E2E happy path en pre con Playwright.

Ejemplo con MSW:

// src/ui/HomePage.test.tsx
import { render, screen } from "@testing-library/react";
import { rest } from "msw";
import { setupServer } from "msw/node";
import React from "react";
import { HomePage } from "./HomePage";

const apiUrl = "https://api.example.com";
const server = setupServer(
  rest.get(`${apiUrl}/products`, (_req, res, ctx) =>
    res(ctx.json([
      { name: "Product Zero", image: "/img0.png", price: 10 },
      { name: "Product One", image: "/img1.png", price: 15 },
    ]))
  )
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// Ajusta según tu runner (Vitest/Jest). Con Vitest podrías hacer:
// vi.stubEnv("VITE_API_URL", apiUrl);

test("muestra productos al cargar", async () => {
  render(<HomePage />);
  const items = await screen.findAllByTestId(/product-id-\d+/);
  expect(items).toHaveLength(2);
  expect(screen.getByText("Product Zero")).toBeInTheDocument();
  expect(screen.getByText("Product One")).toBeInTheDocument();
});

test("muestra error si la API falla", async () => {
  server.use(rest.get(`${apiUrl}/products`, (_req, res, ctx) => res(ctx.status(500))));
  render(<HomePage />);
  const error = await screen.findByText(/No se pudo cargar productos|HTTP 500/);
  expect(error).toBeInTheDocument();
});

E2E con Playwright (idea, sin código extenso):

Crea un test “happy path” que:
- visita la Home deployada en pre,
- espera ver el listado real,
- verifica al menos 1–2 productos.
Úsalo como smoke test en cada release.

Screaming Architecture (mini abrebocas)

Que el repo “grite” el dominio. En vez de “components/services/utils”, prefiere por feature:

src/domain/Product.ts
src/application/ListProducts.ts
src/infrastructure/APIClient.ts
src/ui/HomePage.tsx

Cuando la app crezca, separa por features (products, cart, auth) manteniendo esta idea.

En próximos artículos voy a traer uno sobre Screaming Architecture.

Checklist para aplicarlo hoy

Define tipos de dominio (Product).
Crea un APIClient pequeño para HTTP.
Escribe 1 caso de uso (ListProducts) que use el APIClient.
Implementa la HomePage que llama al caso de uso.
Solo si lo necesitas, añade un ProductRepository y su implementación HTTP (ver ejemplo de funcionamiento arriba).
Añade tests (lee la sección final “Testing” para decidir qué y cómo probar).

Conclusión

Ponemos en el centro el dominio (si lo hay), pero priorizamos simplicidad: no siempre necesitas capas intermedias entre lógica de aplicación, fuente de datos y UI.
Testea donde más valor aporta: UI sociable con MSW y un E2E de humo con Playwright. Si el dominio crece, añade repositorios y tests unitarios rápidos en memoria.

Glosario (términos clave)

Middle Man (code smell)

Qué es: un “intermediario” que solo pasa la llamada a otra capa/objeto sin añadir valor (sin validar, transformar, decidir, ni encapsular reglas). Es “indirección sin abstracción”.
Por qué es problema: añade complejidad y archivos extra, dificulta navegar el código y no aporta semántica.
Cómo detectarlo:
- La clase/método solo delega 1:1 a otra llamada.
- No hay lógica de negocio, ni transformación de datos, ni control de errores propio.
- Si lo eliminas y llamas directamente a la dependencia, nada cambia (salvo menos líneas).
Ejemplo:

// src/application/ListProductsMiddleMan.ts
import type { Product } from "../domain/Product";
import type { ProductRepository } from "../domain/ProductRepository";

export class ListProductsMiddleMan {
  constructor(private readonly repo: ProductRepository) {}
  execute(): Promise<Product[]> {
    return this.repo.getProducts();
  }
}

Alternativas:
- Eliminar la capa y usar directamente la dependencia.
- O bien justificarla añadiendo valor (filtrados, orden, mapeos, políticas de reintento, validaciones, etc.).

E2E de humo (smoke test)

Qué es: un test end-to-end mínimo y rápido que verifica el camino feliz crítico (la app arranca y la funcionalidad principal no “echa humo” tras un deploy).
Objetivo: detectar roturas graves en producción o pre-producción con el menor coste.
Alcance típico:
- Cargar la Home sin errores.
- Ver que se lista al menos un producto.
- Opcional: una interacción clave.
Cuándo ejecutarlo: en cada build de pre o antes de un deploy (pipeline de CD).
Relación con otros tests:
- Complementa a los tests de UI con MSW (rápidos y representativos en local/CI).
- No reemplaza tests unitarios donde haya lógica compleja: si el dominio crece, añádelos.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

¿Qué es SOLID? Principios de diseño para programar código limpio en TypeScript y React

John Serrano (DEV) — Sat, 02 Aug 2025 16:11:40 +0000

Introducción a los principios SOLID en la Programación Orientada a Objetos

En el desarrollo de software, escribir código limpio, modular y fácil de mantener es fundamental. Aquí es donde entran los principios SOLID: un conjunto de reglas que ayudan a diseñar clases y componentes bien estructurados.

Pero, ¿qué es SOLID? ¿Es un patrón de diseño, una arquitectura, o algo más?

SOLID no es un patrón ni una arquitectura, sino cinco principios de diseño que nos ayudan a organizar mejor nuestro código, especialmente en la Programación Orientada a Objetos (POO).

En este artículo:

Explicaremos qué es la POO y por qué es importante para entender SOLID.
Veremos cada uno de los principios SOLID con ejemplos prácticos en TypeScript (backend) y React (frontend).
Analizaremos las ventajas de aplicar SOLID y cómo empezar a implementarlo.

1. Conceptos básicos de la POO

La Programación Orientada a Objetos (POO) es un paradigma que organiza el código en “objetos” que representan elementos del mundo real.

Cada objeto tiene atributos (características) y métodos (acciones).

Ejemplo sencillo:

// TypeScript (Backend)
class Usuario {
  nombre: string;
  correo: string;

  constructor(nombre: string, correo: string) {
    this.nombre = nombre;
    this.correo = correo;
  }

  iniciarSesion() {
    // lógica de autenticación
  }
}

// React (Frontend)
function Usuario({ nombre, correo }) {
  return (
    <div>
      <h2>{nombre}</h2>
      <p>{correo}</p>
    </div>
  );
}

Clases e instanciación

Las clases funcionan como plantillas para crear objetos. Por ejemplo, una clase SuperHeroe puede tener métodos como volar() y atributos como nombre.

Los 4 pilares de la POO

Abstracción: Resumir lo esencial de un objeto y ocultar los detalles innecesarios.
Encapsulamiento: Proteger los datos internos de un objeto, exponiendo solo lo necesario.
Herencia: Permitir que una clase hija herede atributos y métodos de una clase padre.
Polimorfismo: Permitir que diferentes clases respondan de manera distinta a un mismo método.

Abstracción

Extraer las características esenciales de un objeto y ocultar los detalles complejos.

// Solo exponemos lo necesario de la clase
abstract class Vehiculo {
  abstract moverse(): void;
}

class Auto extends Vehiculo {
  moverse() {
    console.log("El auto avanza sobre ruedas");
  }
}

const miAuto = new Auto();
miAuto.moverse(); // "El auto avanza sobre ruedas"

Explicación:
La clase Vehiculo es una abstracción. No interesa cómo se mueve, solo que puede moverse. Cada subclase implementa el detalle.

Encapsulamiento

Proteger los datos internos de un objeto y exponer solo una interfaz controlada.

class CuentaBancaria {
  private saldo: number;

  constructor(saldoInicial: number) {
    this.saldo = saldoInicial;
  }

  depositar(monto: number) {
    this.saldo += monto;
  }

  obtenerSaldo(): number {
    return this.saldo;
  }
}

const cuenta = new CuentaBancaria(1000);
cuenta.depositar(500);
// cuenta.saldo = 99999; // Error: saldo es privado
console.log(cuenta.obtenerSaldo()); // 1500

Explicación:
El atributo saldo está protegido y solo puede ser modificado mediante métodos públicos.

Herencia

Permitir que una clase hija herede atributos y métodos de una clase padre.

class Animal {
  nombre: string;
  constructor(nombre: string) {
    this.nombre = nombre;
  }

  hacerSonido() {
    console.log("Algún sonido...");
  }
}

class Perro extends Animal {
  hacerSonido() {
    console.log("Guau!");
  }
}

const miPerro = new Perro("Rex");
miPerro.hacerSonido(); // "Guau!"

Explicación:
Perro hereda de Animal y puede sobreescribir el método hacerSonido.

Polimorfismo

Permitir que diferentes clases respondan de manera distinta a un mismo método.

const animales: Animal[] = [
  new Perro("Rex"),
  new Gato("Michi"),
];

animales.forEach(animal => animal.hacerSonido());
// "Guau!"
// "Miau!"

Explicación:
Aunque ambos son Animal, cada subclase implementa su propia versión de hacerSonido.

2. ¿Qué es SOLID?

SOLID es el acrónimo de cinco principios de diseño para la POO, propuestos por Robert C. Martin (“Uncle Bob”).

Su objetivo es ayudarte a escribir código:

Más limpio
Más mantenible
Más flexible y escalable

Los cinco principios son:

Single Responsibility Principle (SRP) – Responsabilidad Única
Open/Closed Principle (OCP) – Abierto/Cerrado
Liskov Substitution Principle (LSP) – Sustitución de Liskov
Interface Segregation Principle (ISP) – Segregación de Interfaces
Dependency Inversion Principle (DIP) – Inversión de Dependencias

3. Los principios SOLID explicados con ejemplos

1. Principio de Responsabilidad Única (SRP)

Cada clase o componente debe tener una sola responsabilidad.

Mal ejemplo (TypeScript):

class Factura {
  calcularTotal() { /* ... */ }
  imprimir() { /* ... */ }
  guardarEnBD() { /* ... */ }
}

Esta clase hace demasiadas cosas.

Mejor ejemplo (TypeScript):

class FacturaCalculo { calcularTotal() { /* ... */ } }
class FacturaImpresion { imprimir() { /* ... */ } }
class FacturaPersistencia { guardarEnBD() { /* ... */ } }

Frontend con React:

❌ Un componente que muestra y guarda datos al mismo tiempo:

function UserProfile({ user }) {
  // Guarda y muestra datos juntos (mala práctica)
  function saveUser() {
    // lógica de guardado
  }

  return (
    <div>
      <span>{user.name}</span>
      <button onClick={saveUser}>Guardar</button>
    </div>
  );
}

✅ Separando responsabilidades:

function UserProfileView({ user }) {
  return <span>{user.name}</span>;
}

function UserProfileSave({ user, onSave }) {
  return <button onClick={() => onSave(user)}>Guardar</button>;
}

// Uso
<UserProfileView user={user} />
<UserProfileSave user={user} onSave={saveUser} />

Explicación:
Cada componente tiene una función clara: uno muestra datos, otro los guarda.

2. Principio de Abierto/Cerrado (OCP)

Las clases deben estar abiertas para extensión pero cerradas para modificación.

Mal ejemplo (TypeScript):

class SuperHeroe {
  habilidad: string;
  usarHabilidad() {
    if (this.habilidad === "volar") { /* ... */ }
    // Si agrego más habilidades, tengo que modificar la clase.
  }
}

Mejor ejemplo (TypeScript):

class SuperHeroe {
  usarHabilidad() { /* implementación base */ }
}

class SuperHeroeVolador extends SuperHeroe {
  usarHabilidad() { /* volar */ }
}

React Frontend:

❌ Mal ejemplo (modificando para cada tipo de botón)

function Button({ type, ...props }) {
  if (type === "primary") return <button className="blue" {...props} />;
  if (type === "danger") return <button className="red" {...props} />;
  // Cada vez hay que modificar esta función para agregar un tipo nuevo
}

En vez de modificar un componente para cada variante, extiéndelo o compón con props.

✅ Buen ejemplo (usando composición)

function Button({ children, className, ...props }) {
  return <button className={className} {...props}>{children}</button>;
}

// Extender sin modificar:
function PrimaryButton(props) {
  return <Button className="blue" {...props} />;
}

function DangerButton(props) {
  return <Button className="red" {...props} />;
}

function App() {
  return (
    <div>
      <PrimaryButton onClick={() => alert('Primario')}>
        Botón Primario
      </PrimaryButton>
      <DangerButton onClick={() => alert('¡Cuidado!')}>
        Botón de Peligro
      </DangerButton>
    </div>
  );
}

Explicación:
Se pueden crear nuevos tipos de botones sin modificar el componente base.

3. Principio de Sustitución de Liskov (LSP)

Las clases hijas deben poder usarse como sus padres, sin romper la aplicación.

Mal ejemplo (TypeScript):

class Ave { volar() {} }
class Pinguino extends Ave { volar() { throw new Error("No puedo volar"); } }

Si reemplazo Ave por Pinguino, ¡el código se rompe!

Mejor ejemplo:

class Ave {}
class AveVoladora extends Ave { volar() {} }
class Pinguino extends Ave {}

En React:

❌ Mal ejemplo (hijo rompe comportamiento esperado)

function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />;
}

function ReadOnlyInput(props) {
  // No acepta onChange, rompe el contrato
  return <input value={props.value} readOnly />;
}

✅ Mejor ejemplo

// Componente base: Input editable
function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />;
}

// Variante: Input solo lectura, pero sigue aceptando onChange para cumplir LSP
function ReadOnlyInput({ value, onChange }) {
  return <input value={value} readOnly onChange={onChange} />;
}

// Componente de formulario que puede alternar entre editable y solo lectura
function Formulario({ readOnly }) {
  const [valor, setValor] = React.useState("Texto inicial");

  // Elegimos el componente según la prop readOnly
  const InputComponent = readOnly ? ReadOnlyInput : Input;

  return (
    <div>
      <label>
        Nombre:
        <InputComponent
          value={valor}
          onChange={e => setValor(e.target.value)}
        />
      </label>
      <p>Valor actual: {valor}</p>
    </div>
  );
}

// Ejemplo de uso en tu app principal
function App() {
  const [soloLectura, setSoloLectura] = React.useState(false);

  return (
    <div>
      <button onClick={() => setSoloLectura(prev => !prev)}>
        {soloLectura ? "Cambiar a editable" : "Cambiar a solo lectura"}
      </button>
      <Formulario readOnly={soloLectura} />
    </div>
  );
}

Explicación:
ReadOnlyInput sigue aceptando las mismas props, aunque ignore algunas, no rompe el contrato.

4. Principio de Segregación de Interfaces (ISP)

No fuerces a implementar métodos que no se necesitan.

Mal ejemplo (TypeScript):

interface SuperHeroe {
  volar(): void;
  nadar(): void;
}

class Ironman implements SuperHeroe {
  volar() {}
  nadar() { /* Ironman no nada, pero debe implementar igual */ }
}

Mejor ejemplo:

interface Volador { volar(): void; }
interface Nadador { nadar(): void; }

class Ironman implements Volador {
  volar() {}
}

En React:

❌ Mal ejemplo (props innecesarias)

function Animal({ name, fly, swim }) {
  // Algunos animales no vuelan ni nadan
}

✅ Buen ejemplo

function Animal({ name }) {
  return <span>{name}</span>;
}

function FlyingAnimal({ name, fly }) {
  // Solo para animales que vuelan
}

function SwimmingAnimal({ name, swim }) {
  // Solo para animales que nadan
}

Explicación:
Cada componente recibe solo las props que necesita.

5. Principio de Inversión de Dependencias (DIP)

Las clases deben depender de abstracciones (interfaces), no de implementaciones concretas.

Mal ejemplo (TypeScript):

class Notificador {
  emailService = new EmailService();
  notificar() { this.emailService.enviar(); }
}

Mejor ejemplo:

interface ServicioNotificacion { enviar(): void; }

class Notificador {
  constructor(private servicio: ServicioNotificacion) {}
  notificar() { this.servicio.enviar(); }
}

En React:

❌ Mal ejemplo (componente crea su propia dependencia)

function Notification() {
  const service = new NotificationService();

  function notify() {
    service.send("Hola!");
  }

  return <button onClick={notify}>Notificar</button>;
}

✅ Buen ejemplo (la dependencia se inyecta)

import React from "react";

// Servicio de notificaciones (puede ser email, SMS, etc.)
class NotificationService {
  send(message) {
    alert(`Servicio de notificación: ${message}`);
    // Aquí podrías hacer una llamada a un API, por ejemplo.
  }
}

// Componente que usa el servicio inyectado (DIP)
function Notification({ notificationService }) {
  function notify() {
    notificationService.send("¡Hola usuario!");
  }

  return <button onClick={notify}>Notificar</button>;
}

// Ejemplo de uso en tu aplicación principal
function App() {
  // Instancia concreta del servicio de notificaciones
  const serviceInstance = new NotificationService();

  return (
    <div>
      <h1>Ejemplo de Inversión de Dependencias (DIP) en React</h1>
      <Notification notificationService={serviceInstance} />
    </div>
  );
}

export default App;

Explicación:
El componente no conoce la implementación concreta, solo usa lo que recibe.

4. Ventajas y desventajas de aplicar SOLID

Ventajas:

Código más limpio y modular.
Facilita pruebas (testing) y cambios.
Escalabilidad y mantenibilidad.

Desventajas:

Puede requerir más clases/archivos.
A veces añade complejidad innecesaria en proyectos pequeños.

5. Aplicando SOLID en JavaScript y React

Aunque JavaScript no es estrictamente orientado a objetos, puedes aplicar SOLID en frameworks como React:

SRP: Crea componentes pequeños y especializados.
OCP: Extiende componentes mediante composición y props.
LSP: Evita hacer suposiciones de tipos o estructuras internas.
ISP: Define props claras y separa componentes según su función.
DIP: Pasa datos y comportamientos por props/context, no desde dentro del componente.

Conclusión

Los principios SOLID te ayudan a escribir mejor código: más limpio, modular y fácil de mantener.

Si trabajas en backend (TypeScript) o frontend (React), empezar a aplicar SOLID te ayudará a mejorar la calidad de tus proyectos.

¿Listo para dar el salto? ¡Empieza a aplicar SOLID en tu próximo proyecto y verás la diferencia!

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

Capas en CSS: Guía Completa para Dominar la Regla @layer y Controlar la Especificidad

John Serrano (DEV) — Tue, 06 May 2025 21:19:46 +0000

Introducción: ¿Qué son las Capas de Cascada en CSS?

Las capas de cascada (cascade layers) en CSS han sido introducidas para resolver uno de los problemas más complejos y persistentes en la escritura de estilos: los conflictos de especificidad. En este artículo exploraremos cuál es exactamente ese problema y cómo la regla @layer nos ofrece una solución eficaz y moderna.

La regla @layer permite declarar estas capas de cascada, que funcionan de forma análoga a las capas en editores gráficos como Photoshop o GIMP: cada capa es un grupo independiente, pero en lugar de imágenes, gestionamos reglas CSS.

El objetivo principal es claro:

Organizar mejor el código.
Evitar los problemas clásicos de especificidad.
Reducir la necesidad de usar !important o sobreescribir selectores complejos.

El problema: La especificidad se vuelve inmanejable

Todo desarrollador que ha trabajado con CSS se ha encontrado con la frustración de querer sobrescribir estilos provenientes de otras partes del código, de librerías o frameworks externos, solo para verse atrapado en una batalla de especificidad. Tradicionalmente, para resolver estos conflictos, se han creado "metodologías" y "buenas prácticas" que, en esencia, intentan evitar que la cascada actúe, en lugar de aprovecharla. Ejemplos de estas prácticas son restringirse a usar sólo clases simples o evitar selectores anidados.

El manejo de la cascada y la especificidad ha sido durante años una de las partes más confusas de CSS. Esto se debe en parte a que pocos lenguajes basan su comportamiento en una cascada, pero también a que la forma tradicional de resolución de estilos en CSS depende de heurísticas, no de un control explícito por parte del autor.

Por ejemplo, la especificidad está basada en la suposición de que un selector más detallado (como un ID único) debería tener mayor prioridad que un selector genérico (como una clase). Sin embargo, esto no siempre refleja las verdaderas intenciones del autor, y las soluciones comunes suelen agravar el problema: añadir selectores innecesarios o recurrir al temido !important.

/* Especificidad forzada y confusa */
.overly#powerful .framework.widget {
  color: maroon;
}

.my-single_class { /* ¿Agregar IDs? */
  color: rebeccapurple; /* ¿O usar !important? */
}

La solución: Capas de cascada para un control real

Las capas de cascada permiten a los autores de CSS tomar el control total de la cascada, creando sistemas intencionados y ordenados, en lugar de depender de reglas implícitas y suposiciones.

Mediante la regla @layer y las importaciones con capa mediante @import, podemos establecer nuestras propias capas jerárquicas: desde los estilos de bajo nivel como resets y temas base, hasta las capas superiores como componentes, utilidades y sobrescrituras.

Dentro de cada capa, la especificidad sigue funcionando como siempre. Pero entre capas, los conflictos siempre se resuelven a favor de la capa con mayor prioridad, sin necesidad de escalar especificidad ni usar !important.

@layer framework {
  .overly#powerful .framework.widget {
    color: maroon;
  }
}

@layer site {
  .my-single_class {
    color: rebeccapurple;
  }
}

Las capas son ordenadas y no se acumulan como la especificidad de los selectores. Añadir más capas no incrementa su poder. Tampoco son absolutas como !important, ni arbitrarias como un z-index inflado. De hecho, por defecto, los estilos dentro de una capa son menos prioritarios que los estilos no agrupados en capas.

@layer defaults {
  a:any-link { color: maroon; }
}

/* Estilos no encapsulados en capas siempre tienen la máxima prioridad */
a {
  color: mediumvioletred;
}

Sintaxis y declaración de capas

CSS nos ofrece varias formas para declarar capas utilizando @layer o mediante @import:

Sintaxis	Descripción
`@layer nombre`	Crea una capa CSS con el nombre indicado.
`@layer`	Crea una capa anónima (sin nombre).
`@layer nombre.subcapa`	Crea una capa con subcapas anidadas.
`@layer nombre1, nombre2, ...`	Declara y ordena múltiples capas.
`@import url("archivo.css") layer(nombre)`	Importa CSS en la capa especificada.

El orden en que se definen las capas determina su prioridad en la cascada, algo fundamental para evitar conflictos de especificidad. No obstante, como veremos más adelante en esta guía, ese orden también puede ser manipulado para ajustarlo a nuestras necesidades.

A continuación, exploraremos cada una de estas sintaxis en detalle y aprenderemos a utilizarlas para construir sistemas CSS más robustos, predecibles y sostenibles.

Cómo crear y ordenar Capas en CSS

Ahora que entendemos qué son las capas de cascada y por qué resuelven problemas de especificidad, es momento de aprender a utilizarlas de forma práctica en nuestros estilos CSS. La regla @layer es sencilla en su sintaxis, pero poderosa en sus aplicaciones.

Declarando una Capa Simple

La forma más básica es declarar una capa con un nombre único y agrupar dentro de ella nuestras reglas CSS:

@layer base {
  body {
    font-family: system-ui, sans-serif;
    color: #333;
  }
}

Esta capa llamada base se comporta como un grupo. Los estilos dentro de ella competirán entre sí usando la especificidad tradicional, pero como bloque completo, base tendrá una prioridad determinada por su posición frente a otras capas.

Declarando Capas Anónimas

Si no necesitas un nombre específico, puedes crear una capa anónima:

@layer {
  h1 {
    font-size: 2rem;
  }
}

Las capas anónimas son útiles para agrupar estilos sin preocuparte por su identificación, pero su uso es menos común en proyectos grandes donde el control del orden es esencial.

Creando Subcapas Anidadas

CSS permite anidar capas creando jerarquías internas mediante subcapas:

@layer components.buttons {
  .btn {
    padding: 0.5rem 1rem;
    border-radius: 0.25rem;
  }
}

En este caso, buttons es una subcapa dentro de components. La jerarquía te da mayor control para modular tu CSS y ordenar prioridades dentro de sistemas grandes.

Declarando y ordenando Múltiples Capas

Una de las grandes ventajas de las cascade layers es que puedes declarar varias capas al mismo tiempo y establecer su orden:

@layer reset, base, components, utilities;

El orden en esta declaración es crucial:

reset tendrá la menor prioridad.
utilities tendrá la mayor prioridad dentro de las capas.

Las reglas fuera de cualquier capa siguen siendo las de máxima prioridad (salvo que uses !important).

Ejemplo claro: Controlando el orden con @layer

Observa el siguiente ejemplo. Aquí declaramos un orden específico: primero la capa reset, luego texts, y al final theme.

<button class="primary">Primer botón</button>
<button class="primary">Segundo botón</button>

<style>
  /* Declaramos el orden de las capas */
  @layer reset, texts, theme;

  @layer reset {
    button {
      padding: 30px;
    }
  }

  @layer theme {
    .primary {
      background: #3454d1;
      border: 2px outset #6381db;
      color: white; /* Color de texto en theme */
      font-size: 1rem;
      padding: 5px 10px;
      border-radius: 6px;
    }
  }

  @layer texts {
    .primary {
      color: red; /* Color de texto en texts */
    }
  }
</style>

¿Qué color se aplica?

Aunque en el flujo normal de CSS el color rojo (texts) viene después y debería prevalecer, gana la capa theme, porque hemos definido en la primera línea que theme es la capa con mayor prioridad entre las tres. Por tanto, el texto aparecerá en blanco, como define la capa theme.

Fusionando reglas de una misma Capa

Otra característica importante es que, si vuelves a declarar una capa con el mismo nombre más adelante, el navegador fusiona ambas definiciones en la misma capa, sin alterar su posición en la prioridad general.

@layer theme {
  .primary {
    color: gold; /* Nueva regla dentro de theme */
  }
}

Ahora, como ambas reglas (color: white y color: gold) están en la misma capa theme, se aplicará la última que aparezca dentro de esa capa, es decir, el color dorado.

Regla de Oro: Los estilos fuera de Capa siempre Ganan

Cualquier estilo declarado fuera de cualquier @layer (es decir, sin pertenecer a ninguna capa) se agrupará automáticamente en la capa anónima. Esta capa siempre tiene la máxima prioridad sobre cualquier capa que definas con @layer.

/* Esta regla gana siempre sobre cualquier capa */
.primary {
  color: black;
}

Por tanto, si necesitas forzar estilos al margen de tu sistema de capas, simplemente escríbelos fuera de cualquier @layer.

Importando CSS en una Capa

También puedes importar archivos CSS directamente dentro de una capa, ideal para organizar tu proyecto modularmente:

@import url("reset.css") layer(reset);
@import url("framework.css") layer(components);

Esto asegura que todo el contenido de reset.css estará encapsulado en la capa reset, evitando que choque en especificidad con otras partes de tu código.

Regla Fundamental: El orden define la Prioridad

Las capas se aplican en el orden en que se declaran, no en el orden en que el CSS es escrito dentro de ellas. Es decir, si defines primero @layer base y luego @layer components, la capa components tendrá prioridad, incluso si sus selectores tienen menor especificidad.

Ejemplo:

@layer base {
  h1 {
    color: black;
  }
}

@layer components {
  h1 {
    color: crimson;
  }
}

En este caso, el h1 será crimson porque components es una capa declarada después de base.

Ventajas claras de las Capas en CSS

Evitan la escalada de especificidad.
Reducen el uso innecesario de !important.
Permiten importar librerías sin perder el control sobre tus estilos personalizados.

Fomentan un código CSS modular, predecible y mantenible a largo plazo.

¿Para qué sirven las Capas en CSS?

Las capas (@layer) en CSS nos permiten organizar y controlar la prioridad de nuestros estilos de forma mucho más flexible que con la especificidad tradicional.

Cuando tu proyecto crece o incluyes librerías externas, la especificidad empieza a depender de factores difíciles de manejar. Con @layer, puedes definir de forma explícita qué grupo de estilos tiene prioridad sobre otro, sin necesidad de recurrir a selectores más largos o a !important.

Especificidad: El problema que resuelve @layer

Observa este ejemplo básico. Aquí usamos el mismo selector .primary varias veces. CSS simplemente aplica la propiedad del último bloque que coincide:

.primary {
  color: red;
}

.primary {
  background: #34a;
  border: 2px outset #6381db;
  color: #fff;
  padding: 5px 10px;
  border-radius: 6px;
}

.primary {
  margin: 20px;
  color: green;
}

En este caso, el color de texto será verde (color: green), ya que es el último que aparece para la propiedad color.

Especificidad: Cómo afecta cuando cambian los selectores

Ahora, hagamos los selectores un poco más específicos:

/* Especificidad: 0,2,1 */
button[class].primary {
  color: red;
}

/* Especificidad: 0,1,1 */
button.primary {
  background: #34a;
  border: 2px outset #6381db;
  color: #fff;
  padding: 5px 10px;
  border-radius: 6px;
}

/* Especificidad: 0,1,0 */
.primary {
  margin: 20px;
  color: green;
}

Aquí ya no importa tanto el orden. El navegador aplicará las propiedades siguiendo la especificidad:

Primero se aplican los estilos con menos especificidad (.primary con 0,1,0).

Luego los de especificidad media (button.primary con 0,1,1).

Por último, los más específicos (button[class].primary con 0,2,1).

🔎 Resultado:

El color rojo prevalecerá, porque el selector button[class].primary es el más específico.

Cómo @layer Cambia las Reglas del Juego

Ahora vamos a agrupar el selector más específico dentro de una capa llamada texts:

@layer texts {
  button[class].primary {
    color: red;
  }
}

button.primary {
  background: #34a;
  border: 2px outset #6381db;
  color: #fff;
  padding: 5px 10px;
  border-radius: 6px;
}

.primary {
  margin: 20px;
  color: green;
}

¿Qué ocurre ahora?

Primero, el navegador procesa la capa texts.
Luego, agrupa y aplica todos los estilos fuera de capa en lo que se llama la capa anónima.
Y por regla general, esta capa anónima siempre tiene mayor prioridad que cualquier capa declarada con @layer.

Por tanto, el color verde (color: green) volverá a ganar, incluso aunque el selector de la capa texts tenga mayor especificidad. Esto demuestra cómo @layer permite a los desarrolladores reorganizar la prioridad de estilos de forma más potente que simplemente aumentando la especificidad.

Uso de @layer con CSS Nesting

Gracias al CSS Nesting nativo, también podemos declarar capas dentro de un selector. Esto permite una estructura de código aún más ordenada y modular.

<div class="primary">Hello, John Serrano!</div>

<style>
  @layer base, theme;

  .primary {
    @layer theme {
      background: indigo;
      color: white;
    }
    @layer base {
      background: grey;
      width: 250px;
      height: 200px;
      padding: 1rem;
    }
  }
</style>

¿Cómo funciona aquí?

En la línea @layer base, theme; declaramos que la capa base se aplicará antes que la capa theme.
Así, aunque theme venga antes en el código, sus estilos ganan porque está declarada con mayor prioridad.

Si cambias esa primera línea por:

@layer theme, base;

Ahora, la capa base tendrá prioridad y el fondo gris sobrescribirá al fondo índigo.

Conclusiones

Las capas en CSS (@layer) nos permiten controlar el orden y la prioridad de los estilos de forma más clara y organizada, sin depender únicamente de la especificidad. Son una herramienta poderosa para mantener el código limpio y predecible, especialmente en proyectos grandes o con estilos externos.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

Zustand: La solución más simple y eficiente para gestión de Estado en React

John Serrano (DEV) — Sun, 27 Apr 2025 17:24:19 +0000

El manejo de estado en aplicaciones React es un desafío recurrente. Librerías como Redux o Redux Toolkit ofrecen soluciones robustas pero, en muchos casos, demasiado complejas para necesidades simples. Zustand emerge como una alternativa moderna, liviana y extremadamente intuitiva.

En este artículo te guiaré desde qué es Zustand, sus ventajas sobre otras opciones, hasta cómo implementar un contador utilizando middlewares como persist y devtools, e incluso integrar validaciones con Zod.

¿Qué es Zustand?

Zustand ("estado" en alemán) es una librería minimalista de manejo de estado para aplicaciones React. Fue creada por Poimandres (los mismos de jotai y react-three-fiber) y ofrece una API pequeña pero extremadamente poderosa.

Algunas características principales:

No depende del árbol de componentes.
No requiere boilerplate.
Trabaja de forma reactiva pero es independiente de React internamente.
Permite middlewares para persistencia, devtools, entre otros.

Comparación con Otras Soluciones

Característica	Redux	Redux Toolkit	Zustand
Boilerplate	Muy Alto	Moderado	Muy Bajo
API	Verbosa	Simplificada	Muy simple
Curva de Aprendizaje	Alta	Media	Muy Baja
Integración Devtools	Manual + Configuración extra	Integración automática	Sencilla y directa
Persistencia de Estado	Requiere configuración manual	Requiere middlewares adicionales	Integrado vía middleware
Uso fuera de componentes	Difícil	Más sencillo pero no nativo	Muy fácil
Tamaño de la librería	Grande	Medio	Pequeño (~1KB gzipped)

Como puedes observar, Zustand es ideal para quienes buscan una solución directa, moderna y altamente eficiente, mientras que Redux Toolkit representa una mejora significativa sobre Redux clásico, pero aún mantiene cierta complejidad estructural.

Creando un Store de Contador con Zustand

Primero, instalemos Zustand:

npm install zustand

Ahora, creamos el store:

// src/stores/counterStore.ts
import { create } from 'zustand'

interface CounterState {
  count: number
  increment: () => void
  decrement: () => void
  reset: () => void
}

export const useCounterStore = create<CounterState>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
  reset: () => set({ count: 0 }),
}))

Notas importantes:

El nombre useCounterStore sigue la convención de React Hooks.
El store debe estar fuera de los componentes para ser compartido globalmente.

Usando el Store en un Componente

// src/components/Counter.tsx
import { useCounterStore } from '../stores/counterStore'

const Counter = () => {
  const { count, increment, decrement, reset } = useCounterStore()

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={increment}>Incrementar</button>
      <button onClick={decrement}>Decrementar</button>
      <button onClick={reset}>Resetear</button>
    </div>
  )
}

export default Counter

Con esto tienes un contador funcional, sin necesidad de reducers, actions ni context providers.

Agregando Persistencia y Devtools

Zustand permite utilizar middlewares para ampliar funcionalidades.

Lo primero que debemos hacer es instalar la extensión Redux DevTools de Chrome para utilizar el middleware devtools.

import { devtools } from 'zustand/middleware'

// Envolvemos todo nuestro store con devtools
const usePlainStore = create(devtools((set) => ...))

Modificamos el store:

import { create } from 'zustand'
import { devtools, persist } from 'zustand/middleware'

interface CounterState {
  count: number
  increment: () => void
  decrement: () => void
  reset: () => void
}

export const useCounterStore = create<CounterState>()(
  devtools(
    persist(
      (set) => ({
        count: 0,
        increment: () => set((state) => ({ count: state.count + 1 })),
        decrement: () => set((state) => ({ count: state.count - 1 })),
        reset: () => set({ count: 0 }),
      }),
      { name: 'counter-storage' }
    )
  )
)

¿Qué logramos?:

persist guarda el estado en localStorage o sessionStorage.
devtools permite inspeccionar el estado con Redux DevTools (sin usar Redux).

Esto facilita el debuggeo y asegura que el contador persista aunque recargues la página.

Si deseas ver un ejemplo más completo, incluyendo un carrito de compras, te invito a leer el siguiente artículo 👇

Zustand: Aprende a gestionar tu estado en React una alternativa sencilla a Redux

Integrando Zod para Validaciones

Aunque Zustand no maneja formularios, en una aplicación real puedes querer validar datos antes de actualizar el estado. Para eso Zod es una excelente opción.

Instalamos:

npm install zod

Ejemplo básico para validar antes de setear:

import { z } from 'zod'

const CountSchema = z.object({
  count: z.number().min(0).max(100),
})

export const useCounterStore = create<CounterState>()(
  devtools(
    persist(
      (set) => ({
        count: 0,
        increment: () => set((state) => {
          const result = CountSchema.safeParse({ count: state.count + 1 })
          if (result.success) {
            return { count: state.count + 1 }
          }
          console.error(result.error)
          return state
        }),
        decrement: () => set((state) => {
          const result = CountSchema.safeParse({ count: state.count - 1 })
          if (result.success) {
            return { count: state.count - 1 }
          }
          console.error(result.error)
          return state
        }),
        reset: () => set({ count: 0 }),
      }),
      { name: 'counter-storage' }
    )
  )
)

Conclusión: Con Zod evitamos que el contador pase de ciertos límites definidos de manera declarativa.

Reflexión Final

Zustand representa la evolución natural de la gestión de estado en React: simplicidad, flexibilidad y potencia.

Si estás cansado del exceso de configuración de Redux o simplemente buscas una forma más intuitiva de manejar estados globales, Zustand es, sin duda, una opción que deberías considerar seriamente.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

HTML avanzado y atajos Emmet en 10 Minutos

John Serrano (DEV) — Sun, 20 Apr 2025 17:29:54 +0000

Dominar HTML y Emmet no solo mejora la productividad, sino que también garantiza la creación de sitios web accesibles, semánticos y optimizados para motores de búsqueda. En este artículo, exploraremos técnicas avanzadas de HTML y cómo Emmet puede acelerar significativamente tu flujo de trabajo.

1. HTML Semántico: Mejora de SEO y Accesibilidad

El HTML semántico utiliza etiquetas que describen claramente el propósito del contenido que encierran, facilitando la comprensión tanto para desarrolladores como para motores de búsqueda y tecnologías de asistencia.

Ejemplos de elementos semánticos:

<header>: Encabezado de una sección o página.

<nav>: Contenedor para enlaces de navegación.

<main>: Contenido principal del documento.

<article>: Contenido independiente y autocontenible.

<section>: Agrupación temática de contenido.

<aside>: Contenido complementario o lateral.

<footer>: Pie de página de una sección o documento.

Ejemplo Práctico:

<article>
  <h2>Noticias Recientes</h2>
  <p>Este es un artículo de noticias independiente.</p>
</article>

<aside>
  <h3>Artículos Relacionados</h3>
  <p>Explora más sobre este tema.</p>
</aside>

<footer>© 2025 Mi Sitio Web</footer>

El uso adecuado de estas etiquetas mejora la estructura del documento, la accesibilidad y el posicionamiento en buscadores.

Aprende los conceptos básicos de HTML y descubre por qué es fundamental para cualquier desarrollador web 👇

2. Atributos personalizados con `data-*`

Los atributos personalizados data-* permiten almacenar información adicional en elementos HTML sin afectar su presentación. Son especialmente útiles para pasar datos entre HTML y JavaScript.

Ejemplo:

<button data-product-id="123">Agregar al Carrito</button>

<script>
  const boton = document.querySelector('button');
  console.log(boton.dataset.productId); // Salida: 123
</script>

3. Imágenes responsivas con `<picture>` y `<source>`

El elemento <picture> permite servir diferentes versiones de una imagen según el tamaño de la pantalla o el dispositivo del usuario, mejorando la experiencia visual y el rendimiento.

Ejemplo:

<picture>
  <source media="(min-width: 800px)" srcset="imagen-grande.jpg">
  <source media="(min-width: 400px)" srcset="imagen-mediana.jpg">
  <img src="imagen-pequeña.jpg" alt="Descripción de la imagen">
</picture>

4. Formularios mejorados con HTML5

HTML5 introduce nuevos tipos de entrada que facilitan la validación y mejoran la experiencia del usuario.

Ejemplo:

<form>
  <label for="correo">Correo Electrónico:</label>
  <input type="email" id="correo" required>

  <label for="fecha">Fecha de Nacimiento:</label>
  <input type="date" id="fecha">

  <button type="submit">Enviar</button>
</form>

El uso de atributos como required y tipos de entrada específicos reduce la necesidad de validaciones adicionales con JavaScript.

5. Contenido interactivo con `<details>` y `<summary>`

Estas etiquetas permiten crear secciones desplegables sin necesidad de JavaScript, ideales para preguntas frecuentes o contenido adicional.

Ejemplo:

<details>
  <summary>Más Información</summary>
  <p>Este contenido se muestra al hacer clic.</p>
</details>

6. Inclusión de contenido externo con `<iframe>`

El elemento <iframe> permite incrustar contenido de otras fuentes, como videos de YouTube o mapas de Google.

Ejemplo:

<iframe 
  width="560" 
  height="315" 
  src="https://www.youtube.com/embed/ID_DEL_VIDEO" 
  title="Reproductor de video de YouTube" 
  frameborder="0" 
  allowfullscreen>
</iframe>

7. Metadatos para SEO y compartición en Redes Sociales

Las etiquetas <meta> proporcionan información sobre la página, mejorando su visibilidad en buscadores y cómo se muestra al compartir en redes sociales.

Ejemplo:

<head>
  <meta charset="UTF-8">
  <meta name="description" content="Aprende HTML avanzado en 10 minutos.">
  <meta property="og:title" content="Guía de HTML Avanzado">
  <meta property="og:image" content="miniatura.jpg">
</head>

8. Componentes Web: Elementos HTML personalizados

Los Web Components permiten crear elementos personalizados y reutilizables, encapsulando su funcionalidad y estilo.

Ejemplo:

<mi-boton></mi-boton>

<script>
  class MiBoton extends HTMLElement {
    connectedCallback() {
      this.innerHTML = `<button>Haz Clic</button>`;
    }
  }
  customElements.define('mi-boton', MiBoton);
</script>

9. Mejora de Accesibilidad con ARIA

Los atributos ARIA (Accessible Rich Internet Applications) mejoran la accesibilidad de elementos interactivos para usuarios que utilizan tecnologías de asistencia.

Ejemplo:

<button aria-label="Cerrar menú" onclick="cerrarMenu()">X</button>

10. Aumenta tu Productividad con Emmet

Emmet es una herramienta integrada en la mayoría de editores modernos (como VS Code) que permite escribir HTML y CSS mucho más rápido gracias a su sistema de abreviaciones.

¿Cómo funciona?

Simplemente escribes una abreviación y presionas Tab para expandirla a código HTML completo.

Ejemplos útiles de Emmet:

Abreviación: ul>li*3

Resultado:

<ul>
  <li></li>
  <li></li>
  <li></li>
</ul>

Abreviación: .card>h2+p

Resultado:

<div class="card">
  <h2></h2>
  <p></p>
</div>

Abreviación: form:post>input:text+input:password+button:submit

Resultado:

<form method="post">
  <input type="text">
  <input type="password">
  <button type="submit"></button>
</form>

Bonus: Multiplicación y atributos

div.box$*3 ➜

<div class="box1"></div>
<div class="box2"></div>
<div class="box3"></div>

input:email[name=email required] ➜

<input type="email" name="email" required>

✅ Consejo profesional: Usa Emmet Wrap with Abbreviation (Cmd/Ctrl + Shift + P) para envolver contenido existente con estructura Emmet.

Emmet Wrap with Abbreviation es una funcionalidad avanzada que te permite envolver código existente con una estructura HTML nueva, usando abreviaciones de Emmet.

¿Cómo se usa?

Selecciona el contenido que deseas envolver.

Presiona Cmd/Ctrl + Shift + P para abrir la paleta de comandos en VS Code.

Escribe o selecciona: "Emmet: Wrap with Abbreviation".

Escribe la abreviación, por ejemplo: div.container>ul>li*3

Presiona Enter.

Ejemplo práctico:

Supón que tienes este texto seleccionado:

Manzana
Pera
Banana

Y aplicas ul>li*3, Emmet generará:

<ul>
  <li>Manzana</li>
  <li>Pera</li>
  <li>Banana</li>
</ul>

Es ideal para reorganizar contenido rápidamente con estructuras HTML limpias.

Conclusiones

Dominar HTML moderno no se trata únicamente de conocer etiquetas básicas, sino de entender cómo construir estructuras semánticas, accesibles y optimizadas para buscadores y usuarios. Incorporar etiquetas como <section>, <article>, <figure> o <nav> no solo mejora el SEO, sino también la organización y mantenibilidad del código. Además, aprovechar atributos como loading="lazy", autofocus, required o pattern permite crear experiencias más fluidas e inteligentes sin depender siempre de JavaScript.

Por otro lado, herramientas como Emmet potencian la productividad al automatizar tareas repetitivas y facilitar la creación rápida de estructuras complejas. Funcionalidades como "Wrap with Abbreviation" permiten transformar contenido existente en HTML estructurado con solo unos atajos de teclado, lo que marca una gran diferencia en el flujo de trabajo diario.

En definitiva, aprender HTML avanzado y dominar atajos como los de Emmet es una inversión que mejora tu velocidad, tu calidad de desarrollo y tu claridad mental al enfrentar proyectos web de cualquier escala. La eficiencia no está reñida con la profesionalidad; al contrario, la potencia.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

Lazy Loading en HTML: cómo cargar imágenes de forma eficiente sin usar JavaScript

John Serrano (DEV) — Mon, 07 Apr 2025 17:01:19 +0000

Descubre cómo implementar el lazy loading de imágenes utilizando solo HTML. Aprende a mejorar la velocidad de carga de tu sitio web y el SEO sin escribir una sola línea de JavaScript.

¿Qué es el lazy loading y cómo funciona?

Cuando visitas un sitio web, el navegador descarga todos los recursos necesarios para mostrar la página correctamente: imágenes, scripts, hojas de estilo, iframes, etc. Por defecto, estos recursos se cargan incluso si están fuera del área visible del usuario, es decir, en la parte de la página que todavía no se ha desplazado (lo que se conoce como below the fold).

Este comportamiento puede ralentizar la carga inicial del sitio y afectar negativamente la experiencia del usuario, especialmente en conexiones lentas o dispositivos móviles. Para solucionar este problema, los desarrolladores aplican una técnica llamada lazy loading o carga diferida.

El lazy loading retrasa la carga de ciertos recursos (como imágenes o iframes) hasta que están a punto de aparecer en la pantalla del usuario. Esto reduce el tiempo de carga inicial, mejora el rendimiento y optimiza el uso del ancho de banda.

Lazy loading con JavaScript (enfoque tradicional)

Antes de que existiera soporte nativo en HTML, se usaban bibliotecas como LazyLoad que requerían modificar el marcado HTML. En lugar de usar el atributo src en la etiqueta <img>, se utilizaba un atributo data-src. Luego, un script detectaba cuándo la imagen entraba en el viewport y reemplazaba dinámicamente data-src por src, haciendo que la imagen se cargara justo en ese momento.

<!-- Ejemplo tradicional con JavaScript -->
<img data-src="imagen.jpg" class="lazyload" alt="Ejemplo de carga diferida">

Con esta técnica también era común añadir efectos visuales como desvanecimientos o transiciones suaves para mejorar la percepción visual de carga.

Lazy loading nativo (Recomendado y mejor opción)

El lazy loading o carga diferida es una técnica que mejora significativamente el rendimiento de los sitios web al posponer la carga de imágenes y otros recursos no esenciales hasta que realmente se necesiten, es decir, cuando están a punto de entrar en el área visible del usuario.

Desde HTML5, esta funcionalidad se puede aplicar de forma nativa mediante el atributo loading, sin necesidad de escribir JavaScript ni utilizar bibliotecas externas. Este atributo puede usarse en las etiquetas <img> y <iframe>, y permite a los navegadores modernos gestionar de forma automática y eficiente cuándo cargar estos elementos.

Internamente, los navegadores utilizan mecanismos como Intersection Observer para detectar cuándo un elemento se aproxima al viewport. Sin embargo, tú como desarrollador no necesitas preocuparte por ello: basta con añadir loading="lazy" a tus imágenes o iframes, y el navegador se encarga del resto.

<img src="imagen.jpg" loading="lazy" alt="Descripción de la imagen">
<iframe src="video.html" loading="lazy"></iframe>

Valores disponibles para loading:

lazy: Carga diferida del recurso.
eager: Carga inmediata del recurso.
auto: El navegador decide cuándo cargarlo, según su criterio.

Si no se especifica el atributo, el valor por defecto será auto.

Esta mejora nativa es compatible con la mayoría de los navegadores modernos y representa un paso importante hacia un desarrollo web más rápido, eficiente y centrado en el usuario, además de tener un impacto positivo en el SEO y en los Core Web Vitals.

¿Cómo impacta el Lazy Loading en el SEO?

Más allá de los beneficios en términos de rendimiento y experiencia de usuario, el lazy loading también puede tener un impacto directo en el posicionamiento SEO de un sitio web. Por eso, si estás trabajando en una estrategia de Marketing de Contenidos, vale la pena entender cómo esta técnica puede marcar la diferencia.

Ahora bien, es fundamental tener en cuenta que el uso de la carga diferida debe ser cuidadoso y bien planificado. Una implementación incorrecta podría afectar la visibilidad del contenido ante los motores de búsqueda, especialmente si las imágenes o iframes no se cargan correctamente o si el bot de Google no puede acceder a ellos.

Dicho esto, veamos los principales beneficios (y precauciones) que el lazy loading puede generar en el SEO de tu sitio web.

Optimización de la caché:

Aprovecha contenido precargado para acelerar la carga.
⚠️ Precaución: un uso excesivo puede provocar errores y afectar la indexación en Google.

Reducción del peso total de la página:

Disminuye el tamaño inicial de carga.
Mejora el rendimiento en conexiones lentas.
Favorece el posicionamiento, ya que a Google le gustan los sitios ligeros.

Mejora del tiempo de permanencia:

Aumenta la velocidad de carga.
Reduce el abandono por frustración del usuario.
Impacta positivamente en la tasa de conversión y el tiempo promedio de visita.

¿Cómo implementar lazy loading nativo en imágenes e iframes?

A continuación te muestro cómo utilizarlo correctamente, incluyendo ejemplos prácticos con imágenes simples, imágenes responsivas y elementos <picture>.

Lazy loading en imágenes <img>

<!-- Carga diferida: la imagen se cargará cuando entre en el viewport -->
<img src="lazy-image.jpg" loading="lazy" alt="Descripción de la imagen" />

<!-- Carga inmediata: ideal para imágenes críticas (como banners o logotipos) -->
<img src="hero-banner.jpg" loading="eager" alt="Banner principal" />

<!-- Modo automático: el navegador decide cuándo cargarla -->
<img src="auto-image.jpg" loading="auto" alt="Imagen automática" />

Lazy loading en <picture>

Cuando usas la etiqueta , solo necesitas aplicar loading="lazy" en la etiqueta que actúa como fallback. Todos los heredan este comportamiento.

<picture>
  <source media="(min-width: 42em)" srcset="normal.jpg 1x, retina.jpg 2x" />
  <source srcset="optimized.jpg 1x, optimized-retina.jpg 2x" />
  <img src="fallback.jpg" loading="lazy" alt="Imagen optimizada" />
</picture>

Lazy loading con srcset y sizes

El atributo loading="lazy" también funciona correctamente en imágenes responsivas con srcset y sizes.

<img
  src="imagen-s.jpg"
  srcset="imagen-l.jpg 1024w, imagen-m.jpg 640w, imagen-s.jpg 320w"
  sizes="(min-width: 36em) 33.3vw, 100vw"
  loading="lazy"
  alt="El lanzamiento más esperado" />

Lazy loading en iframes

Puedes aplicar lazy loading también en iframes, tanto para contenido local como embebido desde plataformas externas (como YouTube).

<!-- Iframe local -->
<iframe src="video-player.html" loading="lazy"></iframe>

<!-- Iframe externo (YouTube, Vimeo, etc.) -->
<iframe src="https://www.youtube.com/embed/Hw3VqZxFnGI" loading="lazy"></iframe>

¿Qué soporte tiene el lazy loading nativo en los navegadores?

Actualmente, más del 95% de los navegadores modernos soportan de forma nativa la carga diferida de imágenes e iframes mediante el atributo loading. Esto significa que puedes utilizarlo con total confianza en la mayoría de los entornos de navegación, sin necesidad de bibliotecas externas ni código JavaScript adicional.

Puedes ver el soporte completo a día de hoy en la siguiente tabla:

¿Cómo saber si mi navegador soporta el lazy loading nativo?

Puedes verificar si tu navegador es compatible con loading="lazy" utilizando una simple comprobación en JavaScript. Basta con verificar si la propiedad loading existe en el prototipo de los elementos HTMLImageElement o HTMLIFrameElement:

const hasNativeLazyLoadSupport = 'loading' in HTMLImageElement.prototype;

if (!hasNativeLazyLoadSupport) {
  // El navegador no soporta lazy loading nativo.
  // Aquí podrías cargar una librería como lazysizes para aplicar una solución alternativa.
}

Aunque ha día de hoy no creo que valga la pena validar esto ya que el soporte esta por un 95% según caniuse.

¿Qué ocurre si uso loading="lazy" en un navegador no compatible?

Nada grave. Si el navegador no reconoce el atributo loading, simplemente lo ignorará y cargará las imágenes o iframes como lo haría normalmente. Esto no genera errores ni afecta negativamente al comportamiento del sitio.

De hecho, esta técnica se considera una mejora progresiva:

Los navegadores modernos aprovecharán los beneficios de una carga más eficiente.
Los navegadores más antiguos seguirán funcionando correctamente, aunque sin la optimización de lazy loading.

¿Debería usar siempre el atributo loading="lazy"?

No. Aunque el atributo loading="lazy" es una excelente herramienta para optimizar el rendimiento de un sitio web, no debe aplicarse indiscriminadamente a todas las imágenes.

¿Por qué?

Aplicar loading="lazy" a imágenes que son visibles inmediatamente al cargar la página (por ejemplo, logotipos, banners principales o imágenes del above the fold) puede perjudicar la experiencia de usuario, ya que introduce una ligera demora en su visualización.

Esto sucede porque el navegador, en lugar de cargarlas de inmediato, realiza cálculos adicionales (usando Intersection Observer) para determinar cuándo cargarlas, lo cual es innecesario en este caso.

Recomendación

Usa loading="lazy" únicamente en:

Imágenes que aparecen más abajo en la página (fuera del viewport inicial).
Iframes incrustados que no forman parte del contenido principal.
Elementos multimedia que se cargan bajo demanda conforme el usuario se desplaza.

Evita usarlo en:

Imágenes críticas que forman parte del contenido inicial visible.
Elementos visuales claves para el diseño o funcionalidad inmediata.

¿Cómo saber si necesitas implementar Lazy Loading?

Si has llegado hasta este punto y aún tienes dudas sobre si tu sitio realmente necesita aplicar la estrategia de Lazy Loading, no te preocupes. Aquí te comparto algunas señales claras que pueden ayudarte a tomar una decisión fundamentada:

🔍 1. Tu sitio es lento

Utiliza herramientas como Google PageSpeed Insights, Lighthouse, **GTmetrix **o WebPageTest. Si los informes muestran que el tiempo de carga es elevado, especialmente por la cantidad de imágenes o iframes, el Lazy Loading puede ayudarte a reducir el peso inicial de la página y mejorar los tiempos de respuesta.

🛠️ 2. Tienes problemas de optimización general

Si tu sitio presenta problemas de compresión (Gzip o Brotli), uso excesivo de JavaScript, CSS sin minificar o HTML pesado, estas son señales de que necesitas optimizar la carga de recursos. Aplicar carga diferida en imágenes e iframes puede ser un paso clave dentro de un enfoque integral de optimización.

🔁 3. Exceso de redireccionamientos

Un número elevado de redireccionamientos en tu sitio puede aumentar el tiempo hasta la carga completa. Esto, combinado con recursos que se cargan innecesariamente desde el inicio, impacta negativamente en el rendimiento general. Lazy Loading ayuda a aliviar esta carga inicial.

🖼️ 4. Las herramientas de análisis te recomiendan diferir imágenes

Cuando PageSpeed Insights o Lighthouse te muestran advertencias como "Defer offscreen images", es una señal directa de que implementar Lazy Loading puede tener un impacto positivo. Estas sugerencias son indicadores técnicos concretos de que estás cargando contenido visual antes de que sea necesario.

Conclusiones

El atributo loading="lazy" es una herramienta poderosa, sencilla y ampliamente soportada para mejorar el rendimiento web. No hay razones técnicas de peso para no comenzar a utilizarlo de inmediato en todas aquellas imágenes e iframes que no se encuentren visibles al momento de cargar la página.

✅ Si el navegador soporta Lazy Loading nativo, obtendrás mejoras significativas en la velocidad de carga y en la experiencia del usuario.

❎ Si el navegador no lo soporta, el contenido se cargará normalmente, sin efectos adversos, manteniendo la retrocompatibilidad.

En resumen: implementarlo es una mejora progresiva segura, con un excelente balance entre simplicidad de aplicación y beneficios en rendimiento, SEO y usabilidad.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

Buenas prácticas para escribir commits en Git con Conventional Commits

John Serrano (DEV) — Sat, 22 Mar 2025 20:44:50 +0000

Escribir buenos mensajes de commit es fundamental para mantener un historial de cambios claro, legible y fácil de entender. Un buen commit no solo documenta qué se cambió en el código, sino también el motivo detrás de ese cambio, lo que facilita la colaboración y el mantenimiento del proyecto a largo plazo.

Sin embargo, es común encontrar problemas cuando los commits se hacen sin una estructura definida. Algunos de estos problemas incluyen:

Mensajes ambiguos o genéricos, como "cambios en el código" o "arreglado bug", que no explican qué se modificó ni por qué.
Historial difícil de leer, con commits inconsistentes que dificultan rastrear la evolución del proyecto.
Dificultad para trabajar en equipo, ya que otros desarrolladores no pueden entender rápidamente qué cambios se han hecho y cuál fue su propósito.

Para solucionar estos problemas, surge Conventional Commits, una especificación que define una estructura clara y consistente para escribir mensajes de commit.

Con este estándar, cada commit sigue un formato predefinido, lo que mejora la comprensión del historial de cambios y facilita tareas como la generación automática de versiones y changelogs.

Buenas prácticas al escribir un commit en Git

Para que un commit sea útil, debe ser claro, conciso y seguir un formato consistente. A continuación, algunas buenas prácticas para escribir commits efectivos en Git:

1. Usa el verbo en imperativo

Los mensajes de commit deben expresarse como instrucciones, no como descripciones en pasado. En lugar de "Added login validation", usa "Add login validation". Esto ayuda a mantener consistencia y claridad en el historial de cambios.

✅ Ejemplo correcto:

git commit -m "Fix login validation issue"

❌ Ejemplo incorrecto:

git commit -m "Fixed login validation issue"

2. No uses punto final ni puntos suspensivos

El mensaje del commit actúa como un título, por lo que no debe llevar puntuación al final. Los puntos suspensivos generan incertidumbre y pueden hacer que el mensaje pierda claridad.

✅ Ejemplo correcto:

git commit -m "Improve UI responsiveness"

❌ Ejemplo incorrecto:

git commit -m "Improve UI responsiveness..."

3. Sé breve: usa un máximo de 50 caracteres en el mensaje principal

Si un commit necesita más contexto, agrégalo en la descripción, pero el título debe ser corto y preciso. Un mensaje largo suele indicar que el commit agrupa demasiados cambios.

✅ Ejemplo correcto:

git commit -m "Optimize database queries"

❌ Ejemplo incorrecto:

git commit -m "Optimize database queries and refactor caching system to improve performance"

4. Agrega contexto en el cuerpo del commit si es necesario

Cuando un cambio es complejo o necesita más explicación, es mejor dividir el commit en dos partes:

El título (máximo 50 caracteres, como vimos antes).
El cuerpo con una descripción más detallada del cambio y su motivo.

✅ Ejemplo correcto:

git commit -m "Refactor authentication logic"

Improves the security of the authentication module by replacing
deprecated methods and adding token expiration checks.

Esto facilita que otros desarrolladores entiendan el "por qué" del cambio.

Estas prácticas mejoran la legibilidad y organización del historial de cambios, facilitando el mantenimiento y la colaboración en el proyecto. Siguiendo estas reglas, escribir commits efectivos será mucho más fácil.

¿Qué es Conventional Commits?

Conventional Commits es una especificación que establece una convención clara y estructurada para escribir mensajes de commit en Git. Su objetivo es hacer que el historial del repositorio sea más legible, tanto para los desarrolladores como para herramientas automatizadas.

Esta convención define un conjunto de reglas que facilitan la comprensión de los cambios en el código y permiten automatizar procesos como el versionado del proyecto, la generación de changelogs y la integración continua.

Conventional Commits está estrechamente relacionado con Semantic Versioning (SemVer), un sistema que asigna versiones en función del impacto de los cambios en el código.

Siguiendo esta convención, los commits pueden indicar si una modificación es una nueva funcionalidad, una corrección de errores o un cambio que rompe la compatibilidad con versiones anteriores.

En resumen, adoptar Conventional Commits ayuda a mejorar la colaboración en equipos de desarrollo, optimiza la trazabilidad de cambios y permite que herramientas automatizadas gestionen mejor el ciclo de vida del software.

¿Qué es Semantic Versioning (SemVer)?

Semantic Versioning (SemVer) es un estándar utilizado para asignar versiones a proyectos de software de manera clara y predecible. Se basa en tres números separados por puntos:

MAJOR.MINOR.PATCH

1.4.2
// 1 -> MAJOR
// 4 -> MINOR
// 2 -> PATCH

Por ejemplo, en la versión 2.12.7:

MAJOR (2): Se incrementa cuando hay cambios que rompen la compatibilidad con versiones anteriores.
MINOR (12): Se incrementa cuando se agregan nuevas funcionalidades sin romper compatibilidad.
PATCH (7): Se incrementa cuando se corrigen errores sin afectar funcionalidades existentes.

También es común agregar etiquetas como alpha, beta, rc o next para indicar versiones en desarrollo.

Ejemplo:
Si una librería pasa de 1.4.2 a 2.0.0, significa que ha habido un cambio importante que rompe compatibilidad.

Estructura de un commit con Conventional Commits

Conventional Commits es un estándar que define cómo escribir mensajes de commit de forma estructurada. Su formato es:

<tipo>(<scope opcional>): <descripción>

[cuerpo opcional]

[footer opcional]

Tipos de commit más comunes:

feat: Se ha agregado una nueva funcionalidad (correlaciona con MINOR en SemVer).

fix: Se ha corregido un error (correlaciona con PATCH en SemVer).

BREAKING CHANGE: Indica un cambio que rompe compatibilidad (correlaciona con MAJOR en SemVer).

Otros tipos incluyen:

docs: Cambios en la documentación.

style: Cambios de formato o legibilidad sin afectar el código.

refactor: Modificaciones sin cambios en la funcionalidad.

test: Agrega o corrige pruebas.

chore: Tareas de mantenimiento sin cambios en la funcionalidad.

build: Cambios en la configuración de compilación.

Scope en Conventional Commits

El scope es un campo opcional dentro del mensaje de commit que permite indicar el área específica del proyecto donde se realizaron los cambios. Su propósito es dar mayor claridad sobre el alcance de la modificación.

Este es especialmente útil en monorepositorios o en proyectos con múltiples módulos, ya que facilita la identificación rápida de qué parte del código se ha visto afectada.

feat(backend): Add filter payments
fix(web): Fix space between element nav

Descripción, cuerpo y nota al pie en Conventional Commits

La descripción debe ser breve, en imperativo y en tiempo presente, sin mayúscula inicial ni punto final.

El cuerpo es opcional y se usa para agregar detalles adicionales sobre el cambio. Debe seguir el mismo tono imperativo.

La nota al pie también es opcional y se usa principalmente para indicar Breaking Changes, aunque puede incluir otra información relevante.

Ejemplos en un monorepositorio multipaquete:

feat(api): add endpoint to get statistics
fix(ui): fix margin in navigation button

Si bien lo mínimo recomendable es diferenciar entre fix y feat, seguir convenciones como las de Angular ayuda a estandarizar los commits y mejorar la colaboración dentro de los equipos.

Ejemplo de commits con Conventional Commits:

Agregar una nueva funcionalidad:

feat(auth): Add auth with JWT

Corregir un error:

fix(login): Fix error valid user

Cambio que rompe compatibilidad:

feat(api)!: change the response payload structure

BREAKING CHANGE: The API now returns a JSON object with a new format.

Ruptura de compatibilidad con !

Commit con cuerpo y notas al pie:

fix(api): correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: John Serrano
Fixes #215

¿Por qué usar Conventional Commits?

Establece un estándar en el formato de los commits para todo el equipo, facilitando la colaboración.
Mantiene un historial del repositorio claro y estructurado.
Permite la generación automática del CHANGELOG.
Facilita el versionado automático del proyecto según SemVer.
Mejora la comunicación de los cambios dentro del equipo y con colaboradores externos.
Automatiza procesos de build, despliegue y publicación.
Facilita la contribución de nuevos desarrolladores al proporcionar un historial de commits organizado.

Herramientas para utilizar Conventional Commits

Existen diversas herramientas que facilitan la adopción de Conventional Commits en los proyectos, desde linters hasta automatización del versionado. A continuación, te presento algunas de las más útiles y populares:

1. Commitlint + Husky
Commitlint permite validar los mensajes de commit asegurando que sigan una convención establecida.

Husky ejecuta scripts antes de realizar ciertas acciones en el repositorio, como verificar el formato del commit o ejecutar pruebas antes de un push.

Instalación y configuración básica:

npm install --save-dev husky @commitlint/{config-conventional,cli}
npx husky install
npm set-script prepare "husky install"
npm run prepare
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

(Puedes leer más detalles en mi artículo sobre Husky).

Ver todos los detalles en mi Blog 🔥

Si quieres aprender más sobre Conventional Commits, puedes leer el artículo completo aquí 👉 Buenas prácticas para escribir commits en Git con Conventional Commits.

Conclusiones

Adoptar Conventional Commits mejora la claridad y consistencia del historial del repositorio, facilita la automatización del versionado y la generación de changelogs, y optimiza la colaboración en equipos de desarrollo.

Con herramientas como Commitlint, Husky, Semantic Release y Conventional Changelog, es posible integrar esta convención de manera eficiente en cualquier proyecto.

Implementarlas no solo mejora la documentación del código, sino que también agiliza los procesos de despliegue y mantenimiento.

Gracias por leer. ❤️

CSS FlexBox: Diseño avanzado desde cero

John Serrano (DEV) — Sun, 09 Mar 2025 21:11:59 +0000

En el diseño web moderno, la necesidad de crear interfaces flexibles y adaptables a distintos dispositivos es fundamental. CSS Flexbox (Flexible Box) es un módulo diseñado para proporcionar una manera eficiente de distribuir espacio y alinear elementos dentro de un contenedor, incluso cuando sus dimensiones son dinámicas o desconocidas.

A diferencia de los modelos de diseño tradicionales como el modelo de caja en bloque (block) o en línea (inline), Flexbox permite modificar el tamaño, orden y alineación de los elementos de manera flexible, adaptándose a diferentes pantallas y orientaciones.

Su principal ventaja es que no está restringido a una sola dirección, lo que lo hace ideal para diseños complejos y aplicaciones con necesidades dinámicas.

Aunque Flexbox es una herramienta poderosa para diseños a pequeña escala, como la distribución de elementos dentro de un componente, es importante mencionar que para diseños de mayor escala, CSS Grid suele ser una mejor opción.

¿Quieres dominar CSS Grid y mejorar tus diseños?

Si aún te cuesta organizar elementos en CSS, Grid es la clave para crear estructuras flexibles y ordenadas sin complicaciones.

CSS Grid: La guía completa para principiantes y avanzados

¿Qué es Flexbox?

Flexbox es un módulo de diseño en CSS que permite distribuir el espacio entre los elementos de un contenedor de manera eficiente, permitiendo que estos se expandan o contraigan según sea necesario.

Su funcionamiento se basa en la definición de un "contenedor flexible" que administra la colocación y el tamaño de los elementos hijos.

El modelo de Flexbox facilita tareas comunes en diseño web, como:

Centrando elementos vertical y horizontalmente.
Creando diseños responsivos sin necesidad de utilizar float o position.
Ajustando el orden de los elementos sin modificar el código HTML.
Distribuyendo espacio de manera equitativa o priorizando ciertos elementos dentro de un contenedor.

Este módulo introduce conceptos clave como el eje principal y el eje transversal, que definen la dirección en la que los elementos se distribuyen dentro del contenedor, permitiendo una mayor flexibilidad en el diseño.

Conceptos básicos y terminología

Flexbox no es solo una propiedad, sino un módulo completo con múltiples características y propiedades. Algunas de estas propiedades se aplican al contenedor principal (llamado "contenedor flexible"), mientras que otras afectan a los elementos hijos (llamados "elementos flexibles").

A diferencia de los diseños tradicionales basados en los flujos de bloque y en línea, Flexbox introduce un sistema basado en "direcciones de flujo flexible" (flex-flow directions), lo que permite una disposición más versátil de los elementos dentro del contenedor.

Para comprender cómo funciona, es clave conocer los siguientes conceptos:

Eje principal y eje transversal

Eje principal (main axis): Es la dirección en la que los elementos flexibles se distribuyen dentro del contenedor. Su orientación depende de la propiedad flex-direction, por lo que puede ser horizontal o vertical.
Inicio y fin del eje principal (main-start | main-end): Los elementos se posicionan en el contenedor comenzando desde el main-start y extendiéndose hacia main-end.
Tamaño principal (main size): Hace referencia al ancho o alto de un elemento, dependiendo de la orientación del eje principal. Este tamaño es determinado por las propiedades width o height según corresponda.

Eje transversal

Eje transversal (cross axis): Es el eje perpendicular al eje principal y su dirección se define según la orientación del eje principal.
Inicio y fin del eje transversal (cross-start | cross-end): Los elementos se organizan en líneas dentro del contenedor comenzando en cross-start y extendiéndose hacia cross-end.
Tamaño transversal (cross size): Hace referencia al ancho o alto de un elemento en la dimensión transversal. Se determina por las propiedades width o height según la orientación del eje.

Para ilustrar mejor estos conceptos, aquí tienes una imagen explicativa:

Imagen tomada de css-tricks.com.

Comprender estos conceptos es clave para dominar Flexbox, ya que permiten una mejor organización y control del diseño adaptable.

Propiedades del contenedor Flexible (Flex Container)

Imagen tomada de css-tricks.com

En Flexbox, el contenedor flexible es el elemento padre que define el contexto en el que los elementos hijos se distribuyen y alinean.

A continuación, te explico las principales propiedades aplicables al contenedor:

display

Define un contenedor flexible, permitiendo que todos sus elementos directos se conviertan en elementos flexibles. Puede adoptar los valores:

.container {
  display: flex; /* Contenedor de bloque flexible */
  display: inline-flex; /* Contenedor de línea flexible */
}

Es importante destacar que las columnas de CSS (column-count, column-width) no afectan a un contenedor flexible.

flex-direction

Establece el eje principal y la dirección en la que se organizan los elementos flexibles dentro del contenedor. Flexbox es un modelo de diseño unidireccional, por lo que los elementos pueden distribuirse en filas o columnas.

.container {
  flex-direction: row | row-reverse | column | column-reverse;
}

Los valores posibles son:

row (por defecto): Organiza los elementos de izquierda a derecha en idiomas con escritura de izquierda a derecha (ltr) y de derecha a izquierda en idiomas con escritura de derecha a izquierda (rtl).
row-reverse: Invierte la dirección de row.
column: Organiza los elementos en una columna de arriba hacia abajo.
column-reverse: Invierte la dirección de column, de abajo hacia arriba.

Ejemplo:
https://codepen.io/johnserranodev/pen/JojyJOg

flex-wrap

Determina si los elementos flexibles deben ajustarse dentro del contenedor o si pueden desbordarse a una nueva línea.

.container {
  flex-wrap: nowrap | wrap | wrap-reverse;
}

nowrap (por defecto): Todos los elementos se mantienen en una sola línea.
wrap: Los elementos se ajustan a múltiples líneas si es necesario.
wrap-reverse: Similar a wrap, pero invierte el orden de las líneas.

Ejemplo:
https://codepen.io/johnserranodev/pen/XJWaaYd

flex-flow

Es una propiedad abreviada para flex-direction y flex-wrap, que define el eje principal y el ajuste de los elementos.

.container {
  flex-flow: row nowrap;
}

justify-content

Controla la alineación de los elementos a lo largo del eje principal.

.container {
  justify-content: flex-start | flex-end | center | space-between | space-around | space-evenly;
}

flex-start (por defecto): Alinea los elementos al inicio del contenedor.
flex-end: Alinea los elementos al final del contenedor.
center: Centra los elementos dentro del contenedor.
space-between: Distribuye los elementos con espacio igual entre ellos.
space-around: Agrega espacio antes y después de cada elemento.
space-evenly: Distribuye el espacio de manera uniforme entre los elementos.

Ejemplo:
https://codepen.io/johnserranodev/pen/xbxLLaq?editors=1100

align-items

Define cómo se alinean los elementos en el eje transversal.

.container {
  align-items: flex-start | flex-end | center | baseline | stretch;
}

flex-start: Alinea los elementos al inicio del eje transversal.
flex-end: Alinea los elementos al final del eje transversal.
center: Centra los elementos en el eje transversal.
baseline: Alinea los elementos según su línea base de texto.
stretch (por defecto): Hace que los elementos ocupen todo el espacio disponible en el eje transversal.

Ejemplo:
https://codepen.io/johnserranodev/pen/WbNEEYq?editors=1100

gap, row-gap, column-gap

Define el espacio entre los elementos flexibles dentro del contenedor.

.container {
  gap: 10px;
  gap: 10px 20px; /* row-gap column gap */
  row-gap: 10px;
  column-gap: 15px;
}

Funciona como un margen mínimo entre elementos, sin afectar los bordes externos.

Ejemplo:
https://codepen.io/johnserranodev/pen/bNGrrZy?editors=1100

Te invito a leer este otro artículo donde te enseño las últimas novedades de Tailwind CSS

Tailwind CSS 4: Todas las novedades y cómo configurarlo paso a paso

Propiedades de los elementos Flexibles (Flex Items)

Imagen tomada de css-tricks.com

order

De forma predeterminada, los elementos flexibles se disponen en el orden de origen. Sin embargo, la propiedad de order controla el orden en el que aparecen en el contenedor flexible.

.item {
  order: 5; /* valor por defecto es 0 */
}

flex-grow

Esta propiedad define la capacidad de un elemento flexible para expandirse dentro del contenedor cuando hay espacio disponible. Se expresa con un valor numérico sin unidad, que funciona como un factor de proporción.

El valor indica qué parte del espacio libre debe ocupar el elemento en relación con los demás. Si todos los elementos tienen flex-grow: 1;, el espacio sobrante se distribuirá de manera equitativa entre ellos. Sin embargo, si un elemento tiene flex-grow: 2;, intentará ocupar el doble de espacio en comparación con los demás.

.item {
  flex-grow: 4; /* Valor por defecto: 0 */
}

Es importante destacar que los valores negativos no son válidos.

Ejemplo, order y flex-grow:
https://codepen.io/johnserranodev/pen/VYwzzNX?editors=1100

flex-shrink

Esta propiedad determina la capacidad de un elemento flexible para reducir su tamaño si es necesario. Funciona con un valor numérico sin unidad que indica la proporción en la que el elemento puede encogerse en comparación con los demás.

Si todos los elementos tienen flex-shrink: 1;, se reducirán de manera uniforme cuando el espacio sea insuficiente. Si un elemento tiene un valor mayor, se encogerá más rápido que los demás.

.item {
  flex-shrink: 3; /* Valor por defecto: 1 */
}

Es importante destacar que los valores negativos no son válidos.

Ver todos los detalles y ejemplos 🔥

Si quieres aprender más sobre CSS Grid con ejemplos prácticos, puedes leer el artículo completo aquí 👉 CSS FlexBox: Diseño avanzado desde cero.

Puedes ver todos los ejemplos completos acá:
https://codepen.io/collection/kkkdGZ

Conclusiones

Flexbox es una herramienta poderosa y esencial en el diseño web moderno, ya que permite distribuir y alinear elementos de manera eficiente dentro de un contenedor flexible.

Su versatilidad lo convierte en una excelente opción para crear interfaces responsivas sin necesidad de recurrir a técnicas más complejas como float o position.

Algunos puntos clave que podemos destacar sobre Flexbox son:

Control total sobre el diseño: Permite organizar los elementos en una dirección específica (horizontal o vertical), definir el tamaño de cada uno y ajustar su alineación con facilidad.
Distribución eficiente del espacio: Gracias a propiedades como justify-content, align-items y gap, es posible lograr diseños equilibrados y bien estructurados sin necesidad de hacks o márgenes negativos.
Orden dinámico de los elementos: Con la propiedad order, podemos cambiar la posición visual de los elementos sin modificar el HTML, lo que facilita la flexibilidad en la disposición de los componentes.
Adaptabilidad y responsividad: Al permitir que los elementos crezcan (flex-grow), se encojan (flex-shrink) o tengan un tamaño base (flex-basis), Flexbox ayuda a crear interfaces que se ajustan a distintos tamaños de pantalla de forma fluida.
Combinación con otras herramientas: Aunque Flexbox es ideal para la disposición de elementos en una dimensión (fila o columna), en diseños más complejos puede complementarse con CSS Grid para obtener un control total sobre la disposición del contenido.

En conclusión, Flexbox es una técnica fundamental para cualquier desarrollador web, ya que simplifica la creación de diseños flexibles, adaptables y modernos con menos código y mayor eficiencia.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

CSS Grid: La guía completa para principiantes y avanzados

John Serrano (DEV) — Sat, 01 Mar 2025 14:51:34 +0000

CSS Grid Layout (o simplemente CSS Grid) es un sistema de diseño bidimensional que ha cambiado por completo la forma en que creamos interfaces web.

Durante años, CSS nos ha permitido maquetar páginas, pero siempre con soluciones improvisadas: primero con tablas, luego con flotados (floats), posicionamiento y inline-block. Ninguno de estos métodos fue diseñado específicamente para la maquetación y, por eso, tenían muchas limitaciones (como la falta de alineación vertical).

Flexbox es un gran avance en diseño web, pero su enfoque unidimensional hace que no siempre sea la mejor opción. Aquí es donde CSS Grid brilla: es el primer módulo creado con el propósito exclusivo de resolver los problemas de diseño web, permitiéndonos estructurar nuestras interfaces de manera más intuitiva y eficiente.

En esta guía, exploraremos los conceptos clave de Grid según la versión más reciente de la especificación. No abordaremos la sintaxis obsoleta de Internet Explorer, aunque Grid sigue siendo compatible con IE 11.

Conceptos básicos de CSS Grid

Desde marzo de 2017, la mayoría de los navegadores incorporaron soporte nativo y sin prefijos para CSS Grid, incluyendo Chrome, Firefox, Safari (también en iOS) y Opera.

Por otro lado, Internet Explorer 10 y 11 lo admiten, pero con una implementación antigua y una sintaxis obsoleta. ¡El momento de empezar a usar Grid es ahora!

Para comenzar, lo primero es definir un contenedor como una cuadrícula con display: grid. Luego, se establecen las dimensiones de las filas y columnas con grid-template-columns y grid-template-rows. Finalmente, se ubican los elementos hijos dentro de la cuadrícula con grid-column y grid-row.

Al igual que Flexbox, el orden en el código fuente no afecta la posición de los elementos en la cuadrícula.

Esto significa que puedes reordenar tu diseño fácilmente con media queries, adaptándolo a distintos tamaños de pantalla con solo unas pocas líneas de CSS.

Imagina definir toda la estructura de una página y luego reorganizarla completamente para dispositivos móviles sin modificar el HTML.

CSS Grid es uno de los módulos más potentes que se han incorporado a CSS, brindando flexibilidad y control total sobre el diseño de nuestras interfaces.

Te dejo una gráfica para que sea más visual:

Imagen tomada de platzi.

Términos clave en CSS Grid

Contenedor: El elemento padre que define la cuadrícula.

Ítem: Cada elemento hijo dentro de la cuadrícula.

Línea (grid line): Las líneas horizontales y verticales que separan las celdas.

Celda (grid cell): La unidad mínima de la cuadrícula, equivalente a un solo "cuadro".

Banda (grid track): Una fila o columna completa dentro de la cuadrícula.

Área (grid area): Un conjunto de celdas que forman una región dentro de la cuadrícula.

Grid Container

Es el elemento al que se le aplica display: grid; y actúa como el contenedor principal de todos los elementos de la cuadrícula. En este ejemplo, el contenedor es el grid container.

<div class="contenedor">
  <div class="item item-1"> </div>
  <div class="item item-2"> </div>
  <div class="item item-3"> </div>
</div>

Grid Item

Son los elementos hijos directos del contenedor de la cuadrícula. En este ejemplo, los elementos item son grid items, pero sub-item no lo es.

<div class="contenedor">
  <div class="item"> </div>
  <div class="item">
    <p class="sub-item"> </p>
  </div>
  <div class="item"> </div>
</div>

Grid Line

Son las líneas divisorias que conforman la estructura de la cuadrícula. Pueden ser verticales (líneas de columna) o horizontales (líneas de fila) y se encuentran a ambos lados de una fila o columna. En este ejemplo, la línea amarilla representa una línea de columna.

Grid Cell

Es el espacio comprendido entre dos líneas de fila y dos líneas de columna adyacentes. Representa la unidad más pequeña dentro de la cuadrícula. En este ejemplo, la grid cell está ubicada entre las líneas de fila 1 y 2 y las líneas de columna 2 y 3.

Grid Track

Es el espacio comprendido entre dos líneas de la cuadrícula adyacentes. Puede representar una fila o una columna dentro de la cuadrícula. En este ejemplo, el grid track se encuentra entre la segunda y tercera línea de fila.

Grid Area

Es el espacio total delimitado por cuatro líneas de la cuadrícula. Puede estar compuesto por una o varias grid cells. En este ejemplo, el grid area se encuentra entre las líneas de fila 1 y 3 y las líneas de columna 1 y 3.

Propiedades de CSS Grid

CSS Grid se compone de una serie de propiedades que se aplican tanto al contenedor de la cuadrícula (grid container) como a los elementos de la cuadrícula (grid items).

Propiedades del Grid Container

Estas propiedades se aplican al elemento padre que define la cuadrícula:

display: grid / display: inline-grid
Define el contenedor como una cuadrícula.

grid-template-columns
Especifica el tamaño y número de columnas.

grid-template-rows
Define el tamaño y número de filas.

grid-template-areas
Permite nombrar áreas dentro de la cuadrícula.

grid-column-gap / column-gap
Espacio entre columnas.

grid-row-gap / row-gap

Espacio entre filas.

grid-gap / gap
Espacio entre filas y columnas.

justify-items
Alinea los elementos dentro de sus celdas en el eje horizontal.

align-items
Alinea los elementos dentro de sus celdas en el eje vertical.

place-items
Combinación de align-items y justify-items.

justify-content
Alinea la cuadrícula dentro del contenedor en el eje horizontal.

align-content
Alinea la cuadrícula dentro del contenedor en el eje vertical.

place-content
Combinación de align-content y justify-content.

grid-auto-columns
Define el tamaño de las columnas generadas automáticamente.

grid-auto-rows
Define el tamaño de las filas generadas automáticamente.

grid-auto-flow
Controla cómo se colocan los elementos automáticamente en la cuadrícula.

Propiedades del Grid Item

Estas propiedades se aplican a los elementos hijos dentro de la cuadrícula:

grid-column-start
Define en qué línea de columna comienza el elemento.

grid-column-end
Define en qué línea de columna termina el elemento.

grid-column
Atajo para grid-column-start y grid-column-end.

grid-row-start
Define en qué línea de fila comienza el elemento.

grid-row-end
Define en qué línea de fila termina el elemento.

grid-row
Atajo para grid-row-start y grid-row-end.

grid-area
Asigna un elemento a un área de la cuadrícula nombrada con grid-template-areas.

justify-self
Alinea un elemento dentro de su celda en el eje horizontal.

align-self
Alinea un elemento dentro de su celda en el eje vertical.

place-self
Combinación de align-self y justify-self.

¿Quieres ir un paso más allá?

Si estás interesado en potenciar tu carrera como desarrollador frontend o desarrollador Web, te recomiendo leer este artículo:

Cómo iniciar y crecer como desarrollador frontend en 2025

En él encontrarás consejos prácticos, recursos y estrategias para comenzar y avanzar en el mundo del desarrollo frontend.

Ejemplos prácticos

Crear una cuadrícula de 3 columnas y 2 filas:

.container {
  display: grid;
  grid-template-columns: 100px 200px 150px;
  grid-template-rows: 50px 100px;
}

Con la propiedad display: grid, indicamos que el elemento será un contenedor de cuadrícula. Luego, con grid-template-columns y grid-template-rows, establecemos el tamaño y la cantidad de columnas y filas que compondrán la cuadrícula.

Es importante asegurarnos de que el número de elementos hijos dentro del grid sea el adecuado para la estructura que definimos. La cantidad de filas y columnas que configuremos con grid-template-columns y grid-template-rows determinará cómo se distribuyen los elementos.

Por ejemplo, si definimos una cuadrícula de 2x2, tendremos espacio para 4 elementos; una 2x3 podrá contener 6 elementos, una 2x4 albergará 8 elementos, y así sucesivamente.

Si el número de elementos no coincide con la cantidad de celdas disponibles, pueden ocurrir dos situaciones:

Si hay más elementos de los esperados, los adicionales se colocarán automáticamente en nuevas filas sin un formato definido, a menos que establezcamos reglas específicas.
Si hay menos elementos, solo se ocuparán las celdas necesarias, y las restantes quedarán vacías.

A medida que añadimos más elementos al grid, podemos ajustar las propiedades grid-template-columns y grid-template-rows para expandir la estructura y acomodar el nuevo contenido de manera organizada.

Ver todos los detalles y ejemplos 🔥

Si quieres aprender más sobre CSS Grid con ejemplos prácticos, puedes leer el artículo completo aquí 👉 CSS Grid: La Guía Completa para Principiantes y Avanzados.

Te dejo el ejemplo final, ver ejemplo.

Conclusiones sobre CSS Grid

CSS Grid es una poderosa herramienta para diseñar layouts complejos de manera flexible y eficiente. A lo largo de este tema, hemos visto cómo estructurar cuadrículas utilizando display: grid y definir filas y columnas con grid-template-columns y grid-template-rows.

También exploramos conceptos clave como celdas, áreas, líneas y tracks, que nos permiten organizar mejor los elementos dentro del grid.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

HTML: ¿Para qué sirve y qué son sus etiquetas?

John Serrano (DEV) — Sat, 22 Feb 2025 20:58:42 +0000

Aprende HTML: Descubre cómo funciona y las etiquetas clave para estructurar sitios web. Conocer HTML es fundamental para el desarrollo web moderno, ya que permite crear páginas atractivas y bien organizadas.

En este artículo, exploraremos las funciones principales de HTML y cómo sus etiquetas te ayudan a diseñar contenido eficazmente.

¿Qué es HTML?

HTML, siglas de HyperText Markup Language (Lenguaje de Marcado de Hipertexto), es el lenguaje utilizado para estructurar y organizar el contenido de las páginas web. A través de una serie de elementos y etiquetas, HTML define la estructura básica de una página, permitiendo la inclusión de textos, imágenes, enlaces, videos y otros elementos multimedia.

Aunque no es un lenguaje de programación propiamente dicho, HTML es fundamental para el desarrollo web, ya que establece la base sobre la cual se aplican estilos con CSS y se agrega interactividad con JavaScript.

¿Para qué sirve HTML?

La principal función de HTML es proporcionar la estructura de una página web. Gracias a HTML, los desarrolladores pueden:

Definir encabezados y párrafos: Organizar el texto en secciones.
Incorporar imágenes y videos: Enriquecer el contenido con elementos multimedia.
Crear enlaces: Conectar diferentes páginas o recursos.
Construir listas y tablas: Presentar información de manera ordenada.
Formularios y botones: Permitir la interacción con los usuarios.

Además, HTML se integra con CSS para mejorar el diseño y con JavaScript para agregar funcionalidades dinámicas.

¿Qué es una etiqueta HTML?

Las etiquetas HTML son fragmentos de código que se utilizan para estructurar y definir el contenido en un documento web. Estas etiquetas, también conocidas como "tags", proporcionan instrucciones al navegador sobre cómo mostrar el texto y otros elementos en una página web, permitiendo dar formato, funcionalidad y estructura al contenido visual

Anatomía de un elemento HTML

Un elemento HTML se compone de varias partes importantes:

Etiqueta de apertura: Es el nombre del elemento, encerrado entre corchetes angulares < > (por ejemplo, <p> para un párrafo).

Contenido: El texto o los datos que aparecerán en la página.

Etiqueta de cierre: Indica el final del elemento y se parece a la etiqueta de apertura, pero con una barra / (por ejemplo, </p>).

Atributos (opcional): Proporcionan información adicional sobre el elemento y se colocan dentro de la etiqueta de apertura, como class o id.

Ejemplo con un atributo:

<p class="important">Este es un párrafo importante.</p>

En este caso, class="important" es un atributo que puede utilizarse para aplicar estilos específicos a este párrafo.

Etiquetas principales de HTML

<!DOCTYPE html>: Declara el tipo de documento y es indispensable en HTML5, garantizando que el navegador interprete correctamente el código.

<html>: Elemento raíz que contiene todo el contenido de la página web.

<head>: Sección que incluye metadatos, como el conjunto de caracteres y el título de la página.

<meta charset="UTF-8">: Establece la codificación de caracteres utilizada en el documento, siendo UTF-8 la opción más común para soportar una amplia gama de caracteres.

<title>: Define el título que aparecerá en la pestaña del navegador, proporcionando una referencia clara sobre el contenido de la página.

<body>: Contiene todos los elementos y contenido visible que se presentará al usuario en la página web.

Estructura básica de un documento HTML

Un documento HTML sigue una estructura jerárquica que facilita su interpretación por parte de los navegadores web. A continuación, se presenta un ejemplo básico:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Mi Primera Página Web</title>
  </head>
  <body>
    <h1>¡Bienvenido a mi sitio web!</h1>
    <p>Este es un párrafo de ejemplo.</p>
  </body>
</html>

¿Cuáles son las etiquetas y elementos de HTML más usados?

Existen diversas etiquetas en HTML, pero algunas de las más utilizadas incluyen:

<h1> a <h6>: Encabezados.

  <h1>Título Principal</h1>
  <h2>Subtítulo</h2>

<p>: Párrafos.

  <p>Este es un párrafo de ejemplo.</p>

<a>: Enlaces.

<img>: Imágenes, se insertan con la etiqueta <img>, utilizando el atributo src para especificar la ruta de la imagen y alt para proporcionar un texto alternativo.

  <img src="ruta/imagen.jpg" alt="Descripción de la imagen">

<ul>, <ol>, <li>: Listas no ordenadas y ordenadas.

No ordenadas: Utilizan <ul> para la lista y <li> para cada elemento.

<ul>
  <li>Elemento 1</li>
  <li>Elemento 2</li>
  <li>Elemento 3</li>
</ul>

Ordenadas: Emplean <ol> para la lista y <li> para cada elemento.

<ol>
  <li>Primer elemento</li>
  <li>Segundo elemento</li>
  <li>Tercer elemento</li>
</ol>

<table>, <tr>, <td>: Tablas.

<div> y <span>: Contenedores genéricos.

<form>, <input>, <button>: Formularios y entradas de datos.

<form action="/procesar_formulario" method="post">
  <label for="nombre">Nombre:</label>
  <input type="text" id="nombre" name="nombre" required>
  <br>

  <label for="email">Correo electrónico:</label>
  <input type="email" id="email" name="email" required>
  <br>

  <label for="mensaje">Mensaje:</label>
  <textarea id="mensaje" name="mensaje" rows="4" cols="50"></textarea>
  <br>

  <input type="submit" value="Enviar">
</form>

Estas etiquetas son esenciales para construir la estructura y el contenido de una página web de manera efectiva.

HTML Semántico

El HTML semántico mejora la accesibilidad y optimización para motores de búsqueda al utilizar etiquetas que describen su contenido, como:

<header>: Encabezado de la página o sección.

<article>: Contenido independiente y reutilizable.

<section>: Secciones temáticas.

<footer>: Pie de página.

<aside>: Contenido relacionado o complementario.

Descubre el resto de los detalles y puntos clave en mi blog:
👉 johnserrano.co/blog

Conclusiones

HTML es el pilar fundamental para la creación y estructuración de contenido en la web. Su simplicidad y accesibilidad lo convierten en una herramienta esencial tanto para principiantes como para desarrolladores experimentados.

Aunque por sí solo genera páginas estáticas, su verdadero potencial se manifiesta al combinarse con CSS y JavaScript, permitiendo el desarrollo de sitios web dinámicos e interactivos.

Dominar HTML no solo es el primer paso en el camino del desarrollo web, sino que también sienta las bases para comprender y manejar tecnologías web más avanzadas.

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️

🎥 Aprende con ejemplos prácticos

Si quieres ver HTML en acción, te dejo este video donde explico paso a paso cómo usar sus etiquetas y aplicar buenas prácticas. ¡No te lo pierdas! 👇

Husky y Lint-Staged: Cómo configurar y automatizar pre-commit hooks para test, lint y formateo

John Serrano (DEV) — Sat, 08 Feb 2025 15:14:03 +0000

En el desarrollo de proyectos JavaScript, mantener la consistencia del código y garantizar altos estándares de calidad puede resultar un reto, especialmente en equipos con múltiples colaboradores.

La integración de herramientas de automatización en el flujo de trabajo permite ejecutar de forma automática tareas esenciales como el formateo, el análisis de código (lint) y la ejecución de test antes de que se realicen commits o push.

Este artículo explora en detalle cómo configurar Husky y Lint-Staged para reforzar la calidad del código en tus proyectos JavaScript.

¿Qué es Husky y Lint-Staged?

Husky es una solución nativa para gestionar Git hooks, es decir, scripts que se ejecutan automáticamente en determinados eventos de Git (como antes de un commit o un push). Gracias a Husky, es posible asegurarse de que se cumplan una serie de comprobaciones y tareas esenciales antes de que los cambios se integren al repositorio.

Por otro lado, Lint-Staged es una herramienta que permite ejecutar comandos únicamente sobre los archivos que han sido modificados y se encuentran en estado “staged”. Esto resulta en un proceso mucho más eficiente, ya que se aplican los formateos y las validaciones únicamente en el conjunto reducido de archivos afectados, en lugar de analizar toda la base de código.

¿Por qué usar Husky y Lint-Staged?

Utilizar Husky y Lint-Staged aporta múltiples beneficios en el desarrollo de aplicaciones JavaScript:

Aseguramiento de la calidad: Garantizan que el código cumpla con las normas de estilo y calidad mediante la ejecución automática de linters, formateadores y pruebas unitarias.
Prevención de errores: Al interceptar el proceso de commit o push, se detectan y corrigen errores antes de que estos se integren a la base de código, evitando problemas en producción.
Optimización del flujo de trabajo: Lint-Staged analiza únicamente los archivos modificados, lo que reduce considerablemente el tiempo de ejecución de las tareas de validación.
Uniformidad en el equipo: Permiten que todos los colaboradores sigan los mismos estándares, asegurando la coherencia y mantenibilidad del código.

Configurando Husky y Lint-Staged

A continuación, se detalla el proceso de configuración de Husky y Lint-Staged en un entorno JavaScript, integrando herramientas fundamentales como Prettier, ESLint y Vitest.

Configurando el entorno

Imaginemos que estamos trabajando en un proyecto JavaScript en el que es imprescindible mantener un código limpio y sin errores. Para ello, configuraremos los siguientes scripts en el archivo package.json:

Prettier como formateador:
Se encargará de aplicar un formato consistente en todo el código.

npm run format

ESLint como linter:
Detecta errores y aplica buenas prácticas de codificación.

npm run lint

Vitest como framework de pruebas:
Valida que el código funcione según lo esperado mediante pruebas unitarias.

npm run test

Estos comandos se integrarán en nuestros Git hooks para que, antes de cada commit, se asegure que el código se formatea, se analiza y se prueba.

Instalar Husky y configuración

Ejecuta el siguiente comando para instalar Husky como dependencia de desarrollo:

npm install --save-dev husky

Inicializa Husky en tu repositorio (recuerda que debes haber inicializado previamente Git en el proyecto):

npx husky init

Este comando añade automáticamente un script de preparación en el package.json y crea una carpeta .husky en la raíz del proyecto que contendrá, entre otros, el hook pre-commit.

Configuración del hook pre-commit:
Edita el archivo .husky/pre-commit para incluir los comandos necesarios. Por ejemplo:

npm run format
npm run lint
npm run test

Con esta configuración, cada vez que realices un commit, Husky ejecutará estos comandos. Si alguno de ellos falla, se detendrá el proceso de commit, permitiéndote corregir los errores antes de proceder.

Instalar Lint-Staged y configuración

Añade Lint-Staged como dependencia de desarrollo:

npm install --save-dev lint-staged

Agrega el siguiente script en tu archivo package.json para facilitar la ejecución de Lint-Staged:

"scripts": {
  "lint-staged": "lint-staged"
}

Crea un archivo llamado .lintstagedrc.json en la raíz del proyecto y define los comandos a ejecutar para los archivos modificados. Por ejemplo:

{
  "*.{css,scss}": ["npx prettier . --write"],
  "*.{js,jsx,ts,tsx}": [
    "npx prettier . --write",
    "eslint --fix",
    "vitest run --environment=jsdom"
  ]
}

Con esta configuración, Lint-Staged aplicará Prettier, ESLint y Vitest únicamente en los archivos JavaScript (y sus variantes) que hayan sido modificados y añadidos al área de staging.

Para aprovechar Lint-Staged en el hook pre-commit, modifica el archivo .husky/pre-commit para que ejecute el script de Lint-Staged en lugar de correr los comandos de forma individual:

npm run lint-staged

De esta forma, el proceso de validación se optimiza al centrarse únicamente en los cambios realizados, ahorrando tiempo y recursos.

Descubre el resto de los detalles y puntos clave en mi blog:
👉 johnserrano.co/blog

Conclusiones

La integración de Husky y Lint-Staged en un proyecto JavaScript es una estrategia altamente eficaz para garantizar la calidad y consistencia del código.

Al automatizar tareas fundamentales como el formateo, el análisis estático y la ejecución de pruebas, estas herramientas permiten detectar errores de manera temprana y aseguran que el código que se integra al repositorio cumpla con los estándares establecidos.

Aunque la configuración inicial pueda parecer compleja, los beneficios a largo plazo como la reducción de errores, un proceso de desarrollo más ágil y una mayor uniformidad en el equipo justifican ampliamente la inversión de tiempo y esfuerzo.

La implementación de Husky y Lint-Staged no solo mejora la calidad del producto final, sino que también fomenta las buenas prácticas y optimiza el flujo de trabajo, permitiéndote concentrar esfuerzos en la creación de soluciones robustas y escalables en JavaScript.

Espero que esta guía te resulte de utilidad y te anime a incorporar estas prácticas en tus proyectos. ¡Éxito en tus desarrollos!

Te invito a visitar mi blog, donde encontrarás más contenido sobre JavaScript, React, CSS, IA, buenas prácticas y mucho más. 👉 johnserrano.co/blog ¡No te lo pierdas!

Gracias por leer. ❤️