Add support for the `$postDigest()` and `$onDestroy()` lifecycle hooks.
Better align the behavior of the `$onChanges()` and `$onInit()` lifecycle hooks
with Angular 1.x:
- Call `$onInit()` before pre-linking.
- Always instantiate the controller before calling `$onChanges()`.
Add upgrade-static.umd.js bundles
This allows depending on it without getting a transitive dependency on compiler.
BREAKING CHANGE:
Four newly added APIs in 2.2.0-beta:
downgradeComponent, downgradeInjectable, UpgradeComponent, and UpgradeModule
are no longer exported by @angular/upgrade.
Import these from @angular/upgrade/static instead.
This commit introduces a new API to the ngUpgrade module, which is compatible
with AoT compilation. Primarily, it removes the dependency on reflection
over the Angular 2 metadata by introducing an API where this information
is explicitly defined, in the source code, in a way that is not lost through
AoT compilation.
This commit is a collaboration between @mhevery (who provided the original
design of the API); @gkalpak & @petebacondarwin (who implemented the
API and migrated the specs from the original ngUpgrade tests) and @alexeagle
(who provided input and review).
This commit is an starting point, there is still work to be done:
* add more documentation
* validate the API via internal projects
* align the ngUpgrade compilation of A1 directives closer to the real A1
compiler
* add more unit tests
* consider support for async `templateUrl` A1 upgraded components
Closes#12239
The `addProvider` function in the `UpgradeAdapter` was deprecated in this [commit](d21331e902 (diff-77163e956a7842149f583846c1c01651)) and has been removed in final. Given this, the documentation for downgrading ng2 providers for use in ng1 is invalid.
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.
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.
ngc can now validate metadata before emitting to verify it doesn't
contain an error symbol that will result in a runtime error if
it is used by the StaticReflector.
To enable this add the section,
"angularCompilerOptions": {
"strictMetadataEmit": true
}
to the top level of the tsconfig.json file passed to ngc.
Enabled metadata validation for packages that are intended to be
used statically.
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.
We changed the bootstrap order:
1. create NgZone
2. bootstrap ng1 inside NgZone and upgrade ng1 components to ng2 components.
3. bootstrap ng2 with NgZone
Note: Previous footgun behavior was: bootstrap ng2 first to extract NgZone, so that ng1 bootstrap can happen in NgZone. This meant that if ng2 bootstrap eagerly compiled a component which contained ng1 components, then we did not have complete metadata.
BREAKING CHANGE: UpgradeAdapter.addProvider are now deprecated in favor of passing in an NgModule into the adapter's constructor
Before:
```
let upgradeAdapter = new UpgradeAdapter();
upgradeAdapter.addProviders([myProvidersArray);
```
After:
```
@NgModule({
providers: myProvidersArray
})
class MyModule {}
let upgradeAdapter = new UpgradeAdapter(MyModule);
```
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.
Note about the addition of `beforeEach(fakeAsync(inject(…))))` in some tests:
`ApplicationRef` is now using `ngOnDestroy` and there is eager,
including all of its dependencies which contain `NgZone`.
The additional `fakeAsync` in `beforeEach` ensures that `NgZone`
uses the fake async zone as parent, and not the root zone.
BREAKING CHANGE (via deprecations):
- `ApplicationRef.dispose` is deprecated. Destroy the module that was
created during bootstrap instead by calling `NgModuleRef.destroy`.
- `AplicationRef.registerDisposeListener` is deprecated.
Use the `ngOnDestroy` lifecycle hook for providers or
`NgModuleRef.onDestroy` instead.
- `disposePlatform` is deprecated. Use `destroyPlatform` instead.
- `PlatformRef.dipose()` is deprecated. Use `PlatformRef.destroy()`
instead.
- `PlatformRef.registerDisposeListener` is deprecated. Use
`PlatformRef.onDestroy` instead.
- `PlaformRef.diposed` is deprecated. Use `PlatformRef.destroyed`
instead.
This makes `bootstrapModuleFactory` wait for promises
returned by `APP_INITIALIZER`s, also making `bootstrapModuleFactory` async.
I.e. now `bootstrapModule` and `bootstrapModuleFactory` behave in the
same way.
This ensures that all code from module instantiation, to creating
`ApplicationRef`s as well as calling `APP_INITIALIZERS` is run
in the Angular zone.
This also moves the invocation of the initializers from the `ApplicationRef`
constructor into the `bootstrapModuleFactory` call, allowing initializers
to get a hold of `ApplicationRef` (see #9101).
Fixes#9101Fixes#10363Fixes#10205
BREAKING CHANGES:
- `browserPlatform`/`browserDynamicPlatform`/... have been deprecated and renamed into `platformBrowser`/`platformBrowserDynamic`/....
- `bootstrapModule` and `bootstrapModuleFactory` have been moved to be members of `PlaformRef`.
E.g. `platformBrowserDynamic().bootstrapModule(MyModule)`.
This contains major changes to the compiler, bootstrap of the platforms
and test environment initialization.
Main part of #10043Closes#10164
BREAKING CHANGE:
- Semantics and name of `@AppModule` (now `@NgModule`) changed quite a bit.
This is actually not breaking as `@AppModules` were not part of rc.4.
We will have detailed docs on `@NgModule` separately.
- `coreLoadAndBootstrap` and `coreBootstrap` can't be used any more (without migration support).
Use `bootstrapModule` / `bootstrapModuleFactory` instead.
- All Components listed in routes have to be part of the `declarations` of an NgModule.
Either directly on the bootstrap module / lazy loaded module, or in an NgModule imported by them.
BREAKING CHANGE (deprecations)
- Instead of `coreBootstrap`, create an `@AppModule` and use `bootstrapModule`.
- Instead of `coreLoadAndBootstarp`, create an `@AppModule` and use `bootstrapModuleFactory`.
- Instead of `bootstrapWorkerApp`, create an `@AppModule` that includes the `WorkerAppModule` and use `bootstrapModule` with the `workerAppPlatform()`.
- Instead of `bootstrapWorkerUi`, create an @AppModule that includes the `WorkerUiModule` and use `bootstrapModule` with the `workerUiPlatform()` instead.
- Instead of `serverBootstrap`, create an @AppModule and use `bootstrapModule` with the `serverDynamicPlatform()` instead.
- Instead of `PLATFORM_PIPES` and `PLATFORM_DIRECTIVES`, provide platform directives/pipes via an `@AppModule`.
- Instead of `ComponentResolver`:
- use `ComponentFactoryResolver` together with `@AppModule.precompile`/`@Component.precompile` or `ANALYZE_FOR_PRECOMPILE` provider for dynamic component creation.
- use `AppModuleFactoryLoader` for lazy loading.
- Instead of `SystemJsComponentResolver`, create an `@AppModule` and use `SystemJsAppModuleLoader`.
- Instead of `SystemJsCmpFactoryResolver`, create an `@AppModule` and use `SystemJsAppModuleFactoryLoader`
Closes#9726
Every test now has an implicit module. It can be configured via `configureModule` (from @angular/core/testing)
to add providers, directives, pipes, ...
The compiler now has to be configured separately via `configureCompiler` (from @angular/core/testing)
to add providers or define whether to use jit.
BREAKING CHANGE:
- Application providers can no longer inject compiler internals (i.e. everything
from `@angular/compiler). Inject `Compiler` instead. This reflects the
changes to `bootstrap` for module support (3f55aa609f).
- Compiler providers can no longer be added via `addProviders` / `withProviders`.
Use the new method `configureCompiler` instead.
- Platform directives / pipes need to be provided via
`configureModule` and can no longer be provided via the
`PLATFORM_PIPES` / `PLATFORM_DIRECTIVES` tokens.
- `setBaseTestProviders()` was renamed into `initTestEnvironment` and
now takes a `PlatformRef` and a factory for a
`Compiler`.
- E.g. for the browser platform:
BEFORE:
```
import {setBaseTestProviders} from ‘@angular/core/testing’;
import {TEST_BROWSER_DYNAMIC_PLATFORM_PROVIDERS,
TEST_BROWSER_DYNAMIC_APPLICATION_PROVIDERS} from ‘@angular/platform-browser-dynamic/testing’;
setBaseTestProviders(TEST_BROWSER_DYNAMIC_PLATFORM_PROVIDERS,
TEST_BROWSER_DYNAMIC_APPLICATION_PROVIDERS);
```
AFTER:
```
import {setBaseTestProviders} from ‘@angular/core/testing’;
import {browserTestCompiler, browserDynamicTestPlatform,
BrowserDynamicTestModule} from ‘@angular/platform-browser-dynamic/testing’;
initTestEnvironment(
browserTestCompiler,
browserDynamicTestPlatform(),
BrowserDynamicTestModule);
```
- E.g. for the server platform:
BEFORE:
```
import {setBaseTestProviders} from ‘@angular/core/testing’;
import {TEST_SERVER_PLATFORM_PROVIDERS,
TEST_SERVER_APPLICATION_PROVIDERS} from ‘@angular/platform-server/testing/server’;
setBaseTestProviders(TEST_SERVER_PLATFORM_PROVIDERS,
TEST_SERVER_APPLICATION_PROVIDERS);
```
AFTER:
```
import {setBaseTestProviders} from ‘@angular/core/testing’;
import {serverTestCompiler, serverTestPlatform,
ServerTestModule} from ‘@angular/platform-browser-dynamic/testing’;
initTestEnvironment(
serverTestCompiler,
serverTestPlatform(),
ServerTestModule);
```
Related to #9726Closes#9846
- ts-api-guardian will now error if a new public symbol is added with a stability marker (`@stable`, `@experimental`, `@deprecated`)
- DomEventsPlugin and KeyEventsPlugin were removed from public api surface - these classes is an implementation detail
- deprecated BROWSER_PROVIDERS was removed completely
- `@angular/compiler` was removed from the ts-api-guardian check since this package shouldn't contain anything that users need to directly import
- the rest of the api surface was conservatively marked as stable or experimental
BREAKING CHANGES: DomEventsPlugin and KeyEventsPlugin previously exported from core are no longer public - these classes are implementation detail.
Previously deprecated BROWSER_PROVIDERS was completely removed from platform-browser.
Closes#9236Closes#9235
Ref #9234
Joao Dias
Georgios Kalpakas
Victor Berchet
Bruno Trigueiro
Alex Eagle
Peter Bacon Darwin
Karl Seamon
Christoph Krautz
Chuck Jazdzewski
Alex Eagle
Austin
Miško Hevery
Igor Minar
Polvista
Tobias Bosch
Rob Wormald
Igor Minar
Jason Choi
Sammy Jelin
ScottSWu