- 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
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;
* fix(ngRouteShim): update anchors to function similar to angular 1.x when setting the target
* fix(ngRouteShim): update anchor target check to use indexOf instead of contains on array
Make sure the same path is not added multiple times to the history.
It is replacing the state, instead of skipping it completely,
because the current path in the browser might not be normalized,
while the given one is normalized.
Closes#7829Closes#7897
If the $routerOnActivate hook returns a promise, the navigation
is commited, once the promise gets fullfilled but the view
is updated immediately.
This commit delays the view update so that both (view and url) are
updated at the same time.
Closes#7777
At the moment ng-link is generating html5mode URLs for `href`s.
Instead it should check whether or not html5mode is enabled and create
the `href`s accordingly. The renaming in the `getLink` function is
aligning it to `RouterLink`'s `_updateLink`.
Closes#7423
Until Angular 1.5.1 is released, the `$routeConfig` and `$routerCanActivate`
annotations for components must live on the controller constructor.
In Angular 1.5.1, it will automatically copy these annotations across from
the component definition file.
Closes#7319
These tests were registering new components after the application had
been bootstrapped, which is not a valid use case for synchronous routes
in Angular 1.
In particular it was registering the "root" component, which caused the
`$rootRouter` to blow up, when it was instantiated, pointing to a root
component that did not yet exist.
The directiveIntrospector was a bit of a hack to allow the router to
read the `$routeConfig` annocation and `$routerCanActivate` hook from
directives when they were registered.
It turns out that if we put these properties on the component controller's
constructor function (i.e. as static class methods) then we can simply
use the `$injector` to access it as required.
Currently, people put the properties directly on their component definition
objects. In Angular 1.5.1, we will copy these properties onto the controller
constructor to maintain a simple migration path. But going forward it may be
better to encourage people to add the properties directly to the controller
constructor.
@petebacondarwin deserves credit for most of this commit.
This allows you to specify a regex and serializer function instead
of the path DSL in your route declaration.
```
@RouteConfig([
{ regex: '[a-z]+.[0-9]+',
serializer: (params) => `{params.a}.params.b}`,
component: MyComponent }
])
class Component {}
```
Closes#7325Closes#7126
The current router is passed to the current component via a binding.
To indicate that this is an angular provided object, this commit
renames the binding to `$router`.
BREAKING CHANGE:
The recently added binding of the current router to the current component
has been renamed from `router` to `$router`.
So now the recommended set up for your bindings in your routed component
is:
```js
{
...
bindings: {
$router: '<'
}
}
```
The current router is passed to the current component via a binding.
To indicate that this is an angular provided object, this commit
renames the binding to `$router`.
BREAKING CHANGE:
The recently added binding of the current router to the current component
has been renamed from `router` to `$router`.
So now the recommended set up for your bindings in your routed component
is:
```js
{
...
bindings: {
$router: '<'
}
}
```
The singleton service that represents the top level router was called
`$router` but this is confusing since there are actually lots of routers,
which depend upon where you are in the DOM. This is similar to the situation
with scopes.
This commit clarifies this singleton by renaming it to `$rootRouter`.
BREAKING CHANGE:
The `$router` injectable service has been renamed to `$rootRouter`
The current router is passed to the current component via a binding.
To indicate that this is an angular provided object, this commit
renames the binding to `$router`.
BREAKING CHANGE:
The recently added binding of the current router to the current component
has been renamed from `router` to `$router`.
So now the recommended set up for your bindings in your routed component
is:
```js
{
...
bindings: {
$router: '<'
}
}
```
In angular2 `Location.path()` returns the complete path including query string. In angular1 the query parameters are missing. Similar to this `Location.go` does accept two parameters (path *and query*).
Closes#6943
In Angular 1.5 there is a new helper method for creating component directives.
See https://docs.angularjs.org/guide/component for more information about components.
These kind of directives only match the `E` element form and the previously component
router only created HTML that matched directives that matched the `A` attribute form.
This commit changes the `<ng-outlet>` directive so that it generates custom HTML
elements rather divs with custom attributes to trigger the relevant component to
appear in the DOM.
Going forward, Angular 1.5 users are encouraged to create their router components
using the following style:
```
myModule.componnet('component-name', {
// component definition object
});
```
Closes angular/angular.js#13860
Closes#6076Closes#5278
BREAKING CHANGE:
The component router now creates custom element HTML rather than custom attribute
HTML, in order to create a new component. So rather than
```html
<div custom-component></div>
```
it now creates
```html
<custom-component></custom-component>
```
If you defined you router components using the `directive()` helper and
specified the `restrict` properties such that element matching was not allowed,
e.g. `restrict: 'A'` then these components will no longer be instantiated
by the component router and the outlet will be empty.
The fix is to include `E` in the `restrict` property.
`restrict: 'EA'`
Note that this does not affect directives that did not specify the `restrict`
property as the default for this property is already `EA`.
The upstream Jasmine typings don't define a type for the global
object with Jasmine methods polluting it, so just use any.
Also zone.js has a different name upstream.
Miško Hevery
Joao Dias
Victor Berchet
Alex Eagle
Chuck Jazdzewski
Marc Laval
Jon
Igor Minar
Vamsi Varikuti
Rene Weber
David Reher
Fabian Raetz
Brandon Roberts
Alex Rickabaugh
Alex Eagle
Peter Bacon Darwin
David Reher
Brian Ford
Fahimnur Alam
Alexander Bachmann