- 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
When lazily loading code, users need to be able to get hold of the
NgModuleFactory. For SystemJS environments, the SystemJS registry serves
this purpose. However other environments, such as modules compiled with
Closure compiler, do not expose exports object or a path based registry.
For these environments, `@NgModule` objects can include an identifier, and
the loading code can then pass `loadModule(id).then(() =>
getNgModule(id))` to the router.
closes#11145
Also rename `CompileIdentifierMetadata.runtime` into `CompileIdentifierMetadata.reference`.
Also remove `CompileIdentifierMetadata.equalsTo` as
now it is enough to just check the `reference` fields for equality.
BREAKING CHANGE:
Exceptions are no longer part of the public API. We don't expect that anyone should be referring to the Exception types.
ExceptionHandler.call(exception: any, stackTrace?: any, reason?: string): void;
change to:
ErrorHandler.handleError(error: any): void;
BREAKING CHANGE: previously deprecated @Component.directives and @Component.pipes support was removed.
All the components and pipes now must be declarated via an NgModule. NgModule is the basic
compilation block passed into the Angular compiler via Compiler#compileModuleSync or #compileModuleAsync.
Because of this change, the Compiler#compileComponentAsync and #compileComponentSync were removed as well -
any code doing compilation should compile module instead using the apis mentioned above.
Lastly, since modules are the basic compilation unit, the ngUpgrade module was modified to always require
an NgModule to be passed into the UpgradeAdapter's constructor - previously this was optional.
Closes#9751
BREAKING CHANGE:
These forms of providers are no longer accepted:
bind(MyClass).toFactory(...)
new Provider(MyClass, toFactory: ...)
We now only accept:
{provider: MyClass, toFactory: ...}
Closes#9729
BREAKING CHANGE:
`Type` is now `Type<T>` which means that in most cases you have to
use `Type<any>` in place of `Type`.
We don't expect that any user applications use the `Type` type.
If a `@NgModule` has a `bootstrap` property, `PlatformRef.bootstrapModule` /
`PlatformRef.bootstrapModuleFactory` will automatically bootstrap the components
listed in there.
If such a property does not exist, `PlatformRef.bootstrapModule` /
`PlatformRef.bootstrapModuleFactory` will try to call the method `ngDoBootstrap(appRef: ApplicationRef)` on the module class.
Otherwise an error is reported.
