Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

fix(filterFilter): correctly handle deep expression objects #9757

Closed
wants to merge 4 commits into from

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Oct 23, 2014

Previously, trying to use a deep expression object (i.e. an object whose properties can be objects themselves) did not work correctly. This commit refactors filterFilter, making it simpler and adding support for filtering collections of arbitrarily deep objects.

Closes #9698


BTW, I used "non-IE8" stuff (like `Array.prototype.some/every`) for the sake of conciseness and clarity, so this is not directly back-portable to 1.2.x. If there is interest, I can create a IE8 compatible version (using `for-loops` etc).

@gkalpak
Copy link
Member Author

gkalpak commented Oct 23, 2014

Some considerations:

  1. Should we mention in the docs that deep objects can be also filtered (or is it redundant) ?
  2. Should there be inline comments at certain parts explaining that whats and the whys (or is it clear enough).
  3. None of the previous test-cases broke. Yet, since the filter was heavily refactored, one can't be really sure that all corner-cases are handled the same as before.
    (The documented stuff does seem to still work as expected, so this shouldn't introduce a breaking change (in the "formal" sense).)

@gkalpak gkalpak force-pushed the filterFilter-deep-expr-obj branch 3 times, most recently from 3b040cd to b72583f Compare October 23, 2014 12:20
@Narretz
Copy link
Contributor

Narretz commented Oct 23, 2014

Great work!
So the fix is for with deep expression objects with multiple properties and the feat is that these objects can be nested arbitrarily deep?

I don't want to piggyback on the PR or anything, but can you check if this PR can be incorporated in your fix? It seems like a good fit. #6623

We could also check other filter issues for possible tests to add.

@@ -79,7 +78,6 @@ describe('Filter: filter', function() {
expect(filter(items, {'first.name':'misko', 'last.name':''})).toEqual([items[0]]);
});


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stop removing these =)

@caitp
Copy link
Contributor

caitp commented Oct 23, 2014

So yeah, I would just ditch the first commit --- 2 lines between specs are nice, and used in most of the test suite --- removing them just makes it more inconsistent. As for the minor whitespace changes, those should be picked up by jscs once we get it doing that, but who really cares if we're honest?

@gkalpak
Copy link
Member Author

gkalpak commented Oct 23, 2014

@caitp:
I am totally OK with two lines between specs as I am with one line.
What I can't stand is inconsistency (2 lines between some specs and 1 line between others). I just removed 3 double-lines to make it consistent across the test-suite (which mostly uses 1 line between specs).

I also removed empty new lines before a closing }); in 3 cases to make it consistent across the test-suite (which also mostly doesn't have empty lines before closing });).

Anyway, those changes (along with a few white-space changes, to make things consistent and inline with the new jscs rules) are placed in a separate commit, so they can't be ignored (only...you know...they really shouldn't, because consistency is a good thing).
If it makes you feel better, I can add double-lines between all specs in the test-suite :)

@caitp
Copy link
Contributor

caitp commented Oct 23, 2014

these are test cases, consistency for minor things like that doesn't matter aw hole lot, so long as they are at least following the formal style guidelines imo. I suggest opening a separate bug for fixing style nits unrelated to this functional change so that it's easier to review (less gunk in the diff)

@gkalpak
Copy link
Member Author

gkalpak commented Oct 23, 2014

@caitp: Hm...I thought putting those changes in a separate commit was enough, but it apparently isn't. I'll remove the commit and put it in a separate PR then.

@Narretz: I am not sure if it's a fix or a feat. It depends on how it was supposed to work. If filterFilter was supposed to handle deep expressions (and filter deep objects) then it's a fix. If it wasn't supposed to support that in the first place then it's a feat :)
Will look into other filterFilter related issues, but I can't be sure which ones you want to get in and which you don't. If you can point out PRs that should get merged, I will gladly "adapt" them to feet the refactored filterFilter.

Regarding #6623:
It sure could be incorporated, but I want to point out that:
Right now, it is possible to use {somekey: undefined} to match objects that do not have a somekey property (or have it with a value of undefined). If we merge #6623 this will be only possible using a custom function. So, we might be removing a feature :)
But, if you think it should get merged, I am totally OK with that as well.

@gkalpak gkalpak force-pushed the filterFilter-deep-expr-obj branch 4 times, most recently from 0d9a987 to d412eab Compare October 24, 2014 06:26
@caitp
Copy link
Contributor

caitp commented Oct 24, 2014

@gkalpak you probably need to rebase now that the other part is merged. yeah you do

@Narretz
Copy link
Contributor

Narretz commented Oct 24, 2014

@gkalpak Regarding #6623; didn't think about that, good point. Leave it as is. :)

gkalpak added a commit to gkalpak/angular.js that referenced this pull request Dec 1, 2014
…prop

Basically, implement the logic detailed in the 2nd point of
angular#9757 (comment)
gkalpak added a commit to gkalpak/angular.js that referenced this pull request Dec 1, 2014
…prop

Basically, implement the logic detailed in the 2nd point of
angular#9757 (comment)
@pkozlowski-opensource pkozlowski-opensource modified the milestones: 1.3.5, 1.3.6 Dec 1, 2014
Previously, trying to use a deep expression object (i.e. an object whose
properties can be objects themselves) did not work correctly.
This commit refactors `filterFilter`, making it simpler and adding support
for filtering collections of arbitrarily deep objects.

Closes angular#7323
Closes angular#9698
…prop

Basically, implement the logic detailed in the 2nd point of
angular#9757 (comment)
@caitp
Copy link
Contributor

caitp commented Dec 2, 2014

So I know I threatened to land this a few weeks ago --- I think we want this, but it looks like some stuff has been added since, and it's really hard to keep track of this diff u_u

Generally I trust @gkalpak's judgement though, so it's probably good. @petebacondarwin can we land this today?

@petebacondarwin
Copy link
Member

It's a big diff but I like that there are only additions in the test file and this is not the most central part of Angular. Let's get this in.

@caitp
Copy link
Contributor

caitp commented Dec 2, 2014

Alright *fingers crossed no regressions*

@caitp
Copy link
Contributor

caitp commented Dec 2, 2014

IT IS DONE ✨

@gkalpak gkalpak closed this in f7cf846 Dec 2, 2014
gkalpak added a commit that referenced this pull request Dec 2, 2014
…prop

Basically, implement the logic detailed in the 2nd point of
#9757 (comment)
@gkalpak
Copy link
Member Author

gkalpak commented Dec 2, 2014

✨ ✨ OMG ✨ ✨

I think I'm gonna 😂

@gkalpak gkalpak deleted the filterFilter-deep-expr-obj branch December 7, 2014 11:01
shuhei pushed a commit to shuhei/angular.js that referenced this pull request Dec 10, 2014
Enable filterFilter to filter deep object by string again. It
used to work like this before angular#9757, 1.3.6.
shuhei pushed a commit to shuhei/angular.js that referenced this pull request Dec 10, 2014
Enable filterFilter with string expression to filter objects with deep
properties. It used to work like this before angular#9757 and v1.3.6.
gkalpak added a commit to gkalpak/angular.js that referenced this pull request Dec 11, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.