Manejo de Promesas y Fetch en Angular sin RXJS

La evolución de Angular hacia un enfoque más flexible en el manejo de la reactividad está transformando la forma en que desarrollamos aplicaciones. Con la introducción de Signals y Resources, Angular nos ofrece alternativas al tradicional patrón de Observables de RxJS, permitiendo a los equipos de desarrollo elegir las herramientas que mejor se adapten a sus necesidades y preferencias. Esta libertad de elección representa un cambio significativo en la filosofía del framework, orientado a reducir la curva de aprendizaje y proporcionar mayor flexibilidad.

¿Cómo trabajar con promesas en Angular moderno?

Angular está evolucionando para hacer que RxJS sea opcional en lugar de obligatorio. Esto significa que ahora podemos elegir entre seguir utilizando Observables o migrar hacia un enfoque basado en promesas, más familiar para desarrolladores JavaScript. Esta flexibilidad permite a los equipos tomar decisiones conscientes sobre las herramientas que desean utilizar en sus proyectos.

Para implementar un enfoque basado en promesas, podemos modificar nuestros servicios para utilizar el método fetch nativo de JavaScript en lugar del HttpClient de Angular:

getAll(): Promise<Category[]> {
  return fetch('url/to/categories')
    .then(response => response.json())
    .then(data => data);
}

Este enfoque resulta más intuitivo para desarrolladores que están familiarizados con JavaScript moderno pero no necesariamente con el paradigma de programación reactiva que propone RxJS.

Transición de RxResource a Resource

Cuando trabajamos con promesas en lugar de Observables, necesitamos adaptar la forma en que consumimos estos datos en nuestros componentes. Angular proporciona dos herramientas principales:

1. RxResource: Para trabajar con Observables de RxJS
2. Resource: Para trabajar con Promesas

Si estamos migrando de un servicio que devuelve Observables a uno que devuelve Promesas, simplemente necesitamos cambiar de rxResource a resource:

// Antes (con Observables)
categories = rxResource(this.categoriesService.getAll());

// Después (con Promesas)
categories = resource(this.categoriesService.getAllPromise());

Es importante destacar que la API de ambos métodos es prácticamente idéntica, lo que facilita enormemente la transición entre uno y otro enfoque. Las dependencias y la forma de declarar los estados derivados se mantienen consistentes, independientemente de si estamos trabajando con Observables o Promesas.

¿Cuándo elegir Resource o RxResource?

La elección entre Resource y RxResource depende principalmente de las necesidades y preferencias de tu equipo de desarrollo:

• Usa RxResource si:

  • Tienes una base de código existente con muchos Observables.
  • Tu equipo está familiarizado y cómodo con RxJS.
  • Necesitas operaciones complejas como combinación de flujos, throttling, debouncing, etc.

• Usa Resource si:

  • Quieres reducir dependencias en tu aplicación.
  • Prefieres un código más sencillo y familiar para nuevos desarrolladores.
  • Estás creando nuevos servicios y quieres adoptar un enfoque más ligero.

Una estrategia pragmática podría ser mantener RxJS para el código existente mientras adoptas el enfoque basado en promesas para nuevos desarrollos, permitiendo una transición gradual.

Ventajas de hacer opcional RxJS en Angular

La decisión de Angular de hacer que RxJS sea opcional ofrece varias ventajas significativas:

• Menor curva de aprendizaje: Los nuevos desarrolladores no necesitan dominar conceptos complejos de programación reactiva desde el principio.
• Reducción del tamaño del bundle: Al eliminar RxJS como dependencia obligatoria, el tamaño final de la aplicación puede reducirse.
• Mayor flexibilidad: Los equipos pueden elegir las herramientas que mejor se adapten a sus necesidades específicas.
• Código más familiar: El uso de promesas y fetch es más común en el ecosistema JavaScript general.

Implementación práctica

Para implementar este enfoque en un servicio existente, podemos crear un método alternativo que utilice promesas:

// Servicio con ambos enfoques
export class CategoriesService {
  // Enfoque tradicional con Observable
  getAll(): Observable<Category[]> {
    return this.http.get<Category[]>('url/to/categories');
  }
  
  // Nuevo enfoque con Promise
  getAllPromise(): Promise<Category[]> {
    return fetch('url/to/categories')
      .then(response => response.json());
  }
}

Esto permite una migración gradual y da flexibilidad a los consumidores del servicio para elegir el enfoque que prefieran.

La evolución de Angular hacia un framework más flexible y menos prescriptivo representa un cambio positivo que permite a los desarrolladores tomar decisiones más conscientes sobre las herramientas que utilizan. Ya sea que prefieras seguir con RxJS o adoptar un enfoque basado en promesas, Angular ahora te ofrece la libertad de elegir sin sacrificar funcionalidad. ¿Has comenzado a utilizar Signals y Resources en tus proyectos? ¿Prefieres el enfoque tradicional con Observables o estás considerando migrar a promesas? Comparte tu experiencia en los comentarios.