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)
angular-resource: declare required
chai-assert: 'declare' modifier not allowed for code already in an ambient context.
chai: Trailing comma not allowed
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.
