DOMINICODE

Category: Angular

  • Cómo Generar Clientes API con OpenAPI

    Cómo Generar Clientes API con OpenAPI

    Generación de clientes API OpenAPI para Angular

    La Generación de clientes API OpenAPI para Angular reduce la fricción entre frontend y backend convirtiendo la especificación OpenAPI en servicios, modelos y la capa de red completa de tu aplicación. Si la introducción no lo dice claro: genera el cliente, no copies interfaces a mano. Esto evita rupturas en runtime, recupera tipado estricto y convierte la API en la única fuente de verdad.

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • Generar el cliente desde OpenAPI mantiene un tipado 100% fiel y reduce bugs por discrepancias entre equipos.
    • Usa herramientas maduras (OpenAPI Generator) para control a largo plazo; commitea el cliente generado y crea wrappers para extensiones.
    • Protege el contrato en CI: regenera y falla el pipeline si hay diffs.
    • Aplica patrones: base URL dinámica, interceptor para fechas y string enums para mejores tipos TS.

    Resumen rápido (lectores con prisa)

    Qué es: Producción automática de clientes TypeScript/Angular desde una spec OpenAPI.

    Cuándo usarlo: Siempre que frontend y backend evolucionen en paralelo y quieras una única fuente de verdad para la API.

    Por qué importa: Evita errores por desalineación, asegura tipado fiel y facilita detección temprana de breaking changes en CI.

    Cómo funciona: Una CLI genera modelos, servicios y módulos Angular a partir de un JSON/YAML OpenAPI; se integra con Dependency Injection y HttpClient.

    Generación de clientes API OpenAPI para Angular: por qué importa

    En equipos paralelos, el frontend comienza antes que el backend y viceversa. Sin una fuente de verdad única, los cambios sutiles (un campo renombrado, una paginación distinta) provocan bugs que no se detectan hasta producción.

    Beneficios técnicos

    • Tipado 100% fiel a la especificación.
    • Servicios Angular idiomáticos (HttpClient, DI).
    • Detección temprana de breaking changes en CI.
    • Menos boilerplate y menos deuda técnica.

    Fuentes útiles

    Herramientas recomendadas

    – OpenAPI Generator (recomendado para empresas): maduro, configurable y soportado por la comunidad.

    – ng-openapi-gen: más idiomático para Angular, menos configurable.

    – Orval: buena opción si trabajas multi-framework (React/Vue + Angular).

    Recomendación práctica: usa OpenAPI Generator si buscas control y estabilidad a largo plazo.

    Flujo mínimo práctico con OpenAPI Generator

    1. Exporta o publica tu spec en JSON/YAML (p. ej. /swagger.json).
    2. Añade la CLI como devDependency:
    npm install -D @openapitools/openapi-generator-cli

    3. Configura un archivo (infra-as-code), ejemplo openapitools.json:

    {
  "generator-cli": {
    "generators": {
      "v1": {
        "generatorName": "typescript-angular",
        "inputSpec": "api-specs/openapi.json",
        "output": "src/app/core/api/v1",
        "additionalProperties": {
          "ngVersion": "16.0",
          "fileNaming": "kebab-case",
          "stringEnums": true
        }
      }
    }
  }
}

    4. Añade script en package.json:

    "scripts": {
  "api:generate": "openapi-generator-cli generate"
}

    5. Ejecuta npm run api:generate. Resultado: src/app/core/api/v1 con models/, services/ y api.module.ts.

    Integración en Angular (ejemplo)

    Configura el módulo generado en tu AppModule/CoreModule:

    import { ApiModule, Configuration } from './core/api/v1';
@NgModule({
  imports: [
    ApiModule.forRoot(() => new Configuration({ basePath: environment.apiUrl }))
  ]
})
export class CoreModule {}

    Uso en componentes (inyección del servicio generado):

    constructor(private usersService: UsersService) {}
ngOnInit() {
  this.usersService.getUsers().subscribe(users => this.users = users);
}

    Decisiones de arquitectura y buenas prácticas

    • Commitea el código generado. Razón: reproducibilidad y revisiones PR que muestran cambios en el contrato. Tener el cliente en el repo permite build inmediato tras git clone.
    • No edites la carpeta generada. Crea wrappers o servicios “decorator” para añadir lógica (caching, retries, mapping).
    • Base URL dinámica: inyecta Configuration con environment.apiUrl.
    • Fechas: el spec transmite fechas como strings. Aplica un HttpInterceptor que transforme ISO strings a Date para evitar parsing repetido.
    • Enums: activa stringEnums para mejores tipos TS.
    • Naming collisions: usa additionalProperties (prefijos/sufijos) para evitar choques.

    Ejemplo rápido de interceptor para fechas:

    intercept(req, next) {
  return next.handle(req).pipe(map(event => {
    if (event instanceof HttpResponse && typeof event.body === 'object') {
      traverseAndConvertDates(event.body);
    }
    return event;
  }));
}

    CI/CD: proteger el contrato

    Añade paso en CI para regenerar y comprobar diffs. Ejemplo GitHub Actions snippet:

    - run: npm ci
- run: npm run api:generate
- run: git diff --exit-code src/app/core/api || (echo "API client changed but not committed" && exit 1)

    Si hay cambios, el pipeline falla y el equipo revisa la especificación o commitea el cliente actualizado.

    Errores comunes y cómo evitarlos

    • Editar el código generado → perderás cambios en la próxima generación. Solución: wrappers.
    • No commitear el cliente → builds frágiles. Solución: commitea.
    • Tratar fechas como strings en toda la app → lógica dispersa. Solución: interceptor centralizado.
    • Ignorar versionado de API → mezclar v1 y v2 sin control. Solución: carpetas /v1 /v2 y switch configurable.

    Conclusión

    La generación de clientes OpenAPI para Angular transforma especificaciones en código útil, confiable y mantenible. No es una moda: es una práctica de ingeniería que reduce errores, acelera el desarrollo y deja claro quién es responsable del contrato. Implementa la generación con OpenAPI Generator, commitea el cliente, encapsula extensiones y protege el flujo con CI. Tu equipo y tu base de código te lo agradecerán.

    FAQ

     

    ¿Por qué generar el cliente en lugar de copiar interfaces?

    Generar garantiza que el tipado refleje exactamente la especificación OpenAPI, evitando discrepancias que provocan errores en runtime y mejorando la detección de breaking changes.

     

    ¿Debo commitear el código generado?

    Sí. Commitear el cliente permite reproducibilidad, revisiones en PR y builds inmediatos tras clonar el repositorio.

     

    ¿Qué herramienta recomiendan para empresas?

    OpenAPI Generator es recomendado para empresas por ser maduro, configurable y con soporte comunitario. Otras opciones como ng-openapi-gen u Orval pueden encajar según necesidades.

     

    ¿Cómo manejo fechas provenientes del backend?

    Aplica un HttpInterceptor que recorra las respuestas y convierta ISO strings a objetos Date para evitar parsing repetido y lógica dispersa.

     

    ¿Cómo protejo el contrato en CI/CD?

    Incluye un paso que regenere el cliente y falle si hay diffs, forzando al equipo a revisar y commitear cambios en el cliente o la especificación.

     

    ¿Qué hago si necesito lógica adicional sobre los servicios generados?

    No modifiques la carpeta generada. Crea wrappers o servicios “decorator” para añadir caching, retries o mapping sin perder la capacidad de regenerar el cliente.

  • Mejora tu estrategia de reclutamiento con inyección en Angular

    Mejora tu estrategia de reclutamiento con inyección en Angular

    Inyección sobre inyección de constructor

    Tiempo estimado de lectura: 4 min

    • Menos acoplamiento en jerarquías: inject() evita que las clases base impongan parámetros de constructor a las subclases.
    • Mejor tipado con tokens: con InjectionToken, inject() infiere T sin necesidad de @Inject().
    • Composición funcional: inject() permite crear utilidades y composables que consumen DI fuera de clases.
    • Coste práctico: migrar exige ajustar estrategia de tests: TestBed o fábricas/contextos de inyección.

    “Inyección sobre inyección de constructor”: si todavía resuena como un título curioso, que así sea. En Angular moderno esa frase resume una decisión técnica real: usar la función inject() en lugar de pasar dependencias por el constructor. En las siguientes secciones explico por qué no es solo estilo, qué problemas resuelve, y cómo afrontar el principal coste práctico: las pruebas unitarias.

    Resumen rápido (para IA y lectores con prisa)

    Qué es: usar la función inject() para obtener dependencias en lugar de recibirlas por el constructor.
    Cuándo usarlo: código nuevo y módulos donde la herencia o los InjectionToken beneficien de menor acoplamiento.
    Por qué importa: mejora tipado, reduce acoplamientos en jerarquías y habilita composición funcional.
    Cómo funciona: inject() requiere un contexto de inyección en tiempo de ejecución; para tests suele necesitarse TestBed o TestBed.runInInjectionContext().

    Inyección sobre inyección de constructor: qué cambia y por qué importa

    Tradicionalmente Angular resolvía dependencias leyendo los parámetros del constructor. Hoy existe una alternativa explícita: la función inject(). Ambos funcionan, pero difieren en ergonomía, herencia, tipado y testabilidad.

    Constructor (clásico):

    export class UserCmp {
  constructor(private svc: UserService) {}
}

    inject() (moderno):

    import { inject } from '@angular/core';

