Changelog
1.7.3 eventful-proposal (2018-08-03)
$animate.enabled(element, enabled)
(4bd424,
#16649)cleanData()
if _data()
returns undefined
(7cf4a2,
#16641,
#16642)$flushPendingTasks()
and $verifyNoPendingTasks()
(6f7674,
#14336)timeStripZeroSeconds
and timeSecondsFormat
(b68221,
#10721,
#16510,
#16584)<a name="1.7.2"></a>
Changelog
1.7.2 extreme-compatiplication (2018-06-12)
In the previous release, we removed a private, undocumented API that was no longer used by AngularJS. It turned out that several popular UI libraries (such as AngularJS Material, UI Bootstrap, ngDialog and probably others) relied on that API.
In order to avoid unnecessary pain for developers, this release reverts the removal of the private API and restores compatibility of the aforementioned libraries with the latest AngularJS.
<a name="1.7.1"></a>
Changelog
1.7.1 momentum-defiance (2018-06-08)
$httpBackend
request
(773f39,
#16251,
#11637,
#16560)reloadOnUrl
configuration option
(f4f571,
#7925,
#15002)<a name="1.7.0"></a>
Changelog
1.7.0 nonexistent-physiology (2018-05-11)
Here are the full changes for the release of 1.7.0 that are not already released in the 1.6.x branch, which includes commits from 1.7.0-rc.0 and commits from 1.7.0 directly.
1.7.0 is the last scheduled release of AngularJS that includes breaking changes. 1.7.x patch releases will continue to receive bug fixes and non-breaking features until AngularJS enters Long Term Support mode (LTS) on July 1st 2018.
angular.lowercase
and angular.uppercase
(1daa4f,
#15445)angular.isArray()
(e3ece2,
#15533,
#15541)$sce
service
(1e9ead)null
and undefined
greater than other values
(1d8046,
#15294,
#16376)request
and requestError
interceptors (#15674)
(240a3d,
#5146)xlink:href
security context for SVG's a
and image
elements
(6ccbfa,
#15736)Before this commit removeData()
invoked on an element removed its event
handlers as well. If you want to trigger a full cleanup of an element, change:
elem.removeData();
to:
angular.element.cleanData(elem);
In most cases, though, cleaning up after an element is supposed to be done only when it's removed from the DOM as well; in such cases the following:
elem.remove();
will remove event handlers as well.
The $cookieStore has been removed. Migrate to the $cookies service. Note that
for object values you need to use the putObject
& getObject
methods as
get
/put
will not correctly save/retrieve them.
Before:
$cookieStore.put('name', {key: 'value'});
$cookieStore.get('name'); // {key: 'value'}
$cookieStore.remove('name');
After:
$cookies.putObject('name', {key: 'value'});
$cookies.getObject('name'); // {key: 'value'}
$cookies.remove('name');
If you are not using success
or error
callbacks with $resource
,
your app should not be affected by this change.
If you are using success
or error
callbacks (with or without
response interceptors), one (subtle) difference is that throwing an
error inside the callbacks will not propagate to the returned
$promise
. Therefore, you should try to use the promises whenever
possible. E.g.:
// Avoid
User.query(function onSuccess(users) { throw new Error(); }).
$promise.
catch(function onError() { /* Will not be called. */ });
// Prefer
User.query().
$promise.
then(function onSuccess(users) { throw new Error(); }).
catch(function onError() { /* Will be called. */ });
Finally, if you are using success
or error
callbacks with response
interceptors, the callbacks will now always run after the interceptors
(and wait for them to resolve in case they return a promise).
Previously, the error
callback was called before the responseError
interceptor and the success
callback was synchronously called after
the response
interceptor. E.g.:
var User = $resource('/api/users/:id', {id: '@id'}, {
get: {
method: 'get',
interceptor: {
response: function(response) {
console.log('responseInterceptor-1');
return $timeout(1000).then(function() {
console.log('responseInterceptor-2');
return response.resource;
});
},
responseError: function(response) {
console.log('responseErrorInterceptor-1');
return $timeout(1000).then(function() {
console.log('responseErrorInterceptor-2');
return $q.reject('Ooops!');
});
}
}
}
});
var onSuccess = function(value) { console.log('successCallback', value); };
var onError = function(error) { console.log('errorCallback', error); };
// Assuming the following call is successful...
User.get({id: 1}, onSuccess, onError);
// Old behavior:
// responseInterceptor-1
// successCallback, {/* Promise object */}
// responseInterceptor-2
// New behavior:
// responseInterceptor-1
// responseInterceptor-2
// successCallback, {/* User object */}
// Assuming the following call returns an error...
User.get({id: 2}, onSuccess, onError);
// Old behavior:
// errorCallback, {/* Response object */}
// responseErrorInterceptor-1
// responseErrorInterceptor-2
// New behavior:
// responseErrorInterceptor-1
// responseErrorInterceptor-2
// errorCallback, Ooops!
request
and requestError
interceptors (#15674)Previously, calling a $resource
method would synchronously call
$http
. Now, it will be called asynchronously (regardless if a
request
/requestError
interceptor has been defined.
This is not expected to affect applications at runtime, since the
overall operation is asynchronous already, but may affect assertions in
tests. For example, if you want to assert that $http
has been called
with specific arguments as a result of a $resource
call, you now need
to run a $digest
first, to ensure the (possibly empty) request
interceptor promise has been resolved.
Before:
it('...', function() {
$httpBackend.expectGET('/api/things').respond(...);
var Things = $resource('/api/things');
Things.query();
expect($http).toHaveBeenCalledWith(...);
});
After:
it('...', function() {
$httpBackend.expectGET('/api/things').respond(...);
var Things = $resource('/api/things');
Things.query();
$rootScope.$digest();
expect($http).toHaveBeenCalledWith(...);
});
Previously the tpload
error was namespaced to $compile
. If you have
code that matches errors of the form [$compile:tpload]
it will no
longer run. You should change the code to match
[$templateRequest:tpload]
.
The service now returns the result of $templateCache.put()
when making a server request to the
template. Previously it would return the content of the response directly.
This now means if you are decorating $templateCache.put()
to manipulate the template, you will
now get this manipulated result also on the first $templateRequest
rather than only on subsequent
calls (when the template is retrived from the cache).
In practice this should not affect any apps, as it is unlikely that they rely on the template being
different in the first and subsequent calls.
$animate.cancel(runner) now rejects the underlying promise and calls the catch() handler on the runner returned by $animate functions (enter, leave, move, addClass, removeClass, setClass, animate). Previously it would resolve the promise as if the animation had ended successfully.
Example:
var runner = $animate.addClass('red');
runner.then(function() { console.log('success')});
runner.catch(function() { console.log('cancelled')});
runner.cancel();
Pre-1.7.0, this logs 'success', 1.7.0 and later it logs 'cancelled'. To migrate, add a catch() handler to your animation runners.
Changelog
1.7.0-rc.0 maximum-overdrive (2018-04-19)
angular.lowercase
and angular.uppercase
(1daa4f,
#15445)angular.isArray()
(e3ece2,
#15533,
#15541)$sce
service
(1e9ead)null
and undefined
greater than other values
(1d8046,
#15294,
#16376)request
and requestError
interceptors (#15674)
(240a3d,
#5146)xlink:href
security context for SVG's a
and image
elements
(6ccbfa,
#15736)Before this commit removeData()
invoked on an element removed its event
handlers as well. If you want to trigger a full cleanup of an element, change:
elem.removeData();
to:
angular.element.cleanData(elem);
In most cases, though, cleaning up after an element is supposed to be done only when it's removed from the DOM as well; in such cases the following:
elem.remove();
will remove event handlers as well.
The $cookieStore has been removed. Migrate to the $cookies service. Note that
for object values you need to use the putObject
& getObject
methods as
get
/put
will not correctly save/retrieve them.
Before:
$cookieStore.put('name', {key: 'value'});
$cookieStore.get('name'); // {key: 'value'}
$cookieStore.remove('name');
After:
$cookies.putObject('name', {key: 'value'});
$cookies.getObject('name'); // {key: 'value'}
$cookies.remove('name');
If you are not using success
or error
callbacks with $resource
,
your app should not be affected by this change.
If you are using success
or error
callbacks (with or without
response interceptors), one (subtle) difference is that throwing an
error inside the callbacks will not propagate to the returned
$promise
. Therefore, you should try to use the promises whenever
possible. E.g.:
// Avoid
User.query(function onSuccess(users) { throw new Error(); }).
$promise.
catch(function onError() { /* Will not be called. */ });
// Prefer
User.query().
$promise.
then(function onSuccess(users) { throw new Error(); }).
catch(function onError() { /* Will be called. */ });
Finally, if you are using success
or error
callbacks with response
interceptors, the callbacks will now always run after the interceptors
(and wait for them to resolve in case they return a promise).
Previously, the error
callback was called before the responseError
interceptor and the success
callback was synchronously called after
the response
interceptor. E.g.:
var User = $resource('/api/users/:id', {id: '@id'}, {
get: {
method: 'get',
interceptor: {
response: function(response) {
console.log('responseInterceptor-1');
return $timeout(1000).then(function() {
console.log('responseInterceptor-2');
return response.resource;
});
},
responseError: function(response) {
console.log('responseErrorInterceptor-1');
return $timeout(1000).then(function() {
console.log('responseErrorInterceptor-2');
return $q.reject('Ooops!');
});
}
}
}
});
var onSuccess = function(value) { console.log('successCallback', value); };
var onError = function(error) { console.log('errorCallback', error); };
// Assuming the following call is successful...
User.get({id: 1}, onSuccess, onError);
// Old behavior:
// responseInterceptor-1
// successCallback, {/* Promise object */}
// responseInterceptor-2
// New behavior:
// responseInterceptor-1
// responseInterceptor-2
// successCallback, {/* User object */}
// Assuming the following call returns an error...
User.get({id: 2}, onSuccess, onError);
// Old behavior:
// errorCallback, {/* Response object */}
// responseErrorInterceptor-1
// responseErrorInterceptor-2
// New behavior:
// responseErrorInterceptor-1
// responseErrorInterceptor-2
// errorCallback, Ooops!
request
and requestError
interceptors (#15674)Previously, calling a $resource
method would synchronously call
$http
. Now, it will be called asynchronously (regardless if a
request
/requestError
interceptor has been defined.
This is not expected to affect applications at runtime, since the
overall operation is asynchronous already, but may affect assertions in
tests. For example, if you want to assert that $http
has been called
with specific arguments as a result of a $resource
call, you now need
to run a $digest
first, to ensure the (possibly empty) request
interceptor promise has been resolved.
Before:
it('...', function() {
$httpBackend.expectGET('/api/things').respond(...);
var Things = $resource('/api/things');
Things.query();
expect($http).toHaveBeenCalledWith(...);
});
After:
it('...', function() {
$httpBackend.expectGET('/api/things').respond(...);
var Things = $resource('/api/things');
Things.query();
$rootScope.$digest();
expect($http).toHaveBeenCalledWith(...);
});
Previously the tpload
error was namespaced to $compile
. If you have
code that matches errors of the form [$compile:tpload]
it will no
longer run. You should change the code to match
[$templateRequest:tpload]
.
The service now returns the result of $templateCache.put()
when making a server request to the
template. Previously it would return the content of the response directly.
This now means if you are decorating $templateCache.put()
to manipulate the template, you will
now get this manipulated result also on the first $templateRequest
rather than only on subsequent
calls (when the template is retrived from the cache).
In practice this should not affect any apps, as it is unlikely that they rely on the template being
different in the first and subsequent calls.
$animate.cancel(runner) now rejects the underlying promise and calls the catch() handler on the runner returned by $animate functions (enter, leave, move, addClass, removeClass, setClass, animate). Previously it would resolve the promise as if the animation had ended successfully.
Example:
var runner = $animate.addClass('red');
runner.then(function() { console.log('success')});
runner.catch(function() { console.log('cancelled')});
runner.cancel();
Pre-1.7.0, this logs 'success', 1.7.0 and later it logs 'cancelled'. To migrate, add a catch() handler to your animation runners.
Changelog
1.6.10 crystalline-persuasion (2018-04-17)
<a name="1.6.9"></a>
Changelog
1.6.9 fiery-basilisk (2018-02-02)
drop
event support for IE
(5dc076)xml:base
attributes
(b9ef65)<a name="1.6.8"></a>
Changelog
1.6.7 imperial-backstroke (2017-11-24)
$httpBackend
to the error handler
(1555a4,
#16150,
#15855)<a name="1.6.6"></a>
Changelog
1.6.6 interdimensional-cable (2017-08-18)
$cancelRequest()
(009ebe,
#16037)Content-Type
is not application/json
but response is JSON-like
(2e1163,
#16027,
#16075)strictComponentBindingsEnabled()
method
(3ec181,
#16129)<a name="1.6.5"></a>