in 1.3.16 ng-repeat filter changed from not filtering the absent fields to filtering them

[ali-bugdayci]

in 1.3.15 we have working code like this:

<div data-ng-controller="UserController as vm"
        <div ng-include="'modules/users/views/usersTable.template.client.view.html'">

where the ng-view included can see and use the vm object.

Update to 1.3.16 breaks this and ng-view creates a new scope object. Hence the vm used inside the included code is not same object.

[Narretz]

There is nothing in 1.3.16 that should affect ng-include. Can you please provide a demo of the problem?

[ali-bugdayci]

Hi,

Thanks for the fast response. As you have mentioned the problem was from the change in the "filter filter" implementation.

In 1.3.15, if the filter object values are absent in the data, the data passes through ng-repeat.

In 1.3.16, if the filter object values are absent in the data, the data is not passed from ng-repeat

Check the plunker: http://plnkr.co/edit/5WSyJIlnxRmwkY8wk590?p=preview

[ali-bugdayci]

Must have been appeared when fixing these issues:

filterFilter: fix matching against null/undefined (9dd0fe3, #11573, #11617)

[lgalfaso]

If you need to put a value on a filter so it gets ignored, then it should be set to undefined. Eg ng-repeat="datum in vm.data | filter:{absent: undefined}".
Sorry that this is causing you trouble, but the behavior at 1.3.16 is the correct behavior.

[ali-bugdayci]

No no. Have you checked the plunker I send? To make it more discrete I am outlining a usage scenario:

• Go to :
  http://plnkr.co/edit/E5WhPwmocYNukQhJzmzX?p=preview
• At first the search field is null. And 1.3.16 is displaying them all.
• Write something to the search field like 'a'
• Then delete the search field input
• This time the search is blank string
• 1.3.16 is just displaying one of them

1. User wise this is not acceptable. You have a list of options. When you filter then it works. When you clear the filter it is not back to how it was.
2. Now a days lots of folks are using NoSql databases. Hence you can not make sure that each field exists in the data returned, since they are mostly schemaless.

[gkalpak]

@ali-bugdayci, this is unfortunately how filterFilter works (which is indeed kind of unexpected in some cases). Note that the change between 1.3.15 and 1.3.16 was intentional in order to fix an old regression introduced during a refactoring in 1.3.6 (so basically, 1.3.16 restores the original behaviour of 1.3.5).

In cases where you want to avoid an emty search field resulting in case-insensitive substring comparison against '', you can change your filter expression like this: | filter:{xyz: search||undefined}
(Updated plnkr)

[ali-bugdayci]

@gkalpak
The problem with search field is that, in big projects it is most of the times an object not a string. Like we have different input fields where we aggregate the search object.

If you are aware that it works like this and ok with it, than I have nothing to say. But from my users point of view I believe the scenario I described is not acceptable. Seems like I will be sticking with 1.3.15 for a long time.

[gkalpak]

This is has come up a few times and we (I) are aware of this. I don't say I am against changing it, but it will be a breaking change. I am definitely open to discussion, though.

Luckily, Angular is too flexible for you to have to stick to 1.3.15 for a long time, as it provides several ways of making things work the way you like. Off the top of my head:

1. A special ngModel parser that converts empty string to undefined (either on all input fields or on all input[type="search"] fields or with a special directive.
2. A custom filter that wraps filterFilter (and igores empty strings).
3. Decorating filterFilter itself (to ignore empty strings).
4. Using a custom predicate function as expression.
5. ...

(Especially for a large project, the overhead should be minimal 😃)

[ali-bugdayci]

@gkalpak Yeah you are right. May be the best way would be to configure the filterFilter with a filterprovider and choose how you want it to behave.

[gkalpak]

@ali-bugdayci, what would that filterProvider allow you to do which isn't already possible ? Do you mean something like offering a config flag to enable ignoring empty strings ?

BTW, there is no such thing as "provider" for filters, but we might be able to attach some properties on the filter itself.