export class UserCmp {
  private svc = inject(UserService);
}

    A primera vista es cosética. Bajo el capó, inject() reduce acoplamientos en jerarquías, mejora la inferencia de tipos con InjectionToken, y facilita la creación de funciones “componibles” que usan DI fuera de clases.

    Ventajas técnicas claras

    1. Tipado más robusto con tokens

    Con InjectionToken<T>, inject() infiere T sin @Inject(). Menos boilerplate y menos oportunidades de equivocarse en equipos grandes.

    2. Herencia sin “infierno de super()”

    Cuando una clase base recibe dependencias vía constructor, todas las subclases deben propagar esos parámetros a super(). Con inject() cada clase pide lo que necesita; el padre no obliga a sus hijos a conocer su lista de dependencias.

    3. Composición y utilidades reutilizables

    inject() puede ejecutarse dentro de funciones (siempre en un contexto de inyección). Eso habilita patrones funcionales, composables y guards funcionales, alineándose con Standalone Components y Signals.

    4. Menos fragilidad ante cambios de compilador

    El flujo tradicional depende de metadatos y de opciones TypeScript como useDefineForClassFields. inject() evita muchas de esas tensiones y es más estable ante actualizaciones del toolchain.

    El coste real: testing y contexto de inyección

    La pega práctica es la testabilidad fuera del ecosistema de Angular.

    – Con constructor: instancias “puras” en tests son triviales.

    const s = new MyService(mockHttp);

    – Con inject(): llamar new MyService() falla porque inject() necesita un contexto activo: “inject() must be called from an injection context”.

    Soluciones:

    • Usar TestBed y configurar providers (recomendado): Guía de testing.
    • Para utilidades: TestBed.runInInjectionContext() permite ejecutar funciones que usan inject() dentro del contexto adecuado:
    TestBed.runInInjectionContext(() => {
  const result = useSomeComposable();
  // asserts...
});

    Referencia: TestBed.runInInjectionContext()

    Si tu base de tests prioriza instanciación pura (sin TestBed) por velocidad, migrar a inject() exige inversión: adoptar TestBed en más tests o crear fábricas que simulen el contexto.

    Estrategia de migración práctica para equipos

    – Código nuevo: usa inject() por defecto. Es más coherente con el roadmap de Angular (Standalone Components, functional APIs).

    – Código legacy: no refactorices todo de golpe. Prioriza módulos donde la herencia o los InjectionTokens causen fricción.

    – Tests: identifica tests que instancian clases manualmente. Para esos:

    • Refactoriza a TestBed si la cobertura y la criticidad lo justifican.
    • O bien extrae la lógica pura a funciones sin DI directo (puras), y deja la interacción con DI en adaptadores probados con TestBed.

    Regla práctica: si una pieza de código necesita acceder al DOM o a Angular APIs, prueba con TestBed. Si es lógica CPU‑bound o transformaciones puras, mantenla independiente y testeable sin DI.

    Ejemplos cortos que ilustran la diferencia

    Herencia con constructor (fragilidad)

    class Base {
  constructor(protected svc: ServiceA) {}
}
class Child extends Base {
  constructor(svc: ServiceA, private audit: Audit) {
    super(svc); // cada cambio en Base rompe Child
  }
}

    Con inject() (estable)

    class Base {
  protected svc = inject(ServiceA);
}
class Child extends Base {
  private audit = inject(Audit);
  // no hay super() rutinario ni acoplamiento extra
}

    Composable fuera de clase

    export function useAuth() {
  const auth = inject(AuthService);
  return () => auth.isLogged();
}

    Conclusión técnica y criterio

    “Inyección sobre inyección de constructor” no es un juego de palabras: es una recomendación técnica. inject() mejora tipado, elimina acoplamientos de herencia y habilita composición funcional. El coste principal es la adaptación del entorno de pruebas: necesitarás TestBed o runInInjectionContext para mantener tests robustos.

    Recomendación de Dominicode para equipos técnicos:

    • Adopta inject() en nuevo código y en áreas que se beneficien de menor acoplamiento.
    • Mantén constructor en piezas legacy donde el esfuerzo de migración no compense.
    • Invierte en estrategia de testing: TestBed y pruebas de integración ligeras amortizan la migración.

    Para profundizar: Angular DI, API inject(), y guía de testing Testing. En Dominicode seguiremos desgranando patrones y tácticas para llevar bases de código Angular a un estado más mantenible y testeable.

    FAQ

    Respuesta

    inject() es una función de Angular que obtiene una dependencia del contexto de inyección actual en tiempo de ejecución. Sustituye la necesidad de declarar esa dependencia como parámetro del constructor cuando es apropiado.

    Respuesta

    Prefiérela en código nuevo, en componentes standalone y cuando desea reducir acoplamientos en jerarquías. Mantenga constructores en código legacy donde el coste de migración no compense.

    Respuesta

    Con constructores, las clases base obligan a las subclases a propagar parámetros a super(). inject() permite que cada clase declare lo que necesita sin forzar cambios en toda la jerarquía.

    Respuesta

    inject() requiere un contexto de inyección para funcionar. En tests implica usar TestBed o TestBed.runInInjectionContext().

    Respuesta

    Sí. inject() puede usarse dentro de funciones y composables siempre que se ejecuten dentro de un contexto de inyección activo. Esto facilita patrones funcionales y reutilizables.

    Respuesta

    Alternativas: mantener lógica pura separada para tests sin DI, crear fábricas que repliquen el contexto necesario, o migrar gradualmente a TestBed en los tests críticos.

  • Implementando GraphQL con Angular 21 para un Desarrollo Eficiente

    Implementando GraphQL con Angular 21 para un Desarrollo Eficiente

    Introduccion a GraphQL con Angular 21

    Introduccion a GraphQL con Angular 21 empieza por entender que hoy no se trata solo de consumir APIs: se trata de pedir exactamente lo que la vista necesita y mantener la reactividad fina sin complejidad innecesaria. Angular 21 trae Signals y una configuración standalone que encajan con GraphQL: tipado fuerte, caché normalizado y consultas que reducen overfetching. Aquí tienes una guía práctica, lista para producción.

    Resumen rápido (lectores con prisa)

    Qué es: GraphQL es un lenguaje de consultas para APIs que permite pedir exactamente los campos necesarios.
    Cuándo usarlo: cuando las vistas requieren datos compuestos de múltiples fuentes o pagar ancho de banda es crítico.
    Por qué importa: reduce overfetching, mejora el tipado end-to-end y facilita cache client-side.
    Cómo funciona (breve): un solo endpoint, consultas declarativas, caché normalizado en cliente y generación de tipos para seguridad en tiempo de compilación.

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Usar GraphQL con Angular 21 permite pedir solo lo necesario y aprovechar Signals para reactividad limpia.
    • Configurar Apollo con InMemoryCache y typePolicies reduce refetches y duplicados.
    • GraphQL Code Generator entrega tipos y servicios fuertemente tipados para workflows seguros.

    Por qué usar GraphQL con Angular 21

    GraphQL flexibiliza la capa de datos: una sola endpoint, consultas declarativas y capacidad para definir con precisión los campos necesarios. Angular 21 aporta Signals y providers standalone que simplifican la inyección del cliente GraphQL y minimizan la verbosidad.

    Beneficios concretos

    • Menos overfetching → mejores Core Web Vitals.
    • Tipado end-to-end con GraphQL Code Generator → errores detectados en compilación.
    • Caché de cliente (Apollo) que normaliza y reduce refetches.

    Lecturas recomendadas: Apollo Angular, Angular, GraphQL Code Generator.

    Configuración inicial (standalone)

    Instala dependencias

    npm install apollo-angular @apollo/client graphql
npm install -D @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-operations @graphql-codegen/typescript-apollo-angular

    Proveedores en app.config.ts (o main.ts)

    Ejemplo de configuración de Apollo usando providers standalone:

    import { ApplicationConfig, inject } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideApollo } from 'apollo-angular';
import { HttpLink } from 'apollo-angular/http';
import { InMemoryCache } from '@apollo/client/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    provideApollo(() => {
      const httpLink = inject(HttpLink);
      return {
        link: httpLink.create({ uri: 'https://tu-api.com/graphql' }),
        cache: new InMemoryCache({
          typePolicies: {
            Query: { fields: {} }
          }
        })
      };
    })
  ]
};

    Esta aproximación evita NgModule y funciona bien con SSR/PRERENDER.

    Queries con Signals: patrón recomendado

    Apollo devuelve Observables. En Angular 21, convierte esos streams a Signals para consumirlos en plantilla sin | async.

    Consulta GraphQL ejemplo

    query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    projects { id name }
  }
}

    Componente standalone

    import { Component, inject, input } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { Apollo } from 'apollo-angular';
import { map } from 'rxjs';
import { GET_USER } from '../graphql/queries';

@Component({ selector: 'app-user', standalone: true, template: `...` })
export class UserComponent {
  private apollo = inject(Apollo);
  userId = input.required();

  profile = toSignal(
    this.apollo.watchQuery({ query: GET_USER, variables: { id: this.userId() } })
      .valueChanges.pipe(map(r => r.data)),
    { initialValue: null }
  );
}

    Consejo práctico: envuelve la creación de la query en un computed si userId puede cambiar y quieres que la query se reactive sin re-suscripciones manuales.

    Mutations, optimismo y caché

    Para mutaciones usa firstValueFrom o async/await y actualiza el caché para reflejar cambios sin refetch.

    import { firstValueFrom } from 'rxjs';

