{ "id": "guide/migration-injectable", "title": "Migration for missing @Injectable() decorators and incomplete provider definitions", "contents": "\n\n\n
\n mode_edit\n
\n\n\n
\n

Migration for missing @Injectable() decorators and incomplete provider definitionslink

\n

What does this schematic do?link

\n
    \n
  1. This schematic adds an @Injectable() decorator to classes which are provided in the\napplication but are not decorated.
    2. \n
  2. The schematic updates providers which follow the {provide: SomeToken} pattern\nto explicitly specify useValue: undefined.
    3. \n
\n

Example for missing @Injectable()

\n

Before migration:

\n\nexport class MyService {...}\nexport class MyOtherService {...}\nexport class MyThirdClass {...}\nexport class MyFourthClass {...}\nexport class MyFifthClass {...}\n\n@NgModule({\n providers: [\n MyService,\n {provide: SOME_TOKEN, useClass: MyOtherService},\n // The following classes do not need to be decorated because they\n // are never instantiated and just serve as DI tokens.\n {provide: MyThirdClass, useValue: ...},\n {provide: MyFourthClass, useFactory: ...},\n {provide: MyFifthClass, useExisting: ...},\n ]\n})\n\n

After migration:

\n\n@Injectable()\nexport class MyService {...}\n@Injectable()\nexport class MyOtherService {...}\nexport class MyThirdClass {...}\nexport class MyFourthClass {...}\nexport class MySixthClass {...}\n\n...\n\n

Note that MyThirdClass, MyFourthClass and MyFifthClass do not need to be decorated\nwith @Injectable() because they are never instantiated, but just used as a DI token.

\n

Example for provider needing useValue: undefined

\n

This example shows a provider following the {provide: X} pattern.\nThe provider needs to be migrated to a more explicit definition where useValue: undefined is specified.

\n

Before migration:

\n\n{provide: MyToken}\n\n

After migration:

\n\n{provide: MyToken, useValue: undefined}\n\n

Why is adding @Injectable() necessary?link

\n

In our docs, we've always recommended adding @Injectable() decorators to any class that is provided or injected in your application.\nHowever, older versions of Angular did allow injection of a class without the decorator in certain cases, such as AOT mode.\nThis means if you accidentally omitted the decorator, your application may have continued to work despite missing @Injectable() decorators in some places.\nThis is problematic for future versions of Angular.\nEventually, we plan to strictly require the decorator because doing so enables further optimization of both the compiler and the runtime.\nThis schematic adds any @Injectable() decorators that may be missing to future-proof your app.

\n

Why is adding useValue: undefined necessary?link

\n

Consider the following pattern:

\n\n@NgModule({\n providers: [{provide: MyService}]\n})\n\n

Providers using this pattern will behave as if they provide MyService as DI token\nwith the value of undefined.\nThis is not the case in Ivy where such providers will be interpreted as if useClass: MyService is specified.\nThis means that these providers will behave differently when updating to version 9 and above.\nTo ensure that the provider behaves the same as before, the DI value should be explicitly set to undefined.

\n

When should I be adding @Injectable() decorators to classes?link

\n

Any class that is provided must have an @Injectable() decorator.\nThe decorator is necessary for the framework to properly create an instance of that class through DI.

\n

However, classes which are already decorated with @Pipe, @Component or @Directive do not need both decorators.\nThe existing class decorator already instructs the compiler to generate the\nneeded information.

\n

Should I update my library?link

\n

Yes, if your library has any classes that are meant to be injected, they should be updated with the @Injectable() decorator.\nIn a future version of Angular, a missing @Injectable() decorator will always throw an error.

\n

Additionally, providers in your library that follow the described {provide: X} pattern should be updated to specify an explicit value.\nWithout explicit value, these providers can behave differently based on the Angular version in applications consuming your library.

\n\n \n
\n\n\n" }