- Introduce `InjectionToken<T>` which is a parameterized and type-safe
version of `OpaqueToken`.
DEPRECATION:
- `OpaqueToken` is now deprecated, use `InjectionToken<T>` instead.
- `Injector.get(token: any, notFoundValue?: any): any` is now deprecated
use the same method which is now overloaded as
`Injector.get<T>(token: Type<T>|InjectionToken<T>, notFoundValue?: T): T;`.
Migration
- Replace `OpaqueToken` with `InjectionToken<?>` and parameterize it.
- Migrate your code to only use `Type<?>` or `InjectionToken<?>` as
injection tokens. Using other tokens will not be supported in the
future.
BREAKING CHANGE:
- Because `injector.get()` is now parameterize it is possible that code
which used to work no longer type checks. Example would be if one
injects `Foo` but configures it as `{provide: Foo, useClass: MockFoo}`.
The injection instance will be that of `MockFoo` but the type will be
`Foo` instead of `any` as in the past. This means that it was possible
to call a method on `MockFoo` in the past which now will fail type
check. See this example:
```
class Foo {}
class MockFoo extends Foo {
setupMock();
}
var PROVIDERS = [
{provide: Foo, useClass: MockFoo}
];
...
function myTest(injector: Injector) {
var foo = injector.get(Foo);
// This line used to work since `foo` used to be `any` before this
// change, it will now be `Foo`, and `Foo` does not have `setUpMock()`.
// The fix is to downcast: `injector.get(Foo) as MockFoo`.
foo.setUpMock();
}
```
PR Close#13785
Note: This checks the constructors of `@Injectable` classes more strictly.
E.g this will fail now as the constructor argument has no `@Inject` nor is
the type of the argument a DI token.
```
@Injectable()
class MyService {
constructor(dep: string) {}
}
```
Last part of #12787Closes#12787
When compiling libraries, this feature extracts the minimal information
from the directives/pipes/modules of the library into `.ngsummary.json` files,
so that applications that use this library only need to be recompiled
if one of the summary files change, but not on every change
of the libraries (e.g. one of the templates).
Only works if individual codegen for libraries is enabled,
see the `generateCodeForLibraries: false` option.
Closes#12787
Removes `CompileIdentifierMetadata.name` / `.moduleUrl`,
as well as `CompileTypeMetadata.name / moduleUrl` and
`CompileFactoryMetadata.name / moduleUrl`.
- for now only wraps the `@Input` properties and calls
to `ngOnInit`, `ngDoCheck` and `ngOnChanges` of directives.
- also groups eval sources by NgModule.
Part of #11683
BREAKING CHANGE:
- all `…Metadata` classes have been removed. Use the corresponding decorator
as constructor or for `instanceof` checks instead.
- Example:
* Before: `new ComponentMetadata(…)`
* After: `new Component(…)`
- Note: `new Component(…)` worked before as well.
Every decorator now is made of the following:
- a function that can be used
as a decorator or as a constructor. This function
also can be used for `instanceof` checks.
- a type for this function (callable and newable)
- a type that describes the shape of the data
that the user needs to pass to the decorator
as well as the instance of the metadata
The docs for decorators live at the followig places
so that IDEs can discover them correctly:
- General description of the decorator is placed on the
`...Decorator` interface on the callable function
definition
- Property descriptions are placed on the interface
that describes the metadata produces by the decorator
Miško Hevery
Dzmitry Shylovich
Tobias Bosch
Marc Laval
Chuck Jazdzewski
Bowen Ni
Joao Dias
Victor Berchet