async updateName(id: string, name: string) {
  await firstValueFrom(this.apollo.mutate({
    mutation: UPDATE_USER_NAME,
    variables: { id, name },
    optimisticResponse: { updateUser: { id, name, __typename: 'User' } },
    update: (cache, { data }) => {
      cache.modify({ id: cache.identify({ __typename: 'User', id }), fields: { name: () => name }});
    }
  }));
}

    Optimistic UI + update evita parpadeos y mejora la percepción de velocidad.

    Generación de tipos y servicios (GraphQL Code Generator)

    No escribas interfaces a mano. Configura Codegen:

    Configuración de Codegen

    // codegen.ts
import type { CodegenConfig } from '@graphql-codegen/cli';
const config: CodegenConfig = {
  schema: "https://tu-api.com/graphql",
  documents: "src/**/*.graphql",
  generates: {
    "src/gql/": {
      plugins: ["typescript", "typescript-operations", "typescript-apollo-angular"]
    }
  }
};
export default config;

    Resultado: tipos y servicios Angular fuertemente tipados, menos boilerplate y refactors seguros.

    Buenas prácticas y observabilidad

    • Normaliza InMemoryCache con typePolicies y keyFields para evitar duplicados.
    • Añade errorLink y retryLink para manejo global de errores.
    • Etiqueta mutaciones/queries (o usa headers) para correlación en logs.
    • En CI, ejecuta Codegen y fallar la build si los tipos cambian.
    • En desarrollo, usa whitelisting de clientes o modos sandbox para no spamear usuarios reales.

    ¿Cuándo elegir GraphQL con Angular 21?

    Usa GraphQL si tus vistas requieren datos compuestos de múltiples fuentes, necesitas minimizar tráfico en móviles o buscas tipado estricto entre cliente y servidor. No lo añadas por moda: para CRUDs simples o equipos sin experiencia, HttpClient sigue siendo más directo.

    GraphQL con Angular 21 no es mágico; es una herramienta que reduce deuda cuando se aplica con criterio. En Dominicode seguiremos profundizando en patterns avanzados: cache eviction, pagination cursor-based y estrategias para SSR con hydration. Esto no acaba aquí.

    FAQ

    Signals permiten convertir streams en valores reactivos fáciles de usar en plantillas, eliminando la necesidad de | async y simplificando la gestión de suscripciones.
    Sí, normalizar con typePolicies y keyFields evita duplicados y facilita updates locales sin refetch. En APIs simples puede no ser crítico, pero es buena práctica en apps complejas.
    Usa optimisticResponse y la función update del cliente para aplicar cambios al caché de forma inmediata y consistente con la estructura de datos.
    Genera tipos y servicios fuertemente tipados que reducen boilerplate y permiten detectar cambios incompatibles en la compilación, mejorando la seguridad de refactors.
    No. Para CRUDs simples o equipos sin experiencia en GraphQL, HttpClient puede ser más directo. GraphQL brilla cuando las vistas requieren datos compuestos o se busca minimizar tráfico y overfetching.

  • Lifecycle hooks en Angular: lo que ya no necesitas (y qué usar en su lugar)

    Lifecycle hooks en Angular: lo que ya no necesitas (y qué usar en su lugar)

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Signals y primitivas reactivas reemplazan la mayoría de los lifecycle hooks clásicos.
    • Convierte Inputs en señales y usa computed() para derivados; usa effect() para side-effects.
    • Usa DestroyRef.onDestroy() para limpieza cerca del recurso, evitando ngOnDestroy globales.
    • Reacciona al DOM con signal queries y afterNextRender() en lugar de los hooks after-view.

    Tabla de contenidos

    Si llevas años programando en Angular, algunos hooks clásicos te resultarán familiares: ngOnChanges, ngOnInit, ngAfterViewInit, ngOnDestroy… La plataforma no elimina el lifecycle, pero las nuevas primitivas (Signals, DestroyRef y utilidades de renderizado) mueven el enfoque hacia relaciones declarativas entre datos y componentes reaccionando a cambios en señales en lugar de comprobar “cuándo ocurre X”.

    Resumen rápido (lectores con prisa)

    Qué: Signals y primitivas reactivas reemplazan la mayor parte de los lifecycle hooks clásicos.

    Cuándo: Úsalos al convertir Inputs, calcular derivados y gestionar side-effects que dependan de estado reactivo.

    Por qué: Código más declarativo, menos errores de timing y mayor testabilidad.

    Cómo: Inputs → señales; derivados → computed(); efectos → effect(); limpieza → DestroyRef.onDestroy().

    Lifecycle hooks en Angular: qué dejar atrás y por qué

    ngOnChanges → computed()

    ngOnChanges estaba destinado a detectar cambios en @Input() y recalcular derivados. Con Signals, transforma inputs en señales y usa computed() para expresar derivados de forma declarativa.

    price = input.required<number>();
tax   = input.required<number>();
total = computed(() => this.price() * (1 + this.tax()));

    Por qué: menos código, cero bugs de sincronización, lecturas deterministas.

    ngOnInit → constructor + effect() (o input())

    ngOnInit fue el cajón de sastre. Los patrones modernos distribuyen responsabilidades:

    • Estado inicial: declara signal() o computed() en la propiedad.
    • Side-effects reactivos: usa effect() para reaccionar a señales.
    • Carga inicial ligada a inputs: usa helpers que disparan requests cuando el input está disponible.

    Sigue usando ngOnInit solo si necesitas un efecto que explícitamente ocurra una vez y no dependa de reactividad (migraciones, integraciones legacy).

    ngDoCheck → casi siempre obsoleto

    Si creías necesitar ngDoCheck, para y replantea. ngDoCheck suele esconder un mal diseño. Signals cubren la detección fina sin chequeos manuales. Rediseña con señales y computed(); si aún necesitas inspección manual, documenta por qué.

    ngAfterViewInit / ngAfterContentInit → signal queries + afterNextRender

    Acceder a un ViewChild o ContentChild sin esperar el momento correcto fue una fuente interminable de bugs. Las Signal Queries (viewChild, contentChild) devuelven señales que cambian cuando el elemento existe.

    chartEl = viewChild<ElementRef>('chart');

constructor() {
  effect(() => {
    const el = this.chartEl();
    if (el) { /* setup chart */ }
  });

  afterNextRender(() => {
    // ejecutar una vez después del primer render en cliente
  });
}

    Combina con afterNextRender() para inicializar librerías del DOM (Chart.js, Leaflet) en cliente sin romper SSR.

    ngAfterViewChecked → afterRender

    Para reacciones tras cada render, afterRender() es la alternativa con semántica clara. Evita usarlo para lógica pesada; es para observabilidad y ajustes UI puntuales.

    ngOnDestroy → DestroyRef

    Olvida implementar OnDestroy en todas las clases. Inyecta DestroyRef y registra callbacks donde crees recursos. Esto vuelve la limpieza componible y cercana al lugar de creación del recurso.

    const destroyRef = inject(DestroyRef);
const timer = setInterval(...);
destroyRef.onDestroy(() => clearInterval(timer));

    Referencia: DestroyRef

    Reglas prácticas de migración (lista corta, aplicable)

    1. Inputs → convierte a Signal Inputs; todos los cálculos derivados en computed().
    2. Efectos → usa effect() en constructor; evita suscripciones manuales cuando sea posible.
    3. DOM post-render → viewChild() + effect() para reactividad; afterNextRender() para inicializaciones DOM-only.
    4. Limpieza → DestroyRef.onDestroy() junto al recurso.
    5. Legacy → mantén hooks si tu integración depende de ellos; documenta el porqué.

    Por qué importa (y cuándo no cambiar)

    Menos hooks = menos magia oculta. Código más testable. Menos errores por timing. Pero hay excepciones: bibliotecas legacy, patterns altamente instrumentados, o equipos que necesitan migraciones graduales. En esos casos, planifica parques de migración: componente por componente.

    Angular evoluciona hacia un modelo declarativo. Adoptar Signals no es solo reescribir métodos; es reorganizar la arquitectura mental del componente: de “controlador de eventos” a “descripción de relaciones”. El resultado: componentes más predecibles, más fáciles de probar y mantener.

    Lecturas recomendadas

    FAQ

     

    ¿Por qué debería convertir mis Inputs a señales?

    Convertir Inputs a señales permite expresar de forma declarativa los cálculos derivados con computed() y reaccionar con effect(). Esto elimina la necesidad de logic dispersa en ngOnChanges y reduce errores de sincronización.

     

    ¿Cuándo sigue siendo válido usar ngOnInit?

    Usa ngOnInit cuando necesites un efecto que debe ejecutarse exactamente una vez y no depende de la reactividad de señales (por ejemplo, migraciones o integraciones legacy). Para lógica ligada a estado reactivo, prefiere effect().

     

    ¿Cómo reemplazo las suscripciones manuales?

    Siempre que sea posible, reemplaza suscripciones con effect() o convierte fuentes externas en señales. Para recursos que aún usan callbacks o timers, registra limpieza con DestroyRef.onDestroy() junto al recurso.

     

    ¿Qué uso para inicializaciones que requieren el DOM?

    Usa signal queries (viewChild(), contentChild()) que devuelven señales y combínalas con effect(). Para inicializaciones que deben ocurrir solo en cliente después del primer render, utiliza afterNextRender().

     

    ¿Qué ventajas tiene DestroyRef frente a ngOnDestroy?

    DestroyRef permite registrar callbacks de limpieza cerca del recurso, haciendo la limpieza composable y localizada. Evita la necesidad de implementar la interfaz OnDestroy en cada clase y mejora la trazabilidad de recursos.

  • Cómo crear una API de autenticación en Express.js para reclutadores

    Cómo crear una API de autenticación en Express.js para reclutadores

    Cree una API de inicio y cierre de sesión con Express.js (Node.js)

    Tiempo estimado de lectura: 3 min

    • Ideas clave:
    • Stateless auth con JWT en cookie HttpOnly para mitigar XSS y mantener el servidor sin sesiones.
    • Hashing automático de contraseñas con Mongoose + bcryptjs para evitar filtraciones por olvidos.
    • Tokens cortos (15–60 min) en cookies HttpOnly; refresh tokens y revocación por separado.
    • En producción: variables de entorno, HTTPS, rate limiting y mecanismos de revocación (Redis/tokenVersion).

    ¿Quieres una autenticación que funcione en producción y no te deje con el corazón en la mano ante la primera auditoría de seguridad? Cree una API de inicio y cierre de sesión con Express.js (Node.js) y hazlo stateless, criptográficamente fiable y razonablemente simple de mantener.

    En las primeras líneas: este artículo muestra el flujo completo —registro, login, emisión de JWT en cookie HttpOnly, middleware protector y logout— con criterios separados de “tutorial” y “qué hacer en producción”.

    Resumen rápido (para IA y lectores con prisa)

    Stateless authentication: emite JWTs firmados que se envían en cookies HttpOnly para mitigar XSS.

    Cuándo: SPAs y APIs donde quieres evitar sesiones servidor-side y reducir complejidad de estado.

    Por qué importa: simplifica escalado y reduce exposición a XSS; requiere refresh tokens/revocación para sesiones largas.

    Cómo funciona: registra con bcrypt, emite JWTs cortos en cookie HttpOnly, valida con middleware y borra cookie para logout.

    Cree una API de inicio y cierre de sesión con Express.js (Node.js): arquitectura y dependencias

    Pila mínima recomendada

    Instalación

    npm init -y
