No provider for HttpClient en Angular: 5 soluciones 2025

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

«No provider for HttpClient» — el error que enfurece a todos

\n\n

Escribes un servicio en Angular, conectas HttpClient en el constructor, ejecutas la aplicación... ¡Y entonces, pum! La consola del navegador se inunda de rojo: NullInjectorError: No provider for HttpClient. ¿Te suena?

\n\n

Este error es un auténtico «rito de iniciación» para cada desarrollador de Angular. En Stack Overflow se ha discutido más de 400 mil veces, y en 2025 sigue atrapando tanto a novatos como a experimentados. Pero la buena noticia es: hay solución, y no solo una.

\n\n

En este artículo analizaremos 5 mejores prácticas para vencer No provider for HttpClient en Angular 18+ y TypeScript. ¡Allá vamos!

\n\n

¿Por qué ocurre «No provider for HttpClient»?

\n\n

La esencia del error es simple: Angular no sabe cómo crear una instancia de HttpClient. En Angular se utiliza dependency injection (DI) — un contenedor que gestiona la creación de objetos. Si solicitas HttpClient y el contenedor DI no tiene la receta para construirlo, se produce el error.

\n\n

La situación clásica:

\n\n
import { Injectable } from '@angular/core';\nimport { HttpClient } from '@angular/common/http';\n\n@Injectable({ providedIn: 'root' })\nexport class DataService {\n  constructor(private http: HttpClient) {} // ❌ Error: No provider for HttpClient\n}\n
\n\n

Angular dice: «Veo que quieres HttpClient, pero no sé dónde conseguirlo». Y es lógico: olvidamos importar el módulo o proveedor que registra HttpClient en el contenedor DI.

\n\n

Mejores prácticas 2025: 5 formas de corregir el error

\n\n

1. Clásico: HttpClientModule (Angular hasta 18)

\n\n

La forma más antigua y probada es importar HttpClientModule en el módulo raíz de la aplicación.

\n\n
// app.module.ts\nimport { NgModule } from '@angular/core';\nimport { BrowserModule } from '@angular/platform-browser';\nimport { HttpClientModule } from '@angular/common/http';\nimport { AppComponent } from './app.component';\n\n@NgModule({\n  declarations: [AppComponent],\n  imports: [\n    BrowserModule,\n    HttpClientModule // ✅ Aquí está, el salvador\n  ],\n  providers: [],\n  bootstrap: [AppComponent]\n})\nexport class AppModule { }\n
\n\n

Este método funciona en Angular 2–17. En 2025 sigue siendo relevante si utilizas arquitectura basada en NgModule. Inconveniente: añade todo el módulo HttpClient, incluso si solo necesitas la funcionalidad básica.

\n\n

2. Estándar moderno: provideHttpClient() (Angular 15+)

\n\n

Con la llegada de los standalone components, Angular pasó a proveedores funcionales. Ahora, en lugar del módulo, usas la función provideHttpClient.

\n\n
// main.ts (standalone bootstrap)\nimport { bootstrapApplication } from '@angular/platform-browser';\nimport { provideHttpClient } from '@angular/common/http';\nimport { AppComponent } from './app/app.component';\n\nbootstrapApplication(AppComponent, {\n  providers: [\n    provideHttpClient() // ✅ Registramos HttpClient\n  ]\n}).catch(err => console.error(err));\n
\n\n

Esta es la forma recomendada en Angular 18+ y 2025. Es más ligera, más rápida y no arrastra código innecesario. Si estás escribiendo una aplicación nueva, úsala.

\n\n

3. Avanzado: provideHttpClient() con withFetch()

\n\n

A partir de Angular 17, surgió la posibilidad de usar la fetch API en lugar de XMLHttpRequest. Esto proporciona un aumento de rendimiento y soporte para funciones modernas (por ejemplo, streaming).

\n\n
import { bootstrapApplication } from '@angular/platform-browser';\nimport { provideHttpClient, withFetch } from '@angular/common/http';\nimport { AppComponent } from './app/app.component';\n\nbootstrapApplication(AppComponent, {\n  providers: [\n    provideHttpClient(\n                

Blogs

Book Recommendations