angular-scenario
Advanced tools
Changelog
1.4.0-beta.2 holographic-rooster (2015-01-26)
Closes #9992 Closes #10352
<a name="1.3.11"></a>
Changelog
1.4.0-beta.1 trepidatious-salamander (2015-01-20)
Previously, the order of items when using ngRepeat to iterate over object properties was guaranteed to be consistent by sorting the keys into alphabetic order.
Now, the order of the items is browser dependent based on the order returned
from iterating over the object using the for key in obj
syntax.
It seems that browsers generally follow the strategy of providing keys in the order in which they were defined, although there are exceptions when keys are deleted and reinstated. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete#Cross-browser_issues
The best approach is to convert Objects into Arrays by a filter such as https://github.com/petebacondarwin/angular-toArrayFilter or some other mechanism, and then sort them manually in the order you need.
Closes #6210 Closes #10538
<a name="1.3.10"></a>
Changelog
1.3.10 heliotropic-sundial (2015-01-20)
<a name="1.4.0-beta.0"></a>
Changelog
1.4.0-beta.0 photonic-umbrakinesis (2015-01-13)
fn
to be an optional parameter
(5a603023,
#9176)limitTo: due to a3c3bf33, limitTo changed behavior when limit value is invalid. Instead of returning empty object/array it returns unchanged input.
ngOptions: due to 7fda214c,
When using ngOptions
: the directive applies a surrogate key as the value of the <option>
element.
This commit changes the actual string used as the surrogate key. We now store a string that is computed
by calling hashKey
on the item in the options collection; previously it was the index or key of the
item in the collection.
(This is in keeping with the way that the unknown option value is represented in the select directive.)
Before you might have seen:
<select ng-model="x" ng-option="i in items">
<option value="1">a</option>
<option value="2">b</option>
<option value="3">c</option>
<option value="4">d</option>
</select>
Now it will be something like:
<select ng-model="x" ng-option="i in items">
<option value="string:a">a</option>
<option value="string:b">b</option>
<option value="string:c">c</option>
<option value="string:d">d</option>
</select>
If your application code relied on this value, which it shouldn't, then you will need to modify your
application to accommodate this. You may find that you can use the track by
feature of ngOptions
as this provides the ability to specify the key that is stored.
When iterating over an object's properties using the (key, value) in obj
syntax
the order of the elements used to be sorted alphabetically. This was an artificial
attempt to create a deterministic ordering since browsers don't guarantee the order.
But in practice this is not what people want and so this change iterates over properties
in the order they are returned by Object.keys(obj), which is almost always the order
in which the properties were defined.
setting the ngOptions attribute expression after the element is compiled, will no longer trigger the ngOptions behavior. This worked previously because the ngOptions logic was part of the select directive, while it is now implemented in the ngOptions directive itself.
the select
directive will now use strict comparison of the ngModel
scope value against option
values to determine which option is selected. This means Number
scope values will not be matched
against numeric option strings.
In AngularJS 1.3.x, setting scope.x = 200
would select the option
with the value 200 in the following select
:
<select ng-model="x">
<option value="100">100</option>
<option value="200">200</option>
</select>
In AngularJS 1.4.x, the 'unknown option' will be selected.
To remedy this, you can simply initialize the model as a string: scope.x = '200'
, or if you want to
keep the model as a Number
, you can do the conversion via $formatters
and $parsers
on ngModel
:
ngModelCtrl.$parsers.push(function(value) {
return parseInt(value, 10); // Convert option value to number
});
ngModelCtrl.$formatters.push(function(value) {
return value.toString(); // Convert scope value to string
});
<a name="1.3.9"></a>
Changelog
1.3.8 prophetic-narwhal (2014-12-19)
ng-click
via keypress, pass $event
to expression
(924e68c7,
#10442, #10443, #10447)<a name="1.3.7"></a>
Changelog
1.3.7 leaky-obstruction (2014-12-15)
createMap()
for $$observe
listeners when initialized from attr interpolation
(8e28bb4c)getterFn
(c90ad968)(key,value)
part of micro-syntax
(ef640cbc,
#6827, #6833)valueOf
/toString
on null
(a097aa95,
#10385, #10386)ng-attr
with camelCased attributes
(d8e37078,
#9845, #10194)locals
argument to $evalAsync
(9b96cea4,
#10390)$interpolate
attribute values at link time if changed since compile
(9ae0c01c)Previously, if either value being compared in the orderBy comparator was null or undefined, the
order would, incorrectly, not change. Now, this order behaves more like Array.prototype.sort, which
by default pushes null
behind objects, due to n
occurring after [
(the first characters of their
stringified forms) in ASCII / Unicode. If toString
is customized, or does not exist, the
behavior is undefined.
<a name="1.2.28"></a>
Changelog
1.3.6 robofunky-danceblaster (2014-12-08)
We no longer throw an ihshprfx
error if the URL after the base path
contains only a hash fragment. Previously, if the base URL was http://abc.com/base/
and the hashPrefix is !
then trying to parse http://abc.com/base/#some-fragment
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting $location.absUrl() === "http://abc.com/base/#!/#some-fragment"
.
This should not break any applications, but you can no longer rely on receiving the
ihshprfx
error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway: If the base URL
and hashPrfix are set up as above, then http://abc.com/base/other/path
does not
throw an error but just ignores the extra path: http://abc.com/base
.
filterFilter: due to a75537d4,
Named properties in the expression object will only match against properties on the same level. Previously, named string properties would match against properties on the same level or deeper.
Before:
arr = filterFilter([{level1: {level2: 'test'}}], {level1: 'test'}); // arr.length -> 1
After:
arr = filterFilter([{level1: {level2: 'test'}}], {level1: 'test'}); // arr.length -> 0
In order to match deeper nested properties, you have to either match the depth level of the
property or use the special $
key (which still matches properties on the same level
or deeper). E.g.:
// Both examples below have `arr.length === 1`
arr = filterFilter([{level1: {level2: 'test'}}], {level1: {level2: 'test'}});
arr = filterFilter([{level1: {level2: 'test'}}], {$: 'test'});
<a name="1.3.5"></a>