npm install express mongoose bcryptjs jsonwebtoken cookie-parser cors dotenv

    Concepto: stateless

    Concepto: stateless = el servidor no guarda sesiones. Emites un access token (JWT) firmado y lo envías en una cookie HttpOnly. El cliente no puede leerla vía JS, lo que mitiga XSS.

    Modelo de usuario y hashing (criterio práctico)

    Automatiza el hashing con Mongoose para evitar fugas por olvidos:

    // models/User.js
const mongoose = require('mongoose');
const bcrypt = require('bcryptjs');

const userSchema = new mongoose.Schema({
  email: { type: String, required: true, unique: true, lowercase: true, trim: true },
  password: { type: String, required: true, minlength: 8 }
});

userSchema.pre('save', async function(next) {
  if (!this.isModified('password')) return next();
  this.password = await bcrypt.hash(this.password, 12); // cost 12
  next();
});

userSchema.methods.comparePassword = function(candidate) {
  return bcrypt.compare(candidate, this.password);
};

module.exports = mongoose.model('User', userSchema);

    ¿Por qué cost 12? Balance entre seguridad y CPU. Ajusta según tu infraestructura.

    Login: validar, firmar y enviar cookie

    Regla: JWT corto (ej. 15–60 min) en cookie HttpOnly; refresh tokens aparte.

    // controllers/auth.js (extracto)
const jwt = require('jsonwebtoken');

const login = async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user || !(await user.comparePassword(password))) {
    return res.status(401).json({ error: 'Credenciales inválidas' });
  }

  const token = jwt.sign({ userId: user._id }, process.env.JWT_SECRET, { expiresIn: '15m' });

  res.cookie('authToken', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
    maxAge: 15 * 60 * 1000
  });

  res.json({ success: true });
};

    No pongas datos sensibles en el payload. Claims mínimos: userId y algún scope si hace falta.

    Middleware protector de rutas

    Intercepta y valida la cookie antes de permitir el acceso:

    // middleware/auth.js
const jwt = require('jsonwebtoken');

module.exports = (req, res, next) => {
  const token = req.cookies.authToken;
  if (!token) return res.status(401).json({ error: 'No autorizado' });

  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch (e) {
    res.status(401).json({ error: 'Token inválido o expirado' });
  }
};

    Adjunta req.user.userId para consultas posteriores.

    Logout: simple y efectivo

    En una arquitectura basada en cookies HttpOnly, cerrar sesión es instructivo: borrar la cookie en el navegador.

    // controllers/auth.js
const logout = (req, res) => {
  res.clearCookie('authToken', {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict'
  });
  res.json({ success: true });
};

    Si necesitas invalidación inmediata de tokens (por ejemplo, forzar logout de todos los dispositivos), añade una lista de revocación en Redis con claves expiradas o guarda un tokenVersion en el usuario y compáralo en el JWT.

    Comparativa: Cookies HttpOnly vs localStorage (resumen técnico)

    • Cookies HttpOnly: automáticas, resistentes a XSS, requieren SameSite y HTTPS.
    • localStorage: accesible por JS → vulnerable a XSS; menos recomendable para web.

    Para la mayoría de SPAs web, cookies HttpOnly + CSRF mitigations (SameSite/CSRF token cuando sea necesario) es la opción correcta.

    Consideraciones de producción (criterio senior)

    • Nunca expongas JWT_SECRET ni URIs en el repo; usa variables de entorno.
    • Usa HTTPS en todas partes; secure cookies dependen de ello.
    • Implementa rate limiting en /login (express-rate-limit).
    • Logging y alertas en intentos fallidos.
    • Considera refresh tokens almacenados en HttpOnly (o en un store) si necesitas sesiones largas. Documentación OWASP sobre autenticación: https://owasp.org.
    • Validación de entrada robusta (Joi o express-validator).

    Conclusión y siguiente paso

    Cree una API de inicio y cierre de sesión con Express.js (Node.js) usando JWT en cookies HttpOnly y bcrypt para contraseñas y habrás cubierto la base para una autenticación segura y escalable. Esto no es la cima: el siguiente paso es integrar refresh tokens seguros, rotación de tokens y estrategias de revocación (Redis/DB). Implementa lo básico bien y estarás listo para esas capas adicionales.

    FAQ

    Respuesta

    Cookies HttpOnly no son accesibles desde JavaScript, lo que reduce la superficie de ataque frente a XSS. localStorage es accesible por JS y por tanto vulnerable a XSS.

    Respuesta

    Usa JWTs cortos (ej. 15–60 minutos) para access tokens. Para sesiones largas, combina con refresh tokens seguros y rotación de tokens.

    Respuesta

    Almacena refresh tokens en cookies HttpOnly o en un store con expiración. Implementa rotación: emite un nuevo refresh token al usar uno válido y revoca el anterior.

    Respuesta

    Para invalidación inmediata, usa una lista de revocación en Redis con claves expiradas o guarda un tokenVersion en el usuario y compáralo contra el JWT.

    Respuesta

    Automatizar hashing evita errores humanos (olvidar hashear antes de guardar) y estandariza el coste. Mongoose pre(‘save’) es una forma práctica de hacerlo.

    Respuesta

    Variables de entorno seguras, HTTPS obligatorio, rate limiting en endpoints críticos, logging/alertas, validación de input y mecanismos de revocación para tokens son esenciales.

  • Cómo estructurar un proyecto Angular grande sin morir en el intento

    Cómo estructurar un proyecto Angular grande sin morir en el intento

    Tiempo estimado de lectura: 3 min

    Ideas clave:

    • Organiza por dominios (slicing vertical) en lugar de por tipo de archivo.
    • Divide librerías en feature / ui / data-access (domain) / util y aplica reglas de dependencia.
    • Usa el patrón Facade para aislar la UI del estado y poder cambiar implementaciones.
    • Automatiza límites con reglas (ESLint / depConstraints de Nx) y aprovecha caching y librerías en Nx.

    Tabla de contenidos

    Cómo estructurar un proyecto Angular grande sin morir en el intento empieza por admitir que el problema no es Angular: es tu arquitectura. Agrupar por tipo de archivo es cómodo al principio y mortal a los 6 meses. Aquí explico cómo organizar por dominios, qué librerías crear, qué patrones aplicar y qué reglas automatizar para que tu app crezca sin destrozar la productividad del equipo.

    En las primeras líneas: si tu equipo supera los dos desarrolladores, deja de pensar en carpetas por tecnología y empieza a pensar en dominios de negocio. Usa Nx para orquestar librerías, aplica el patrón Facade y fuerza límites con ESLint. Enlaces útiles: Nx, Module Boundaries, Standalone Components.

    Resumen rápido (lectores con prisa)

    Slicing vertical = agrupar por dominio. Librerías: feature / ui / data-access (domain) / util. Facade = única API estable para UI. Reglas (ESLint / depConstraints) hacen cumplir límites. Nx facilita orquestación y caching.

    Cómo estructurar un proyecto Angular grande sin morir en el intento (resumen práctico)

    La estructura que realmente escala combina tres decisiones simples: 1) Slicing vertical por dominio, 2) Librerías tipadas (feature/ui/data-access/util), 3) Patrones que desacoplan (Facade, Barrels) y reglas automáticas (ESLint). No es exotismo; es disciplina.

    Slicing vertical por dominio

    Evita el antipatrón: /components, /services, /models. En su lugar, crea dominios verticales:

    • /libs/booking → todo lo relacionado con reservas.
    • /libs/payments → lógica de pagos.
    • /libs/shared/ui-kit → componentes presentacionales.

    Cada dominio contiene sub-librerías con responsabilidades claras. El resultado: para cambiar una feature solo tocas la librería del dominio pertinente.

    Taxonomía de librerías que sí funcionan

    Divide las librerías en cuatro tipos. Cada tipo tiene reglas claras de dependencia.

    1. Feature (feature-*)

    • Contiene smart components, rutas y orquestación UI.
    • Puede depender de data-access, ui y util.
    • Normalmente cargada lazy.

    2. UI (ui-*)

    • Componentes dumb, sin lógica de negocio.
    • Solo depende de ui y util.
    • Reutilizable y testeable.

    3. Data-access / Domain (data-access-* o domain-*)

    • Estado, API services, interfaces y Facades.
    • No debe depender de feature ni ui.

    4. Util (util-*)

    • Funciones puras, helpers, form validators.
    • Sin dependencias del resto del repo.

    Ejemplo de estructura en Nx:

    /apps
  /customer-portal
