Erro DI Angular – EXCEÇÃO: Não é possível resolver todos os parâmetros

Eu criei um aplicativo básico no Angular, mas encontrei um problema estranho em que não posso injetar um serviço em um dos meus componentes. Ele injeta bem em qualquer um dos outros três componentes que eu criei no entanto.

Para começar, este é o serviço:

import { Injectable } from '@angular/core'; @Injectable() export class MobileService { screenWidth: number; screenHeight: number; constructor() { this.screenWidth = window.outerWidth; this.screenHeight = window.outerHeight; window.addEventListener("resize", this.onWindowResize.bind(this) ) } onWindowResize(ev: Event) { var win = (ev.currentTarget as Window); this.screenWidth = win.outerWidth; this.screenHeight = win.outerHeight; } } 

E o componente com o qual ele se recusa a trabalhar:

 import { Component, } from '@angular/core'; import { NgClass } from '@angular/common'; import { ROUTER_DIRECTIVES } from '@angular/router'; import {MobileService} from '../'; @Component({ moduleId: module.id, selector: 'pm-header', templateUrl: 'header.component.html', styleUrls: ['header.component.css'], directives: [ROUTER_DIRECTIVES, NgClass], }) export class HeaderComponent { mobileNav: boolean = false; constructor(public ms: MobileService) { console.log(ms); } } 

O erro que recebo no console do navegador é este:

EXCEÇÃO: Não é possível resolver todos os parâmetros para o HeaderComponent: (?).

Eu tenho o serviço na function de bootstrap para que ele tenha um provedor. E eu pareço ser capaz de injetar no construtor de qualquer um dos meus outros componentes sem problema.

Importe-o do arquivo onde ele é declarado diretamente, em vez do barril.

Eu não sei exatamente o que causa o problema, mas eu o vi mencionado várias vezes (provavelmente algum tipo de dependência circular).

Também deve ser reparável, alterando a ordem das exportações no barril (não sei detalhes, mas foi mencionado também)

Além das respostas anteriores, parece que este erro também é lançado quando o seu serviço injetável não possui o decorador @Injectable() real. Portanto, antes de depurar a coisa de dependência cíclica e a ordem de suas importações / exportações, faça uma simples verificação de que seu serviço realmente tem @Injectable() definido.

Isso se aplica ao Angular mais recente, o Angular 2.1.0.

Eu abri uma questão sobre este assunto .

A partir do Angular 2.2.3 existe agora uma function de utilidade forwardRef() que permite injetar provedores que ainda não foram definidos.

Por não definido, quero dizer que o mapa de injeção de dependência não conhece o identificador. É o que acontece durante as dependencies circulares. Você pode ter dependencies circulares no Angular que são muito difíceis de serem desenhadas e ver.

 export class HeaderComponent { mobileNav: boolean = false; constructor(@Inject(forwardRef(() => MobileService)) public ms: MobileService) { console.log(ms); } } 

Adicionar @Inject(forwardRef(() => MobileService)) ao parâmetro do construtor no código-fonte da pergunta original corrigirá o problema.

Referências

Angular 2 Manual: ForwardRef

Referências futuras no Angular 2

WRONG # 1: Forgetting Decorator:

 //Uncaught Error: Can't resolve all parameters for MyFooService: (?). export class MyFooService { ... } 

ERRADO # 2: Omitindo o símbolo “@”:

 //Uncaught Error: Can't resolve all parameters for MyFooService: (?). Injectable() export class MyFooService { ... } 

ERRADO # 3: Omitindo “()” Símbolos:

 //Uncaught Error: Can't resolve all parameters for TypeDecorator: (?). @Injectable export class MyFooService { ... } 

ERRADO # 4: “i” minúsculo:

 //Uncaught ReferenceError: injectable is not defined @injectable export class MyFooService { ... } 

ERRADO # 5: Você esqueceu: import {Injectable} de ‘@ angular / core’;

 //Uncaught ReferenceError: Injectable is not defined @Injectable export class MyFooService { ... } 

CORRIGIR:

 @Injectable() export class MyFooService { ... } 

Como já foi dito, a questão é causada pela ordem de exportação dentro do barril, que é causada por dependencies circulares.

Uma explicação mais detalhada está aqui: https://stackoverflow.com/a/37907696/893630

