[filter] allow object maps along with arrays

[hsdk123]

The current implementation of filter only allows arrays. It would be nice if we could also use filter with object maps. (some 3rd party plugins return object maps instead of arrays)

I'm having to convert all the object maps I receive to arrays each time just so that I can get the filtering to work.

example found:
http://stackoverflow.com/questions/13887504/filtering-on-object-map-rather-than-array-in-angularjs

[xixixao]

+1

[angadsalaria]

+1
AngularJS support for maps would be of immense help. This can go beyond the filtering needs. Maps allow very quick and easy access to individual elements. For the purpose of 2 way data binding, updating the model/view can become extremely easy if maps are utilized instead of arrays.

[stevebhyve]

+1
this seems wrong. I feel dirty.

$scope.objectToArray = function(item) {
var arr = [];
for(var key in item) {
arr.push(item[key]);
}
return arr;
}

[yaru22]

+1
any update on this? Rather than storing data in an array, if we can store it in an object with key being id of the data, it will make manipulating them so much easier.

[hsdk123]

+1 Also wondering if this has gone through any progress.

[wwchen]

+1

[quentinburley]

+1

[slid1amo2n3e4]

+1

[gkalpak]

This seems like (sort of) a duplicate of #8458.
(This is older, but I suggest continuing conversation in #8458, since it also references orderBy and has more relevant comments.)

[pkozlowski-opensource]

Given that cea8e75 landed, I don't think it is going to happen. Closing as "won't fix".

[hsdk123]

@pkozlowski-opensource I think this is a very hasty closing - and I think the other commit should be revised as well. I originally opened this issue because it would be 'immensely useful' if object maps were also allowed in parallel to arrays, not because angular didn't give an error if I tried.

I'm sure the +1s in this thread were also made for also the same practical advantage that this feature would give, and not for the lack of error output.

I still strongly feel that this feature should be added in the angluar core, and hence this thread reopened. It is disappointing that this has been given such a lack of interest considering almost 2 years has past since the original post.

[pkozlowski-opensource]

@caitp @gkalpak @petebacondarwin what is the final team's decision on this issue? I figured it was "won't fix" since cea8e75 landed.

I guess we should decide once and for all if we want to include this in the core and then either:

• close all the related issues / PRs (ex.: feat(filter): allow filtering of an object #5451), or
• implement it "properly" (and close all the issues / PRs :-))

I'm not sure we should include it in core. Personally I didn't bump into the scenario where this would be need for an elegant solution, but it seems like some people feel strongly about this one.

[caitp]

it doesn't work well with objects since it is converted to an array, and information is lost. the only way it could conceivably work without losing information, is if each key/value pair were wrapped in an object themselves. This makes everything rather clunky, and is not ideal. Plus, the use cases for actually using an object rather than an array are rather limited. everything from animations to filtering loses some important details of quality when used with an unordered set, and not all of these are fixable in a manner we'd like to ship. so it's unfortunate, but I don't think this is something worth fixing

[petebacondarwin]

I agree
On 24 Jan 2015 17:39, "⭐caitp⭐" notifications@github.com wrote:

it doesn't work well with objects since it is converted to an array, and
information is lost. the only way it could conceivably work without losing
information, is if each key/value pair were wrapped in an object
themselves. This makes everything rather clunky, and is not ideal. Plus,
the use cases for actually using an object rather than an array are rather
limited. everything from animations to filtering loses some important
details of quality when used with an unordered set, and not all of these
are fixable in a manner we'd like to ship. so it's unfortunate, but I don't
think this is something worth fixing

—
Reply to this email directly or view it on GitHub
#2694 (comment).