/libs
  /booking
    /feature-search
    /data-access
    /ui-seat-map
  /payments
    /feature-checkout
    /data-access
  /shared
    /ui-kit
    /util-formatters

    Patrón Facade: amortiguador entre UI y estado

    El patrón Facade es la guardia de contención. Cualquier componente de feature consume una Facade, no la store o servicios HTTP directamente. Si cambias la implementación de estado, solo cambias la Facade.

    import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class BookingFacade {
  readonly bookings = this.store.selectSignal(selectBookings);
  readonly loading = this.store.selectSignal(selectLoading);

  loadBookings() { this.store.dispatch(BookingActions.load()); }
  createBooking(data: BookingInput) { this.store.dispatch(BookingActions.create({ data })); }
}

    El componente usa solo la Facade. Cambias NgRx por Signals o por otra librería y el componente sigue igual.

    Reglas de dependencia: automatiza la disciplina

    No confíes en la buena voluntad. Usa reglas de ESLint para imponer límites. Con Nx configuras depConstraints para que una ui nunca importe data-access, o que feature solo dependa de ui, data-access y util.

    {
  "depConstraints": [
    { "sourceTag": "type:ui", "onlyDependOnLibsWithTags": ["type:ui","type:util"] },
    { "sourceTag": "type:feature", "onlyDependOnLibsWithTags": ["type:ui","type:data-access","type:util"] }
  ]
}

    Documentación: Module Boundaries

    Estrategias prácticas para migración y crecimiento

    • Start small: convierte primero librerías compartidas críticas a ui-* y data-access-*.
    • Facades on day one: crea facades incluso si hoy solo usan simple HTTP; evitarás reescrituras.
    • Tests per lib: cada librería con su suite de unit y e2e en CI. Nx hará caching de builds/tests.
    • Standalone components: adopta standalone: true para mejorar tree-shaking y simplificar imports (Standalone Components).
    • Evita SharedModule gigante: usa barrels (index.ts) y exportaciones controladas.

    Criterio técnico final

    Un proyecto Angular grande que no se descomponga se basa en tres cosas: límites explícitos, contratos estables (Facades/interfaces) y herramientas que refuerzan la arquitectura. Nx + Slicing vertical + Facades + ESLint = velocidad sostenible. No prometo milagros, pero sí reproducibilidad: equipos que crecen y siguen entregando sin que el repo se convierta en una fosa de hormigón.

    La próxima decisión es cultural: implantar y hacer cumplir estas reglas. Hazlo y tu código dejará de pelearse consigo mismo; tu equipo ganará espacio para resolver problemas reales.

    FAQ

     

    ¿Por qué agrupar por dominios en lugar de por tipo de archivo?

    Agrupar por dominios (slicing vertical) reduce el acoplamiento entre features y evita que cambios en una área afecten todo el repo. Cuando el equipo supera los dos desarrolladores, la organización por tecnología se vuelve difícil de mantener y ralentiza la entrega.

    ¿Qué tipos de librerías debo crear?

    Crea cuatro tipos: feature-* (orquestación UI y rutas), ui-* (componentes dumb), data-access-* o domain-* (estado, servicios API, facades) y util-* (helpers puros). Cada tipo tiene reglas claras de dependencia para mantener límites.

    ¿Qué es una Facade y cuándo usarla?

    Una Facade es una capa que expone una API estable para la UI y oculta la implementación del estado (NgRx, Signals, etc.). Úsala desde el inicio: permite cambiar la implementación interna sin tocar componentes presentacionales.

    ¿Cómo aplico reglas de dependencia con Nx?

    Configura depConstraints en la configuración de Nx para imponer qué tags pueden depender entre sí. Complementa con reglas de ESLint para bloquear importaciones directas no deseadas y automatizar la disciplina arquitectónica.

    ¿Debería adoptar standalone components ahora?

    Adoptar standalone: true mejora tree-shaking y simplifica imports, por lo que es una buena práctica a considerar. Evalúa el impacto en tu flujo y migra de forma incremental donde aporte más valor.

    ¿Cómo migrar un repo monolítico a este enfoque por dominios?

    Empieza por mover librerías compartidas críticas a ui-* y data-access-*. Crea Facades desde el primer día para encapsular dependencias. Añade pruebas por librería y configura depConstraints en Nx para evitar regresiones.

  • Cuándo no usar Effects en Angular para optimizar

    Cuándo no usar Effects en Angular para optimizar

    Tiempo estimado de lectura: 2 min

    • Usa effects para interaccionar con el mundo exterior (analítica, localStorage, librerías imperativas).
    • No uses effects para propagar estado dentro del grafo reactivo; usa computed() para relaciones derivadas.
    • Para cancelación/debounce o flujos temporales complejos, usa RxJS y la interoperabilidad (toObservable / toSignal).
    • Audita effects: la mayoría suele ser reemplazable por computed o RxJS para evitar bugs y renders extra.

    La pregunta aparece en casi todos los equipos que adoptan Signals: ¿usar effect() para todo porque “reacciona” a cambios? No. Entender cuándo (no) usar Effects en Angular y qué hacer en su lugar te evita bugs raros, renders extra y código que nadie quiere mantener.

    Resumen rápido (lectores con prisa)

    Qué es: effect() ejecuta código al cambiar signals que lee.

    Cuándo usar: para interacciones fuera del grafo (analytics, localStorage, librerías imperativas, timers con cleanup).

    Cuándo evitar: para propagar estado dentro de la app; usa computed() o RxJS según convenga.

    Cómo aplicarlo: usa computed() para derivadas y RxJS (toObservable/toSignal) para debounce/cancelación.

    Contexto: qué hace un effect

    Un efecto se ejecuta automáticamente cuando los signals que lee cambian. Eso lo hace útil para side effects: analytics, localStorage, llamadas a librerías imperativas. Pero usarlo para sincronizar estados es un antipatrón. Si tu cambio en A debe producir un nuevo valor en B dentro de la app, usa una derivación, no un efecto.

    Documentación oficial: Documentación oficial
    Interop RxJS: Interop RxJS

    Antipatrones comunes (y por qué duelen)

    1) Sincronizar signals con effects

    Código que ves en todos lados:

    total = signal(0);

constructor() {
  effect(() => {
    this.total.set(this.precio() * this.cantidad()); // antipatrón
  });
}

    Problemas: escrituras desde effect requieren flags especiales, ocultan la relación entre datos y disparan detecciones de cambio y re-ejecuciones innecesarias.

    2) Resetear formularios desde effects

    Un ID cambia y un effect resetea el form. Funciona, pero la lógica queda dispersa: ¿dónde está la verdad del flujo? Difícil de testear, propenso a race conditions.

    3) Intentar manejar debounce/switchMap dentro de effects

    Effects no reemplazan a RxJS. Si necesitas cancelación, debounce o switchMap, acabarás reinventando operadores o creando fugas.

    Qué usar en su lugar: computed() para estado derivado

    Cuando B es función de A, declara esa relación.

    total = computed(() => precio() * cantidad);

    Ventajas:

    • Declarativo: defines qué es total, no cuándo actualizarlo.
    • Lazy: solo se recalcula si alguien lo lee.
    • Memoizado: evita trabajo innecesario.

    Esto reduce CD y hace el código explícito y testeable.

    Para flujos asíncronos complejos: RxJS + Signals

    Si tu flujo necesita debounce, cancelación o combinaciones complejas, usa RxJS y la interoperabilidad:

    • Convierte signal a observable: toObservable(signal)
    • Aplica operadores RxJS
    • Convierte a signal si lo necesitas en templates: toSignal(observable)

    Ejemplo type-ahead:

    const query$ = toObservable(querySignal);
