Manejo de Promesas y Fetch en Angular sin RXJS

Contenido del curso

Configuración Inicial

Gestión de Entornos

Nuevas Funcionalidades en Angular

Server-Side Rendering (SSR) y Navegación

Optimización de Rendimiento

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:59

Manejo de Promesas y Fetch en Angular sin RXJS

Curso de Angular Avanzado

Clase 19 de 36

Clase 19 / 36

Recursos

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:

RxResource: Para trabajar con Observables de RxJS
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.

  async getProductsPromise(params: {
    categoryId?: string;
    category_slug?: string;
  }): Promise<Product[]> {
    const url = new URL(`${environment.apiUrl}/api/v1/products`);
    if (params.categoryId) {
      url.searchParams.set('categoryId', params.categoryId);
    }
    if (params.category_slug) {
      url.searchParams.set('categorySlug', params.category_slug);
    }

    const response = await fetch(url.toString());
    const data = await response.json();
    return data;
  }

  async getOnePromise(params: {
    id?: string;
    slug?: string;
  }): Promise<Product> {
    if (params.id) {
      const response = await fetch(
        `${environment.apiUrl}/api/v1/products/${params.id}`
      );
      const data = await response.json();
      return data;
    }

    if (params.slug) {
      const response = await fetch(
        `${environment.apiUrl}/api/v1/products/slug/${params.slug}`
      );
      const data = await response.json();
      return data;
    }

    throw new Error('Se produjo un error');
  }

import {
  Component,
  inject,
  input,
  linkedSignal,
  resource,
} from '@angular/core';
import { CommonModule, NgOptimizedImage } from '@angular/common';
import { ProductService } from '@shared/services/product.service';
import { CartService } from '@shared/services/cart.service';

@Component({
  selector: 'app-product-detail',
  imports: [CommonModule, NgOptimizedImage],
  templateUrl: './product-detail.component.html',
})
export default class ProductDetailComponent {
  private productService = inject(ProductService);
  private cartService = inject(CartService);
  readonly $slug = input<string>();

  productResource = resource({
    request: () => ({ slug: this.$slug() }),
    loader: ({ request }) => this.productService.getOnePromise(request),
  });
  $cover = linkedSignal({
    source: () => this.productResource.value(),
    computation: product => {
      if (product && product.images.length > 0) {
        return product.images[0];
      }
      return '';
    },
  });

  changeCover(newImg: string) {
    this.$cover.set(newImg);
  }

  addToCart() {
    const product = this.productResource.value();
    if (product) {
      this.cartService.addToCart(product);
    }
  }
}

```&#x20;

Resumen

¿Cómo trabajar con promesas en Angular moderno?

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:

RxResource: Para trabajar con Observables de RxJS
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());

¿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.

  async getProductsPromise(params: {
    categoryId?: string;
    category_slug?: string;
  }): Promise<Product[]> {
    const url = new URL(`${environment.apiUrl}/api/v1/products`);
    if (params.categoryId) {
      url.searchParams.set('categoryId', params.categoryId);
    }
    if (params.category_slug) {
      url.searchParams.set('categorySlug', params.category_slug);
    }

    const response = await fetch(url.toString());
    const data = await response.json();
    return data;
  }

  async getOnePromise(params: {
    id?: string;
    slug?: string;
  }): Promise<Product> {
    if (params.id) {
      const response = await fetch(
        `${environment.apiUrl}/api/v1/products/${params.id}`
      );
      const data = await response.json();
      return data;
    }

    if (params.slug) {
      const response = await fetch(
        `${environment.apiUrl}/api/v1/products/slug/${params.slug}`
      );
      const data = await response.json();
      return data;
    }

    throw new Error('Se produjo un error');
  }

import {
  Component,
  inject,
  input,
  linkedSignal,
  resource,
} from '@angular/core';
import { CommonModule, NgOptimizedImage } from '@angular/common';
import { ProductService } from '@shared/services/product.service';
import { CartService } from '@shared/services/cart.service';

@Component({
  selector: 'app-product-detail',
  imports: [CommonModule, NgOptimizedImage],
  templateUrl: './product-detail.component.html',
})
export default class ProductDetailComponent {
  private productService = inject(ProductService);
  private cartService = inject(CartService);
  readonly $slug = input<string>();

  productResource = resource({
    request: () => ({ slug: this.$slug() }),
    loader: ({ request }) => this.productService.getOnePromise(request),
  });
  $cover = linkedSignal({
    source: () => this.productResource.value(),
    computation: product => {
      if (product && product.images.length > 0) {
        return product.images[0];
      }
      return '';
    },
  });

  changeCover(newImg: string) {
    this.$cover.set(newImg);
  }

  addToCart() {
    const product = this.productResource.value();
    if (product) {
      this.cartService.addToCart(product);
    }
  }
}

```&#x20;

