As scopes are injected into controllers now, you have the reference anyway, so having scope as first argument makes no sense…
Breaks $watcher gets arguments in different order (newValue, oldValue, scope)
Controller is standalone object, created using "new" operator, not messed up with scope anymore.
Instead, related scope is injected as $scope.
See design proposal: https://docs.google.com/document/pub?id=1SsgVj17ec6tnZEX3ugsvg0rVVR11wTso5Md-RdEmC0kCloses#321Closes#425
Breaks controller methods are not exported to scope automatically
Breaks Scope#$new() does not take controller as argument anymore
Chrome (probably other browsers as well) fires 'hashchange' event synchronously, so if you change raw location from within $apply/$digest, we don't want to $apply twice. (It would throw an exception)
- there are too many unknowns about PATCH, so I'm dropping its support until we know that this is actually useful
- expectGET, expectHEAD and expectJSON (and the same for whenXXX) should not require response data to be specified
Now, that we have autoscroll attribute on ng:include, there is no reason to disable the service completely, so $anchorScrollProvider.disableAutoScrolling() means it won't be scrolling when $location.hash() changes.
And then, it's not $autoScroll at all, it actually scrolls to anchor when it's called, so I renamed
it to $anchorScroll.
$http:
- use promises internally
- get rid of XhrFuture that was previously used internally
- get rid of $browser.defer calls for async stuff (serving from cache),
promises will take care of asynchronicity
- fix transformation bugs (when caching requested + multiple request
pending + error is returned)
- get rid of native header parsing and instead just lazily parse the
header string
$httpBackend:
- don't return raw/mock XMLHttpRequest object (we don't use it for
anything anymore)
- call the callback with response headers string
mock $httpBackend:
- unify response api for expect and when
- call the callback with response headers string
- changed the expect/when failure error message so that EXPECTED and GOT
values are aligned
Conflicts:
src/service/http.js
test/service/compilerSpec.js
test/service/httpSpec.js
Previously we used to put callbacks on the window object, but that
causes problems on IE8 where it is not possible to delete properties
from the window object
Parser now builds expressions that can detect promises and transparently
evaluate them to undefined or the promise value.
If promiseA is resolved with value 'A', then {{promiseA}} evals to 'A';
If promiseA is unresolved, then {{promiseA}} evals to undefined;
Following invocations are supported:
- {{promise}}
- {{promise.futureProp}}
- {{[promise][0]}}
- {{object.promise}}
- {{object[promise]}}
- {{array[promise]}}
- {{fn(promise)}}
- combinations of the above
If jsonp is not successfull, we return internal status -2.
This internal status should by normalized by $xhr into 0,
but $xhr needs to distinguish between jsonp-error/abort/timeout (all status 0).
- since NaN !== NaN in javascript digest can get into an infinite loop
when model value is set to NaN
- angular.equals(NaN, NaN) should return true since that's what we
expect when comparing primitives or objects containing NaN values
Previously NaN because of its special === properties was used as the
initial value for watches, but that results in issues when NaN is used
as model value.
In order to allow for model to be anything incuding undefined and NaN we
need to mark the initial value differently in a way that would avoid
these issues, allow us to run digest without major perf penalties and
allow for clients to determine if the listener is being called because
the watcher is being initialized or because the model changed. This
implementation covers all of these scenarios.
BREAKING CHANGE: previously to detect if the listener was called because
the watcher was being initialized, it was suggested that clients check
if old value is NaN. With this change, the check should be if the newVal
equals the oldVal.
Closes#657