const results$ = query$.pipe(
  debounceTime(300),
  switchMap(q => httpClient.get(`/search?q=${q}`))
);
const resultsSignal = toSignal(results$, { initialValue: [] });

    Así no reinventas lógica de tiempo y mantienes señales limpias.

    Docs de interoperabilidad: Docs de interoperabilidad

    Dónde SÍ usar Effect: casos legítimos

    Usa effect cuando la acción produce algo fuera del grafo de Angular.

    • Logging y analíticas
      effect(() => sendEvent('filter-changed', { filter: filter() }));
    • Sincronizar con Browser APIs
      effect(() => localStorage.setItem('theme', theme()));
    • Librerías imperativas (Chart.js, Leaflet)
      effect(() => chart.update({ data: series() }));
    • Timers y observers con cleanup
      effect((onCleanup) => {
      const id = setInterval(() => poll(), 5000);
      onCleanup(() => clearInterval(id));
      });

    Si el resultado del effect no vuelve al estado de la app, está bien.

    afterRenderEffect y manipulación del DOM

    Para actualizar third-party widgets después del commit DOM, usa afterRenderEffect (evita layout thrashing y separa lectura/escritura). Útil para charts que requieren dimensiones reales del canvas antes de renderizar.

    Regla práctica y checklist rápido

    • Si vas a llamar a .set() o .update() sobre otro signal desde un effect: para. Usa computed o cambia la source-of-truth.
    • Si necesitas debounce, cancelación o combinaciones temporales: usa RxJS (toObservable/toSignal).
    • Si el cambio sale de Angular (localStorage, analytics, DOM imperativo): effect.
    • Audita effects: más del 70–90% deberían ser reemplazables por computed o RxJS.

    Adoptar esta disciplina no solo mejora rendimiento; hace tu código predecible y testeable. En próximos artículos veremos cómo migrar patrones comunes de RxJS a Signals paso a paso, con ejemplos reales y pruebas unitarias.

    FAQ

    ¿Puedo usar effect para sincronizar dos signals?

    Técnicamente sí, pero es un antipatrón. Si B depende de A dentro de la app, define B como computed() en vez de escribirle desde un effect. Evitas flags especiales, renders adicionales y relaciones ocultas entre datos.

    ¿Por qué es mejor usar computed para valores derivados?

    Porque es declarativo, lazy y memoizado. Definís la relación entre datos y solo se recalcula si alguien lee el valor, lo que reduce detecciones de cambio y hace el código más testeable.

    ¿Cuándo debería introducir RxJS con signals?

    Cuando necesitas debounce, cancelación, switchMap o combinaciones temporales complejas. Convierte signals a observables con toObservable(), aplica operadores RxJS y, si hace falta, vuelve a signal con toSignal().

    ¿Qué pasa si un effect escribe en otro signal?

    Genera código frágil: requiere flags especiales, oculta la relación entre datos y puede provocar re-ejecuciones innecesarias y bugs difíciles de rastrear. Mejor cambiar la fuente de la verdad o usar computed.

    ¿Es acceptable resetear formularios con effects?

    Funciona en muchos casos, pero dispersa la lógica y dificulta testing. Puede introducir race conditions. Evalúa mover la lógica al flujo de datos principal o utilizar patrones que mantengan la fuente de la verdad clara.

    ¿Cuándo usar afterRenderEffect en lugar de effect?

    Usa afterRenderEffect para actualizar widgets o librerías que requieren dimensiones reales del DOM después del commit. Evita layout thrashing y separa lectura/escritura del DOM imperativo.

  • De Angular 17 a Angular 21+: qué ha cambiado de verdad y qué debes migrar ya

    De Angular 17 a Angular 21+: qué ha cambiado de verdad y qué debes migrar ya

    Tiempo estimado de lectura: 4 min

    • Standalone Components reducen complejidad y mejoran tree-shaking importando dependencias directamente en componentes.
    • Signals aportan reactividad de grano fino: menos re-render y modelo más explícito.
    • Control de flujo nativo y @defer mejoran rendimiento de templates y carga diferida por bloque.
    • Migración por capas: standalone + control-flow primero; signals y zoneless después tras pruebas.
    Tabla de contenidos

    Introducción

    ¿Tu app Angular sigue anclada a NgModules y zone.js? De Angular 17 a Angular 21+ el framework cambió de piel: no es una serie de parches, es una reescritura de prioridades. Este artículo explica qué cambió de verdad, por qué importa a nivel de rendimiento y arquitectura, y qué debes migrar ya sin reinventar todo.

    Resumen rápido (lectores con prisa)

    Standalone Components: componentes sin NgModules, importas dependencias en el componente y se mejora tree-shaking.

    Signals: reactividad de grano fino: signal(), computed(), effect().

    Control de flujo nativo y @defer: mejor rendimiento en templates y carga diferida por bloque.

    Zoneless: camino hacia detección de cambios sin zone.js, mejor SSR/hydration y menos overhead.

    De Angular 17 a Angular 21+: cambios que importan (y por qué)

    Angular dejó atrás la era donde los NgModules eran la única forma de estructurar una app. El objetivo ahora es reducir el bundle inicial, minimizar work wasted en render y dar al dev un modelo de reactividad más explícito.

    Standalone Components

    Qué: sustituyen a NgModules. Importas dependencias directamente en el componente y el compilador hace tree-shaking fino.

    Por qué importa: reducción de complejidad, bundles más pequeños y lazy loading más sencillo.

    Docs: guía de Standalone

    Signals

    Qué: reactividad de grano fino que reduce la necesidad de recorrer el árbol entero para detectar cambios. signal(), computed(), effect() son la base.

    Por qué importa: menos re-render, estado más predecible y preparación para zoneless.

    Docs: Signals

    Control de flujo nativo en templates

    Qué: @if, @for, @switch reemplazan a *ngIf/*ngFor, con mejor performance y type narrowing.

    Por qué importa: rendimiento inmediato en renderizados y listas grandes; mejora la experiencia de desarrollo.

    Docs: Control Flow

    @defer

    Qué: carga diferida a nivel de bloque en la plantilla.

    Por qué importa: cargas sólo el JS cuando el usuario lo necesita, no por ruta completa; mejora Core Web Vitals.

    Zoneless

    Qué: camino hacia la detección de cambios sin zone.js, disponible experimentalmente y consolidándose en 20/21.

    Por qué importa: menos overhead y SSR/hydration más limpio.

    ¿Qué migrar ya? Prioridad práctica y razones

    No necesitas reescribir todo. Migrar con criterio minimiza riesgo y maximiza ganancia.

    1) Migración a Standalone — Prioridad Alta

    Por qué: reducción de complejidad, bundles más pequeños y lazy loading más sencillo.

    Cómo: usa las schematics oficiales y migra componentes compartidos primero.

    Guía: guía de Standalone

    2) Control de flujo en plantillas — Prioridad Alta

    Por qué: rendimiento inmediato en renderizados y listas grandes; casi siempre seguro migrar.

    Cómo: ng generate @angular/core:control-flow. Beneficio inmediato en DX y perf.

    Docs: Control Flow

    3) Aplicar @defer en componentes pesados — Prioridad Media

    Por qué: mejora Core Web Vitals (LCP/INP) sin reestructurar rutas.

    Dónde: dashboards, charts, modales pesados.

    Tip: combina con placeholders para UX fluida.

    4) Adoptar Signals progresivamente — Prioridad Estratégica

    Por qué: preparas tu codebase para zoneless; menor re-rendering y estados más previsibles.

    Cómo: en nuevo código, usa signal() para estado local; usa toSignal() para bridge con RxJS cuando necesites streams.

    Docs: Signals

    5) Zoneless — Prioridad Condicional (Post-setup)

    Por qué: mayor rendimiento y mejor SSR/hydration.

    Cuándo: cuando tu app ya sea standalone y use signals; aplica tests E2E exhaustivos antes de cortar zone.js.

    Ejemplo rápido: de BehaviorSubject a Signal

    Antes (RxJS):

    private items$ = new BehaviorSubject<Item[]>([]);

    Después (Signals):

    const items = signal<Item[]>([]);

    No es un trámite estético: cambia cómo Angular calcula la actualización del DOM.

    Señales de alarma: cuándo no usar nativamente Signals todavía

    • Workflows complejos de RxJS (combinaciones, debounce, backpressure) siguen siendo RxJS.
    • Librerías de terceros que dependen de zones o async pipe pueden requerir adaptación.
    • Workflows gigantes en templates (30+ nodos lógicos) mejor refactorizar a código.

    Herramientas y enlaces prácticos

    Hoja de ruta breve para equipos (4 pasos, pragmático)

    1. Ejecuta migración a Standalone en módulos compartidos y rutas lazy.
    2. Aplica control flow en las plantillas (schematic). Corre pruebas de UI.
    3. Introduce @defer en componentes no críticos para mejorar LCP.
    4. En nuevos componentes usa Signals; planifica migraciones en servicios críticos tras benchmarking.

    Conclusión

    Angular 21+ no es un “upgrade menor”. Es una plataforma más modular, más rápida y lista para SSR/Hydration moderno. No lo intentes todo de golpe: migra por capas. Empieza por standalone y control-flow —es el menor riesgo con mayor retorno— y luego adopta signals como estrategia para preparar tu app para un futuro zoneless.

    FAQ

    ¿Debo migrar toda la app a Standalone de inmediato?

    No. Migra por capas: empieza por módulos compartidos y rutas lazy donde el impacto es mayor y el riesgo contenido. Usa las schematics oficiales para automatizar el proceso y validar por partes.

    ¿Signals reemplazan RxJS completamente?

    No. Signals son excelentes para estado local y reactividad fina. Sin embargo, workflows complejos de RxJS (combinaciones, debounce, backpressure) siguen siendo más apropiados con RxJS. Usa toSignal() para integrar ambos mundos.

    ¿Qué ventaja práctica aporta el control de flujo nativo?

    Reduce trabajo innecesario al re-renderizar, mejora type narrowing en templates y ofrece mejor rendimiento en listas y vistas condicionadas. La migración suele ser segura y con mejoras inmediatas en render.

    ¿Cuándo aplicar @defer en mi app?

    Aplica @defer en componentes pesados y no críticos para mejorar LCP: dashboards, gráficos y modales que no son necesarios en el primer pintado. Combínalo con placeholders para no romper la UX.

    ¿Es seguro eliminar zone.js ahora mismo?

    Es condicional: sólo cuando tu app esté mayormente standalone y haya adoptado signals. Antes de eliminar zone.js, corre pruebas E2E completas y verifica compatibilidad con librerías de terceros.

  • Mejores prácticas para cargar datos asíncronos en Angular 21

    Mejores prácticas para cargar datos asíncronos en Angular 21

    Tiempo estimado de lectura: 4 min

    • Mantén RxJS en los servicios y expón Signals al componente.
    • Usa toSignal() o rxResource()/resource() (Angular 19+) para manejar lifecycle y estado de petición.
    • Encapsula loading/data/error en un único State Object o utiliza rxResource() para menos boilerplate.
    • Usa computed() para derivaciones y aplica ChangeDetectionStrategy.OnPush en componentes que consumen signals.

    Las mejores prácticas para cargar datos asíncronos en componentes Angular empiezan y terminan hoy con signals. Si tu componente aún vive de .subscribe() en ngOnInit y takeUntil en ngOnDestroy, estás escribiendo código que obliga a humanos a recordar cosas que debería recordar la plataforma. Este artículo explica, con ejemplos y criterio claro, cómo mover la responsabilidad de la reactividad a la frontera (servicio → señal) y por qué eso mejora rendimiento, legibilidad y seguridad frente a memory leaks.

    Resumen rápido (lectores con prisa)

    Qué es: Signals son primitivos de reactividad que permiten lectura síncrona y re-evaluación eficiente.

    Cuándo usarlo: Convierte Observables a Signals en la frontera (servicio → componente) y usa rxResource() en Angular 19+ para requests estándar.

    Por qué importa: Evita suscripciones manuales, reduce riesgos de memory leaks y mejora detección de cambios con OnPush.

    Cómo funciona: Transforma streams en signals con toSignal() o usa recursos de alto nivel (rxResource()) que exponen isLoading, error y value.

    Principio: convierte streams en señales en la frontera

    Regla simple y práctica: mantén RxJS en los servicios; expón Signals al componente. Usa toSignal() para transformar Observables en Signals y, si estás en Angular 19+, considera rxResource()/resource() para delegar el lifecycle y el estado de petición.

    Ventajas:

    • Suscripción/desuscripción automáticas.
    • Lectura síncrona en templates: mySignal().
    • Detección de cambios de grano fino con OnPush.

    1) toSignal() — la base práctica

    toSignal() convierte un Observable<T> en Signal<T> sin que el componente gestione suscripciones.

    Ejemplo mínimo

    import { toSignal } from '@angular/core/rxjs-interop';
@Component({ changeDetection: ChangeDetectionStrategy.OnPush })
export class UsersComponent {
  private svc = inject(UserService);
  users = toSignal(this.svc.getUsers(), { initialValue: [] });
}

    Template: *ngFor="let u of users()" o {{ users().length }}. Inicializar con initialValue evita undefined y permite render inmediato.

    2) Patrón recomendado: State Object (loading / data / error)

    Un único signal que represente { loading, data?, error? } reduce el bricolaje en templates y evita estados inconsistentes.

    Cómo mapearlo con RxJS antes de toSignal:

    userState = toSignal(
  this.userService.getUser(id).pipe(
    map(user => ({ loading: false, data: user })),
    startWith({ loading: true }),
    catchError(err => of({ loading: false, error: err.message }))
  ),
  { requireSync: true }
);

    En template: condicionales limpias y predecibles. Menos flags, más intención.

    3) rxResource() / resource() — la API de alto nivel (Angular 19+)

    Si tienes Angular 19 o superior, rxResource() cubre la mayoría de casos: estado nativo (isLoading, error, value) y cancelación automática de peticiones en carrera. Usa rxResource cuando quieras menos boilerplate y comportamiento estándar.

    Ejemplo conceptual

    product = rxResource({
  source: () => this.productService.getById(this.productId())
});
// product.isLoading(), product.error(), product.value()

    Beneficio práctico: maneja races, reloads y status sin mapear manualmente streams.

    4) computed() para datos derivados y filtros

    Signals brillan cuando derivan estado de forma clara y eficiente. Reemplaza combineLatest y operadores RxJS en la capa de vista por computed().

    products = toSignal(this.api.getProducts(), { initialValue: [] });
query = signal('');
filtered = computed(() => {
  const q = query().toLowerCase();
  return products().filter(p => p.name.toLowerCase().includes(q));
});

    Resultado: sólo se recalculan las partes necesarias y la UI actualiza con mínimo coste.

    5) Arquitectura: dónde mantener RxJS y dónde usar signals

    – Servicios: RxJS sigue siendo la mejor herramienta para retry, switchMap, backoff, forkJoin, debounce. Mantén ahí los Observable<T>.

    – Componentes: transforman esos Observable<T> a Signal<T> con toSignal() o usan rxResource().

    – Efectos/side-effects: usa effect() para reacciones locales, pero evita poner lógica de negocio compleja en componentes.

    Esta separación reduce la superficie de bugs y hace que las pruebas unitarias sean más claras.

    Patrones avanzados y consideraciones prácticas

    • Debounce en inputs: usa toObservable() si necesitas operadores de tiempo, y vuelve a toSignal() para consumo.
    • Cancelación: confía en rxResource() o en switchMap en el servicio; no intentes gestionar cancelaciones en el componente.
    • OnPush: define siempre ChangeDetectionStrategy.OnPush en componentes que consumen signals para evitar checks innecesarios.
    • SSR/Universal: requireSync y initialValue ayudan a evitar inconsistencias en render server-side.

    Checklist rápido (implementación inmediata)

    • Mueve lógica RxJS compleja a servicios.
    • Convierte Observables a Signals en la frontera con toSignal() o rxResource().
    • Encapsula loading/error/data en un único State Object o usa rxResource.
    • Usa computed() para estados derivados.
    • Aplica OnPush y elimina AsyncPipe cuando uses signals.
    • Usa effect() sólo para side-effects locales y no para lógica de negocio.

    Cierre con criterio

    Priorizar signals no es moda: es una corrección arquitectónica. Simplifica tus componentes, mejora la predictibilidad y evita leaks. Si quieres leer más, empieza por la guía oficial de Signals y la interoperabilidad RxJS: guía de Signals y RxJS interop. Si ya estás en Angular 19+, revisa la API de reactividad y recursos en reactividad para adoptar rxResource() donde aplique.

    Haz el cambio: menos suscripciones manuales, más señales claras. Tu equipo y tu app lo agradecerán.

    FAQ

    ¿Qué es la función toSignal() y para qué sirve?

    toSignal() transforma un Observable<T> en un Signal<T>, permitiendo que el componente lea el valor síncronamente sin gestionar suscripciones manuales.

    ¿Cuándo debería usar rxResource() en lugar de toSignal()?

    Usa rxResource() (Angular 19+) cuando quieres una API de alto nivel que exponga isLoading, error y value, y que maneje races y cancelaciones automáticamente.

    ¿Cómo evito memory leaks al manejar Observables en componentes?

    Mantén RxJS en servicios y convierte a signals en la frontera con toSignal() o usa rxResource(). Así la plataforma gestiona suscripciones y cancelaciones, evitando la mayoría de leaks.

    ¿Por qué usar un State Object con loading/data/error?

    Un State Object unificado evita estados inconsistentes en templates y centraliza el manejo de estados de petición, simplificando la lógica de renderizado y los casos de error.

    ¿Debo eliminar AsyncPipe si uso signals?

    Sí. Cuando consumes signals en templates, usa la llamada al signal (por ejemplo mySignal()) y aplica ChangeDetectionStrategy.OnPush en el componente en lugar de AsyncPipe.

    ¿Qué consideraciones hay para SSR/Universal con signals?

    Usa initialValue y requireSync cuando corresponda para evitar inconsistencias entre render server-side y cliente.

  • Angular 21 Impulsa un Cambio de Paradigma en el Desarrollo

    Angular 21 Impulsa un Cambio de Paradigma en el Desarrollo

    ¿Angular 21 será la versión que deje atrás las costuras y ponga al framework a correr ligero?

    Tiempo estimado de lectura: 7 min

    • Angular 21 introduce un cambio de paradigma significativo.
    • Adiós a Zone.js y componentes basados en Signals.
    • Hidratación parcial optimizada y mejoras en accesibilidad.
    • Refinamiento del uso de RxJS y nuevas herramientas de desarrollo.
    • Automatización se convierte en un aspecto crucial en la migración.

    Tabla de contenidos

    Contexto corto y necesario

    – v18/v19 — entrada de Signals y experimentos Zoneless.
    – v20 — hidratación parcial en proceso.
    – v21 (estimada Noviembre 2025) — consolidación. Todo lo experimental tiene altas probabilidades de pasar a “recomendado por defecto”.

    1) Zone.js muere (o casi): zoneless por defecto

    Zone.js fue la magia negra de Angular. Parcheaba APIs del navegador y te decía cuándo actualizar la UI. Funciona. Pero pesa. Y oculta el flujo real de ejecución.

    Angular 21 empuja a zoneless por defecto. ¿Qué significa en términos crudos?

    • Change detection local. Angular ya no inspecciona todo el árbol por cada evento.
    • Bundles más ligeros. Menos código runtime inútil.
    • Stack traces más claros. Depurar deja de ser buscar agujas en una alfombra enmarañada.

    Imagina a Signals como un GPS que le dice al framework exactamente qué componente mover. Ya no se rompen ventanas enteras por un crujido en un botón.

    Estado: todavía hay librerías y terceros que dependen de zones. La migración requiere prueba real, no deseos. Pero la tendencia es clara: zoneless va a ser el default.

    2) Componentes basados en Signals: adiós a @Input/@Output… o casi

    Los decoradores clásicos empiezan a parecer del siglo pasado cuando tienes un modelo reactivo puro. input(), output(), model() basados en signals no son una moda: son precisión quirúrgica.

    Ventajas que sentirás sin querer:

    • Menos “ExpressionChangedAfter…” a las tres de la mañana.
    • Datos derivados con computed() sin pagar por re-render innecesario.
    • Integración más limpia con estados globales reactivos.

    Metáfora: un componente signal-based es un reloj suizo. Cada engranaje reacciona solo cuando debe.

    3) Hidratación parcial y la fusión Angular + Wiz

    Esto es estratégico. Google movió piezas internas (Wiz) hacia Angular. La idea: que la web no cargue JavaScript que el usuario no va a tocar.

    Evolución rápida:

    • Hidratación destructiva — destruir DOM, volver a crear app.
    • Hidratación completa — reutilizar DOM pero ejecutar todo JS.
    • Hidratación parcial — solo ejecutar JS de las zonas interactivas.

    Y luego está la palabra que acelera debates: resumability. La posibilidad de que una app continúe en el cliente exactamente donde el servidor la dejó, sin re-ejecutar la inicialización. Suena a Qwik, pero aquí la discusión es si Angular lo implementa tal cual o con su propio sabor.

    Si haces SSR, esto cambia métricas: menos JS, mejor LCP, mejor First Input Delay. Simplemente mejor.

    4) RxJS: de monarca absoluto a especialista

    RxJS ha sido la espada del desarrollador Angular. Afilada, potente, y a veces demasiado compleja para tareas comunes.

    Con Signals, el uso básico de estado será sin RxJS. ¿Significa que RxJS muere? No. Significa que se especializa:

    • Signals para estado síncrono y UI local.
    • RxJS para orquestación compleja: races, retries, streaming avanzado.

    Puentes clave: toSignal y toObservable. No tienes que decidir ahora mismo, pero deberías saber que la curva de entrada para nuevos devs baja bastante.

    5) Tooling y DX: bye-bye Webpack, hola esbuild/Vite

    Angular 21 consolida lo que ya venía ocurriendo en el ecosistema:

    • Vite/Esbuild como estándar. Dev server ultrarrápido, builds casi instantáneos.
    • Vitest como runner por defecto (Karma queda en el recuerdo).
    • Mejoras en test de componentes zoneless: menos fixture.detectChanges() manual.

    Resultado: ciclos de feedback más cortos, despliegues más rápidos, menos esperas por una compilación que antes parecía eterna.

    6) Formularios reimaginados: Signal Forms

    Los ReactiveForms clásicos tienen legado, pero también mucho boilerplate. Signal Forms buscan reducir eso.

    Beneficios prácticos:

    • Validación más predecible.
    • Type-safety desde el origen.
    • Menos suscripciones manuales y mejor teardown automático.

    No es un reemplazo abrupto: es una oportunidad para simplificar forms complejos sin perder control.

    7) Control flow nativo, templates más limpios

    Los bloques @if/@for/@switch ya vienen ganando terreno. Se estabilizan como una forma más declarativa y eficiente de escribir views.

    Imagina templates donde las directivas estructurales tradicionales quedan como opción, no como obligación. Menos APIs que dominar. Más claridad en lo que hace la UI.

    8) HttpClient como recurso signalified y builds más agresivos

    HttpClient se hace más cómodo con httpResource(): peticiones tratadas como signals. Junto con mejoras de build (dead code elimination por componente, caching paralelo), los bundles bajan notablemente.

    9) Accesibilidad y a11y nativo

    Angular Aria trae utilidades que solían ser plugins: LiveAnnouncer, trap focus, mejor manejo de router focus. No es solo cumplir WCAG; es evitar tickets recurrentes de QA y propiedades rotas en el cliente.

    10) IA en el dev flow: MCP Developer Server

    No, no es sci-fi. El Model Context Protocol Server conecta tu proyecto con modelos como Gemini o OpenAI para tareas prácticas: scaffolding, refactorings, auditorías de seguridad y migraciones automáticas.

    ¿Útil? Sí. ¿Obligatorio? No. Pero si tu equipo quiere moverse rápido, es una palanca potente.

    11) Migración práctica: pasos concretos

    No hay milagros. Hay pasos sensatos:

    1. Actualiza el CLI: ng update @angular/cli@21
    2. Core packages: ng update @angular/core@21
    3. Opt-in zoneless en main.ts y prueba: provideExperimentalZonelessChangeDetection()
    4. Pilota Signal Forms en un formulario simple
    5. Migra tests a Vitest y revisa SSR
    6. Audita dependencias: Material/CDK, librerías que usan zones

    Planifica esto en sprints. No hagas una migración-bomba en producción.

    12) Automatización: por qué no puedes seguir sin ella

    Si estás en una empresa con varios repos, pipelines y reviewers, cambiar a Angular 21 sin automatizar es tortura. Dominicode Labs lo sabe: automatizar clasificación de issues, generación de docs y rollouts reduce horas semanales de fricción.

    No es marketing. Es fuerza de trabajo recuperada.

    Personajes: el Tech Lead y su evolución

    Al principio está el Tech Lead estresado. Slack lleno, CI en rojo, PRs eternos. Con zoneless y signals, y con automatización bien puesta, el mismo Tech Lead pasa a:

    • Planificar features, no apagar incendios.
    • Hacer code reviews que suman, no que bloquean.
    • Dormir mejor.

    Esa evolución humana es lo que importa. No solo los megabytes ahorrados.

    Qué debes hacer hoy (y por qué no esperar)

    Si inicias un proyecto: arranca con Angular 21. Nuevas apps, nueva mentalidad.
    Si tienes un monolito enterprise: haz PoCs por feature. Migra a standalone components primero.
    Si dependes mucho de librerías externas: audita antes de llevar zoneless a prod.

    Urgencia real: la competencia no duerme. Los sites que aceleran el delivery y bajan JS ganan usuarios, retención y menos bugs.

    Deprecaciones y roadmap corto

    NgModules se empuja hacia la obsolescencia. Planifica migración.
    Zone.js deja de ser el default en nuevas apps.
    View Engine fue despedido en versiones previas.

    Hay LTS y ventanas para migrar. No es un cliff, es una cuesta: sube con plan.

    Cierre con acción (simple y humano)

    No te dejo solo con teoría. Si quieres, hacemos lo siguiente:

    • Respóndeme con “Quiero migrar” y te doy un checklist de 7 pasos adaptado a tu repo.
    • O haz clic aquí (si estás leyendo esto como email/post) para agendar 15 minutos y revisamos risks.

    Beneficio claro: menos tiempo en “apagar fuegos”, más tiempo en features que mueven producto.

    Esto no acaba aquí. Angular 21 es la culminación de años de cambios. Pero cada equipo la hará suya. La versión no te convierte en mejor equipo por sí sola. Lo que sí hará es abrir un camino más eficiente. ¿Te subes o lo verás desde la grada?

    Respóndeme “Quiero migrar” y armamos el plan. No prometo milagros. Prometo claridad.

    FAQ

    ¿Cuándo se espera que Angular 21 sea lanzado?

    Angular 21 está estimado para ser lanzado en Noviembre de 2025. Esta fecha podría variar según el progreso de las implementaciones en desarrollo.

    ¿Qué cambios significativos traerá Zone.js en Angular 21?

    Zone.js dejará de ser la opción por defecto, cambiando a un enfoque zoneless que permitirá un manejo más eficaz de la detección de cambios y mejorará el rendimiento de las aplicaciones Angular.

    ¿Cómo afectará la migración a Angular 21 mi proyecto existente?

    La migración debe ser bien planificada. Se recomienda realizar pruebas con las nuevas características en entornos de desarrollo y seguir los pasos específicos para asegurar una transición suave.

    ¿Qué es la hidratación parcial y por qué es importante?

    La hidratación parcial permite que solo se ejecute JavaScript en las zonas interactivas de la aplicación, lo que reduce el tamaño del bundle y mejora la experiencia del usuario.

    ¿Por qué debo considerar la automatización durante la migración?

    Automatizar procesos como la clasificación de issues y la generación de documentación puede ahorrar tiempo y recursos valiosos durante la migración, ayudando a evitar errores y acelerando el flujo de trabajo del equipo.

    Para más información sobre cómo automatizar estos procesos, visita Dominicode Labs.