fix(filterFilter) deeply-nested predicate objects + multiple conditions were not giving expected results #7329
Conversation
|
Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.
If you need to make changes to your pull request, you can update the commit with Thanks again for your help! |
|
oh no, did I make the API behave in weird and inconsistent ways! teh shame, teh shame. |
albertboada
changed the title
|
It looked like to me! Or maybe I was too sleepy, lol. Could you confirm (that I wasn't too sleepy)?? Thanks! |
|
I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS. Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match. If you signed the CLA as a corporation, please let us know the company's name. Thanks a bunch! PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR. |
|
@mary-poppins, I know you will probably not understand me, but just signed the CLA :) |
|
CLA signature verified! Thank you! Someone from the team will now triage your PR and it will be processed based on the determined priority (doc updates and fixes with tests are prioritized over other changes). |
|
@caitp Any change of getting this reviewed anytime? 😳 |
| if (textKey.charAt(0) === '$' || !hasOwnProperty.call(text, textKey) || | ||
| !comparator(obj[textKey], text[textKey])) { | ||
| passes = false; | ||
| break; |
|
A few nits there, it's easier to read if we're just returning rather than keeping an extra state variable and switching it on. Another alternative would be just making it default to Anyways, the tests look good, this needs to be squashed to one commit with a message following the commit message guidelines at https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit Apart from all that I don't see any obvious problems with it |
|
Thanks for the tips! Should be good to go now (I guess!) :) |
…itions not returning expected filtered results Current implementation of `filterFilter` when using deeply nested predicate objects + multiple conditions behaves like if it used _OR_ operators (i.e. it doesn't matter if some conditions don't match as long as one does), and should be behave like if it used _AND_ operators in order to be consistent with the original implementation for non-deeply-nested predicate objects. `filterFilter` working with deeply-nested predicate objects was introduced in 1.2.13 as a result of angular#6215.
|
+1 |
|
@SebastianM myeah, deep filtering has been broken probably for too long now for a first-class tool like this one. Both this very pull request (#7329) and #6623 should be taken into consideration for a one-time-fix of deep filters introduced in February. @caitp any roadmap on this? |
petebacondarwin
force-pushed
the
master
branch
from
02dc2aa to
fd2d6c0
Compare
jeffbcross
force-pushed
the
master
branch
2 times, most recently
from
cad9560 to
f294244
Compare
jeffbcross
force-pushed
the
master
branch
4 times, most recently
from
e8dc429 to
e83fab9
Compare
petebacondarwin
force-pushed
the
master
branch
from
4dd5a20 to
998c61c
Compare
|
Closing this, finally! in favour of #9757 :) |
Request Type: bug
How to reproduce:
http://plnkr.co/edit/Yd705mYbqKJ3n79TXLmx?p=preview
Component(s): misc core
Impact: medium
Complexity: small
Detailed Description:
Fixes current
filterFilter's implementation (introduced in 1.2.13 as a result of #6215) for deeply-nested predicate objects + multiple conditions scenarios.Problem: when using deeply nested predicate objects,
filterFilteris currently behaving as if it was using OR operators (i.e. it doesn't matter if some conditions don't match as long as one does), and should be behaving as if it used AND operators in order to be consistent with the original implementation for non-deeply-nested predicate objects.