Eu também encontrei isso injetando o serviço A no serviço B e vice-versa.

Pessoalmente, estou feliz que isso falhe rápido, como provavelmente deve ser evitado de qualquer maneira . Se você quiser que seus serviços sejam mais modulares / reutilizáveis, é melhor evitar referências circulares, tanto quanto possível. Este post destaca as armadilhas que cercam isso.

Portanto, tenho as seguintes recomendações:

  • Se você acha que as classs estão interagindo com muita frequência (estou falando de inveja de resources ), talvez você queira considerar a fusão dos dois serviços em uma class .
  • Se o acima não funcionar, considere usar um terceiro serviço (um EventService ) que ambos os serviços podem injetar para trocar mensagens.

Para o benefício dos pesquisadores; Eu tenho esse erro. Foi simplesmente um símbolo @ ausente.

Can't resolve all parameters for MyHttpService seja, isso produz o erro Can't resolve all parameters for MyHttpService .

 Injectable() export class MyHttpService{ } 

Adicionar o símbolo @ ausente corrige.

 @Injectable() export class MyHttpService{ } 

Você obtém este erro se tiver o serviço A que depende de uma propriedade / método estático do serviço B e o próprio serviço B depender do serviço A através da injeção de dependência. Portanto, é um tipo de dependência circular, embora não seja, pois a propriedade / método é estática. Provavelmente um bug que ocorre em combinação com o AOT .

Além do faltante @Injectable() decorador

O decorador @Injectable() na class abstrata produziu o Não é possível resolver todos os parâmetros para o serviço: (?) O decorador precisa estar presente no MyService , bem como na class derivada BaseService

 //abstract class @Injectable() abstract class BaseService { ... } //MyService @Injectable() export class MyService extends BaseService { ..... } 

Removendo parâmetros do método constructor () injetável resolvi para o meu caso.

No meu caso, isso aconteceu porque eu não declarei o tipo para um parâmetro de construtor.

Eu tive algo assim:

 constructor(private URL, private http: Http) { } 

e depois mudá-lo para o código abaixo resolveu o meu problema.

 constructor(private URL : string, private http: Http) {} 

No meu caso, eu precisava adicionar import "core-js/es7/reflect"; ao meu aplicativo para fazer o trabalho @Injectable .

para mim foi apenas falta de () em @Injectable. Proper é @Injectable ()

No meu caso foi por causa do plugin Augury, desabilite ele vai funcionar bem. Opção alternativa é aot, também funciona.

todos os créditos para @ Boboss74, ele postou a resposta aqui: https://github.com/angular/angular/issues/23958

Bem, para mim o problema foi ainda mais irritante, eu estava usando um serviço dentro de um serviço e esqueci de adicioná-lo como dependência no appModule! Espero que isso ajude alguém a economizar várias horas quebrando o aplicativo apenas para reconstruí-lo novamente