Comentarios (4)4 comentarios

Reinaldo Mendoza

Hace 2 años

Los pipes en los observables son herramientas poderosas, supongo que han de existir sus alternativas nativas en la transición a fetch

Emilio Nicolás Mendoza Patti

Dejo aqui porque me costo un poco hacer la modificacion para pasar la parte de product-details a resources y utilizar fetch:

Y asi quedo product-details.components.ts

Mauricio Pinzón

Hace un año

que es recomendable usar o de que forma se trabajaria los interceptors para fetch ya que estos solo funcionaban con HttpClient? cual es la alternativa y recomendada por google?

Me parece que no esta tan clara esta parte de la migración/convivencia rxjs y signals

Pienso que ambas formas tienen los suyo, como decis en el comentario de mas arriba, los pipes, maps y todos los operadores que tiene rxjs son buenisimos, pero al mismo tiempo es una libreria mas para cargar en nuestra app y lo nativo tiende a ser mas limpio y mas facil de aprender aveces, mas que siempre se esta actualizando. Me gusta esto de que angular permita esta versatilidad y nos deje seguir usando lo mejor de los 2 mundos.

Configuración Inicial

Curso Avanzado de Desarrollo con Angular para eCommerce

Clona y explora el proyecto base de Angular

Configuración de ESLint y Prettier en proyectos Angular

Prettier y ESLint sin conflictos en Angular

Gestión de Entornos

Manejo de environments en Angular

Ambiente de staging en Angular paso a paso

Nuevas Funcionalidades en Angular

Variables locales con @let en Angular

Lazy loading de imágenes con ngSrc en Angular

URLs amigables para SEO en Angular

"Reactividad en Angular: Migración a Input Signals"

Migración automática de @Input a signals en Angular

Migración de Outputs en Angular: De Decoradores a Funciones

linkedSignal en Angular: computed con set

Sincronización de Componentes en Angular con Model y Signals

toSignal: Observables de RxJS como Signals

Conversión de Observables a Signals en Angular con toSignal

Interoperabilidad de RXDS y Signals en Angular: Uso de RX Resourcers

Manejo de Parámetros Reactivos con RX Resource en Angular

Manejo de Promesas y Fetch en Angular sin RXJS

Reactividad en Angular: Uso de Signals para Consultas DOM

Configuración de Prettier para HTML en Angular

Server-Side Rendering (SSR) y Navegación

Migración al Application Builder de Angular

Server Side Rendering con Angular: Mejora Rendimiento y SEO

afterNextRender: código seguro solo en el browser

Geolocalización y APIs: Creando un Mapa de Tiendas Cercanas

Pre-rendering en Angular con ng build

Desplegando Angular SSR en Firebase

Optimización de Rendimiento

Generación de Meta Tags Dinámicos con Angular y Open Graph

Creación de MetaTags Dinámicos en Angular

Proceso de Hydration y Event Replay en Angular

Productos relacionados con RxResource en Angular

Carga diferida de componentes en Angular para mejorar rendimiento

Optimización de Incremental Hydration en Angular

Configuración de Server Routing en Angular

Aplicaciones Sin Zone.js: Migración a Signals en Angular

Cierre del curso avanzado de Angular

Manejo de Promesas y Fetch en Angular sin RXJS