ngRepeat iterates over object in alphabetical order #6210
Comments
|
There was a lot of discussion about it in #1286 |
|
@cztomsik, major browsers don't all keep the order of keys added to objects in the same way... So there is actually some issues there. I agree it would be preferable if the orderBy filter supported object collections as well as arrays, though. I've set this as PRs plz!, because I believe it should be desirable to fix the In the mean time, you could get around this by simply using arrays instead of objects, IMO. |
Allows to use orderBy filter on collection objects and not only arrays.
eg:
var c = {
b: {name: 'b'},
c: {name: 'c'},
a: {name: 'a'}
};
orderBy(c, 'name'); // => [{name: 'a'}, {name: 'b'}, {name: 'c'}];
Closes: angular#6210
Allows to use orderBy filter on collection objects and not only arrays.
eg:
var c = {
b: {name: 'b'},
c: {name: 'c'},
a: {name: 'a'}
};
orderBy(c, 'name'); // => [{name: 'a'}, {name: 'b'}, {name: 'c'}];
Closes: angular#6210
Allows to use orderBy filter on collection objects and not only arrays. Closes: angular#6210
|
+1 |
5 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 ! |
|
+1 |
5 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
It is very easy to fix this with an Here is a hard-coded solution to an Here is a version that uses @finalclass's toArray filter (remembering that this will not work on IE8): http://jsfiddle.net/z8ME5/ Here is a version that uses toArray but actually modifies the original object (and will work on IE8): I don't expect this to be added to the core but maybe there is enough desire... |
|
I have been thinking about this some more tonight - instead of going to sleep, which is what I ought to be doing! First of all, I think @caitp is right that we cannot guarantee to solve what appears to be the main use case, which is to get the DOM elements in the same order in which the properties are defined on the object collection. It appears that most browsers currently do indeed leave this property ordering alone but it is not guaranteed not to change at any point without notice. That being said I think we can do more here... A big problem we have at the moment with object collections is that we really want to do the sorting and filtering inside the repeat logic. Filters such as I have an idea for 1.4. How about we split ng-repeat into two directives:
This would have a number of benefits.
Any thoughts on this? |
|
we've been using objects as ordered collections for years so the behaviour is hardly going to change, also any other library iterates objects in enumeration order ($.each, _.each) so why is angular doing it its own way??? |
|
I don't see why browsers would, all of a sudden, decide to scramble the order of items in an object. Nobody expects it to be re-ordered alphabetically and I know people are having trouble with this, thinking there's a bug somewhere when they see 2 coming after 10. It's hard to figure it out the first time, because no one expects it, and it's a pain to have to work around it. I would rather risk Chrome (or others) scramble the order than have forced ordering, mostly because I highly doubt such a thing would last more than 1 day before being patched. I'm all for making alphabetical re-ordering optional and disabled by default. I don't think heavier changes are required at the moment. |
|
@kesarion to Angular teams' credit, it is true and a known fact that some browsers / versions of browsers do not respect object property order. The intentions were good I think, in trying to create a consistent behavior across all browsers, but in practice it's a bit overreaching |
|
there are some interoperable features of property enumeration which are never going to change (the usual "don't break the web" stuff, despite not being spec'd), there are other elements of property enumeration which are not interoperable, and which can change --- those non-interoperable elements are why we say that we can't provide any guarantees about ordering --- you think it's guaranteed, but it's really not. It's one of those really stupid things about javascript =) But the point I'm getting at is really, it doesn't make any difference whether the keys are alphabetically sorted or not --- you shouldn't be enumerating object keys in ngRepeat anyways, because it doesn't really make sense to do it that way (you lose all control, you get varying results in different engines, depending on the keys you use and the things you do with them). People want the change and they can have it, but honestly it's not really helping you do anything, and it's a really weird thing to depend on. |
|
We are going to stop automatically sorting properties in I think that this thread is no longer providing anything valuable to the discussion. Let's focus on the implementation and make sure that we have captured all the possible use cases for iterating over an object collection inside that PR. |
|
i really don't care either way on this though I'm more with the +1's but just put it in the documentation! I shouldn't have spent 2 hours today trying to sift through why my objects are out of order, finding that it wasn't the json serializer on my server, it wasn't expressjs, it wasn't mongoose, it wasn't the browser, it wasn't angular ui-router but it was the core of angular! I like things that don't break but I like building things fast even more and fixing them when they break if and when my project has the budget for it. |
|
+1 for documenting this in 1.3.10 |
|
+1, undocumented "features" that aren't intuitive. |
|
Thanks I see that now. Just the same though, looks like it was out for a while before it was documented (1.3 released in October, this doc change dated 25 days ago) and it isn't very intuitive. It cost me a lot of time as I was doing server side sorts and finally tried a hail mary of returning an array, as it violates FIFO. I'm glad it's being removed for 1.4 due out in march. The only reason I mentioned the lack of documentation and intuitiveness is simply to express the dissatisfaction such causes as to hopefully curtail such in the future. Thanks! |
|
Actually, I this sorting of keys was the behaviour since before Angular 1.0.0! |
|
A very unexpected behaviour :-) |
|
@cztomsik I am using 1.3.11 and it is sorting the keys alphabetically. Let me try 1.4 now 👍 |
|
+1 |
|
What are the +1s for? This is fixed in master. It would be a breaking change for 1.3 so it will not be fixed there. |
|
Maybe people want to see this in 1.5.. Community decides what goes into 1.5 and it looks like they are speaking with +1s??? |
|
@niemyjski this is part of 1.4 so I'm not sure what is the story with 1.5 and votes.... In other words: this is already fixed in master and part of 1.4 releases.... |
|
odd, I thought I just came across this issue a few hours ago and thus when looking and +1'ed... Maybe it was just an issue with track by that made me think this was happening... |
|
yep, just noticed that an object i created for a dropdown was being rendered, unexpectedly and quite undesirably, in alphabetical rather than in as-is object order. |
|
+1 |
|
I'm going to lock this issue, because this is fixed. To recap: Starting with 1.4, the keys are not sorted alphabetically anymore. This is documented as a breaking change here: https://github.com/angular/angular.js/blob/master/CHANGELOG.md#breaking-changes-6 Any behavior that might look like the keys are still sorted alphabetically is possibly a different bug (for which you can open a new issue), or a usage error. In 1.3.x and before, the keys are still sorted alphabetically, as changing it in these versions would be major breaking change. The docs outline how to work around this problem: https://code.angularjs.org/1.3.16/docs/api/ng/directive/ngRepeat |
and others
This is very unexpected, all major browsers retain order of inserted keys and it is not going to change in any way in future as it would break a lot of existing code.
No matter of that, angular does it its own "way".
Basically it makes this feature completely useless as you can't use it for example for iterating computed averages, and similar great things.
This is major flaw in design and fixing it involves removing one line:
Can we at least discuss this? I am highly convinced this (possibly) breaking change should affect minimum people and if orderBy worked on objects too, fixing may be very simple on their side.
The text was updated successfully, but these errors were encountered: