{ "id": "guide/migration-undecorated-classes", "title": "Missing @Directive()/@Component() decorator migration", "contents": "\n\n\n
\n mode_edit\n
\n\n\n
\n

Missing @Directive()/@Component() decorator migrationlink

\n

What does this migration do?link

\n

This migration adds an empty @Directive() decorator to undecorated\nbase classes that:

\n\n

For example, in the diff below, a @Directive() decorator is added to BaseMenu because BaseMenu uses dependency injection.

\n

Before:

\n\nexport class BaseMenu {\n constructor(private vcr: ViewContainerRef) {}\n}\n\n@Directive({selector: '[settingsMenu]'})\nexport class SettingsMenu extends BaseMenu {}\n\n

After:

\n\n@Directive()\nexport class BaseMenu {\n constructor(private vcr: ViewContainerRef) {}\n}\n\n@Directive({selector: '[settingsMenu]'})\nexport class SettingsMenu extends BaseMenu {}\n\n

In the event that a directive or component is extended by a class without a decorator, the schematic copies any inherited directive or component metadata to the derived class.

\n

Before:

\n\n@Component({\n selector: 'base-menu',\n template: '<div></div>'\n})\nclass BaseMenu {}\n\nexport class SettingsMenu extends BaseMenu {}\n\n

After:

\n\n@Component({\n selector: 'base-menu',\n template: '<div></div>'\n})\nclass BaseMenu {}\n\n@Component({\n selector: 'base-menu',\n template: '<div></div>'\n})\nexport class SettingsMenu extends BaseMenu {}\n\n

This schematic also decorates classes that use Angular field decorators, including:

\n\n

Before:

\n\nclass Base {\n @Output()\n countChanged = new EventEmitter<number>();\n}\n\n@Directive({\n selector: '[myDir]'\n})\nclass Dir extends Base {\n}\n\n

After:

\n\n@Directive() // schematic adds @Directive()\nclass Base {\n @Output()\n countChanged = new EventEmitter<number>();\n}\n\n@Directive({\n selector: '[myDir]'\n})\nclass Dir extends Base {\n}\n\n

Why is this migration necessary?link

\n

Migrating classes that use DIlink

\n

When a class has a @Directive() or @Component() decorator, the Angular compiler generates extra code to inject dependencies into the constructor.\nWhen using inheritance, Ivy needs both the parent class and the child class to apply a decorator to generate the correct code.

\n

You can think of this change as two cases: a parent class is missing a\ndecorator or a child class is missing a decorator.\nIn both scenarios, Angular's runtime needs additional information from the compiler.\nThis additional information comes from adding decorators.

\n

Decorator missing from parent classlink

\n

When the decorator is missing from the parent class, the subclass will inherit a constructor from a class for which the compiler did not generate special constructor info (because it was not decorated as a directive).\nWhen Angular then tries to create the subclass, it doesn't have the correct info to create it.

\n

In View Engine, the compiler has global knowledge, so it can look up the missing data.\nHowever, the Ivy compiler only processes each directive in isolation.\nThis means that compilation can be faster, but the compiler can't automatically infer the same information as before.\nAdding the @Directive() explicitly provides this information.

\n

In the future, add @Directive() to base classes that do not already have decorators and are extended by directives.

\n

Decorator missing from child classlink

\n

When the child class is missing the decorator, the child class inherits from the parent class yet has no decorators of its own.\nWithout a decorator, the compiler has no way of knowing that the class is a @Directive or @Component, so it doesn't generate the proper instructions for the directive.

\n

Migrating classes that use field decoratorslink

\n

In ViewEngine, base classes with field decorators like @Input() worked even when the class did not have a @Directive() or @Component() decorator.\nFor example:

\n\nclass Base {\n @Input()\n foo: string;\n}\n\n@Directive(...)\nclass Dir extends Base {\n ngOnChanges(): void {\n // notified when bindings to [foo] are updated\n }\n}\n\n

However, this example won't compile with Ivy because the Base class requires either a @Directive() or @Component() decorator to generate code for inputs, outputs, queries, and host bindings.

\n

Always requiring a class decorator leads to two main benefits for Angular:

\n
    \n
  1. \n

    The previous behavior was inconsistent.\nSome Angular features required a decorator (dependency injection), but others did not.\nNow, all Angular features consistently require a class decorator.

    \n
    2. \n
  2. \n

    Supporting undecorated classes increases the code size and complexity of Angular.\nAlways requiring class decorators allows the framework to become smaller and simpler for all users.

    \n
    3. \n
\n

What does it mean to have a @Directive() decorator with no metadata inside of it?link

\n

The presence of the @Directive decorator causes Angular to generate extra code for the affected class.\nIf that decorator includes no properties (metadata), the directive won't be matched to elements or instantiated directly, but other classes that extend the directive class will inherit this generated code.\nYou can think of this as an \"abstract\" directive.

\n

Adding an abstract directive to an NgModule will cause an error.\nA directive must have a selector property defined in order to match some element in a template.

\n

When do I need a @Directive() decorator without a selector?link

\n

If you're using dependency injection, or any Angular-specific feature, such as @HostBinding(), @ViewChild(), or @Input(), you need a @Directive() or @Component() decorator.\nThe decorator lets the compiler know to generate the correct instructions to create that class and any classes that extend it.\nIf you don't want to use that base class as a directive directly, leave the selector blank.\nIf you do want it to be usable independently, fill in the metadata as usual.

\n

Classes that don't use Angular features don't need an Angular decorator.

\n

I'm a library author. Should I add the @Directive() decorator to base classes?link

\n

As support for selectorless decorators is introduced in Angular version 9, if you want to support Angular version 8 and earlier, you shouldn't add a selectorless @Directive() decorator.\nYou can either add @Directive() with a selector or move the Angular-specific features to affected subclasses.

\n

What about applications using non-migrated libraries?link

\n

The Angular compatibility compiler (ngcc) should automatically transform any non-migrated libraries to generate the proper code.

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