No meu caso, passando parâmetros errados para o construtor gera este erro, a idéia básica sobre esse erro é que você inadvertidamente passou alguns argumentos errados para qualquer function.

 export class ProductComponent { productList: Array; constructor(productList:Product) { // productList:Product this arg was causing error of unresolved parameters. this.productList = []; } } 

Eu resolvi isso apenas removendo esse argumento.

Para mim, eu recebi este erro quando por engano desabilitei esta importação no arquivo polyfills.ts, você precisa garantir que ele seja importado para evitar esse erro.

 /** Evergreen browsers require these. **/ // Used for reflect-metadata in JIT. If you use AOT (and only Angular decorators), you can remove. import 'core-js/es7/reflect'; 

Eu encontrei este erro por erro de digitação do nome do serviço, ou seja, construtor ( myService privado : MyService ).

Para os serviços com erros ortocharts, eu era capaz de determinar qual serviço era o problema (eu tinha vários listados no construtor) inspecionando a página no Chrome-> Console. Você verá como parte da mensagem uma lista de matriz de “parâmetros” exibindo o object Objeto, object Objeto? (ou algo assim). Observe onde o “?” é e essa é a posição do serviço que está causando o problema.

Embora o pedido de classs exportadas de dentro de barris possa ter sido mencionado, o cenário a seguir também pode produzir o mesmo efeito.

Suponha que você tenha classs A , B e C exportadas de dentro do mesmo arquivo onde A depende de B e C :

 @Injectable() export class A { /** dependencies injected */ constructor(private b: B, private c: C) {} } @Injectable() export class B {...} @Injectable() export class C {...} 

Uma vez que as classs dependentes (ie, classs B e C ) ainda não são conhecidas pelo Angular, ( provavelmente em tempo de execução durante o processo de injeção de dependência do Angular na class A ) o erro é levantado.

Solução

A solução é declarar e exportar as classs dependentes antes da class em que o DI é feito.

isto é, no caso acima, a class A é declarada logo após suas dependencies serem definidas:

 @Injectable() export class B {...} @Injectable() export class C {...} @Injectable() export class A { /** dependencies injected */ constructor(private b: B, private c: C) {} } 

Outra possibilidade é não ter emitDecoratorMetadata definido como true em tsconfig.json

 { "compilerOptions": { ... "emitDecoratorMetadata": true, ... } } 

Ao usar importações de barris – considere a importação de injetáveis ​​primeiro como regra geral.

Isso acontece quando se refere uma interface também.

Mudando a interface para a class fixa, trabalhando com e sem @Inject .

Você precisa adicionar array de provedores no decorador @Component ou no módulo onde seu componente está declarado. Componente dentro você pode fazer como abaixo:

 @Component({ moduleId: module.id, selector: 'pm-header', templateUrl: 'header.component.html', styleUrls: ['header.component.css'], directives: [ROUTER_DIRECTIVES, NgClass], providers: [MobileService] }) 

Às vezes isso acontece quando você declara o módulo interno do Angular (HttpClientModule, HttpErrorResponse etc) em app.module.js. Eu também enfrentei o mesmo problema, mas resolvi agora.

O erro que eu fiz foi mencionar HttpClientModule em provedores em vez de importação de módulo angular

Para mim, foi porque eu tinha uma linha vazia entre meu decorador @Component e minha class Component. Isso fez com que o decorador não fosse aplicado à turma.

No meu caso, eu estava exportando uma class e um Enum do mesmo arquivo de componente:

mComponent.component.ts :

 export class MyComponentClass{...} export enum MyEnum{...} 

Então, eu estava tentando usar MyEnum de um filho de MyComponentClass . Isso estava causando o erro Não é possível resolver todos os parâmetros .

Ao mover o MyEnum em uma pasta separada do MyComponentClass , isso resolveu meu problema!

Como Günter Zöchbauer mencionou, isso está acontecendo porque um serviço ou componente é dependente de circularidade.

No meu caso, tomei uma dependência em um serviço que não tinha dependencies e, portanto, não incluí uma function constructor() na class de serviço. Eu adicionei um construtor sem parâmetros à class de serviço dependente e tudo começou a funcionar.

No meu caso, eu estava tentando estender ” NativeDateAdapter ” para replace o método ” format(date: Date, displayFormat: Object) “.

Em AngularMaterial-2 DatePicker.

Então basicamente eu esqueci de adicionar a anotação @Injectable .

Depois de adicionar isso à minha class “CustomDateAdapter”:

 @Injectable({ providedIn: 'root' }) 

Erro foi embora.

Se o serviço estiver definido no mesmo arquivo que um componente (que o consome) e o serviço estiver definido após o componente no arquivo, você poderá receber esse erro. Isso se deve ao mesmo problema “forwardRef” que outros mencionaram. Neste momento, o VSCode não é muito bom em mostrar esse erro e a compilation é compilada com êxito.

Executar a compilation com --aot pode mascarar esse problema devido à maneira como o compilador funciona (provavelmente relacionado a tremer de trees).

Solução: verifique se o serviço está definido em outro arquivo ou antes da definição do componente. (Eu não tenho certeza se forwardRef pode ser usado neste caso, mas parece desajeitado fazê-lo).

Se eu tenho um serviço muito simples que é fortemente ligado a um componente (como um modelo de visão) – por exemplo. ImageCarouselComponent , eu posso nomeá-lo como ImageCarouselComponent.service.ts para que ele não fique todo misturado com meus outros serviços.

Parece dependência circular, Se você usar angular> = 4 para que você possa se livrar de intex.ts (barril) e importar tudo o que você precisa diretamente.