EXCEPTION: Error: Uncaught (in promise): TypeError: Cannot read property 'isSkipSelf' of null

[info007]

[ericmartinezr]

See, dup of #8519

[beemsoft]

Try the following:

• Replace the SearchService constructor with:

constructor(@Inject(forwardRef(() => Jsonp)) jsonp: Jsonp)

• Add Jsonp to the providers list of AppComponent

[info007]

No change it didn't solved problem.

[beemsoft]

Strange, what happens on the console when you add SearchService to the bootstrap:
bootstrap(AppComponent, [SearchService])

[info007]

Same error.

[rktawni]

providers:[SearchService]

Why making AppComponent 'Injectable' when it is root component? Just make your service injectable by enter it into the providers array in your root component "AppComponent". @Injectable() is always used to make any service injectable, and to make it available same service need to be entered in providers:[] metadata in root component.

[ecozoic]

Getting the same issue here. I'm working w/ an API and I have separate services for all the API resources, and then one main service that all the separate services consume.

My setup is basically:
WidgetComponent -> WidgetService -> APIService -> Http

I get this exact error, even if my services are all decorated with @Injectable() and I have them registered as providers (also confirmed that my tsconfig.json has emitDecoratorMetadata / experimentalDecorators both set to true). @beemsoft's solution using @Inject(forwardRef(() => APIService)) in my WidgetService constructor causes the "isSkipSelf of null" error to go away. Right now I have the APIService provided at the App component level, but I have also tried at the bootstrap level as well with the same results. If I use the Inject/forwardRef approach without providing APIService at some level in the app, I get the helpful error message "No provider for APIService".

I have not had to use forwardRef before, is this expected behavior? Do you need to use it when your custom services inject other custom services?

Removing API Service and consuming Http directly in the Widget Service works fine.
WidgetComponent -> WidgetService -> Http

No need to use Inject/forwardRef for anything. But it seems adding that extra dependency in the chain causes things to mess up. Not sure if I'm missing something obvious, but definitely seems like a bug and I agree that the error message should be more helpful to assist.

EDIT -

Tried to recreate this issue in the Angular 2 Quickstart Plunkr but was unsuccessful. Seems to work fine there: plnkr

One thing I noticed is that I would get the isSkipSelf null error if I tried to inject a nested service w/o first importing the type definition for its class. Adding that import would resolve the isSkipSelf error and give me the helpful "No provider" error message until I added a provider... I'm wondering if this is less about Angular and more about build process or something. @info007 -- what's your build environment? I'm running webpack/awesome-typescript-loader with cheap-module-eval-source-maps. Going to mess around and see if anything sticks... (quick update - swapped source maps and swapped awesome-typescript loader for ts-loader.. same thing..)

[ecozoic]

I ended up finding the solution to my problem at least

#8519

Basically I can't import my service from a barrel, I have to go to the particular file.

In other words:

import { ApiService } from './services'; does not work

import { ApiService } from './services/api.service'; does

This is with Webpack using CommonJS modules. Not sure what's going on but at least it works. Barrel files are super nice to have though.

EDIT - Ok so plot thickens a bit. Its not the barrel file per se, but order matters here. Both my WidgetService and APIService are in the same barrel ('services/index.ts). If I'm going to be importing from the barrel, the imports/exports in that barrel need to be in a particular order. I need to import/export the APIService BEFORE I import/export the WidgetService. This kind of makes sense. If I import the WidgetService from the barrel but it is declared before the ApiService it depends on, you get the cryptic error message. This also explains why forwardRef works, because it's designed for when you need to refer to symbols that are not yet defined. Maybe something to do with the fact that classes are not hoisted?

export * from './widget.service';
export * from './api.service';

will throw the error

export * from './api.service';
export * from './widget.service';

will not throw the error.

Other possibilities seem to work too.

import { ApiService } from './api.service';
import { WidgetService } from './widget.service';

export { ApiService, WidgetService };

TL;DR: Be careful w/ your barrels guys!

[kingjordan]

I can confirm the what @ecozoic found out. I ended up having a circular reference to a service because the service I was using imported another service from the same folder, but I used the index.ts barrel to import it. I changed the import statement to reference the actual file and not the barrel and it solved the problem.

[pkozlowski-opensource]

Duplicate of #8519 - we've got a reproduce scenario in the other issue

[AionDev]

I hot a similar error when using angular2 forms - data driven approach.

Here it is: " Uncaught (in promise): TypeError: Cannot read property 'setParent' of null "

After 3-4 hours of continuous searching and debugging I found out that my form does not have the [formGroup]="myForm" directive on it !!
So when I tried to use my formControlName="email" without [formGroup] directive I got this cryptic error.
Of course this is a dumb mistake! But there was no way for me to know that I'm missing the formGroup directive!!
So again, before trying to do debugging or anything please verify you got all the dependencies you need all the Providers, all the directives etc..

[ericmartinezr]

@Alon-Gbbe that is not related this issue, but it seems a valid bug. Try the same with latest forms release and reproduce it in a plnkr, when you have that you may want to file an issue.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}