Looks like defining only a single overload of the then function on the
IHttpPromise interface is making the other overload of it defined on
IPromise invisible to the compiler. As such, we need to expose both
versions. Otherwise, the standard promise unwrapping behaviour does not
type check correctly.
success/error should retain the promise type
also, the callback return should be void, any return value doesn't seem to be carried anywhere: http://jsfiddle.net/9syMH/
I know you haven't used generics so far so I hope this is a welcome
change - the only nuisance is that it will "break" current compilation
but will increase type safety by far.
Also added params to ICurrentRoute and inline injection notation to
$provide.decorator as per
https://github.com/borisyankov/DefinitelyTyped/issues/799
Adjusted templateUrl of IRoute because $routeProvider now allows function templateUrls to be defined such as;
.when("/:controller/:action", {
templateUrl: function ($routeParams) {
console.log("Default rule");
return '/ng/app/views/partials/' + $routeParams.action.toLowerCase() + '.htm';
}
})
- add IHttpPromiseCallback for both `error` and `success` promise calls
use case is if we're passing around the callback, we don't want to be
repeating that entire function declaration every time, and we cannot use
`Function` as that doesn't satisfy the compiler. (see test case)
See http://docs.angularjs.org/guide/directive: `scope` can be either `true`, or object hash which defines a set of local scope properties derived from the parent scope.
The type definition for ng.IPromise.then was, in my opinion, incorrect
semantically, and breaking on practical examples in my codebase.
An `IPromise`' `then` function takes a callback which is called with the
value of the promise once it's fulfilled. This could be a number, a
string, some object, an array of strings, anything really. Yet the
typing in angular.d.ts specified `then` as taking a `successCallback` of
type `(response: PromiseCallbackArg) => any`.
The definition of `PromiseCallbackArg` seems very permissive at first
glance, as it is defined to be an object with a bunch of fields, all
optional. Any object, a number, and a string all type check correctly
with such a type, but an array of strings, for example, does not
(`cPromise` in the provided list of test).
Furthermore, it seems to me that the `PromiseCallbackArg` definition was
added specifically to support the response type for promises returned by
the Angular `$http` service, the `ng.IHttpPromise`.
So instead of having an incorrect type on the `ng.IPromise.then` function,
I propose we return it to its generic form, and instead override the
type of the inherited `then` function in the `ng.IHttpPromise` interface.
This would also warrant renaming `PromiseCallbackArg` to
`IHttpPromiseCallbackArg`.
angularjs: docs around first page tutorials
jquery: fix for known lib.d.ts big
knockback: add typing for observable based on tutorial, add docs around
observable.
