Is it necessary to filter a collection in Angular?

Question

Angular

Hello, help me understand the process of implementing sorting (filtering) of goods in an online store on Angular.
Let's just say, there is an array or a database from which I display data (name, price, category, etc.) The
user needs to be able to filter the list of goods, say by price, or he enters the desired name into the input and the goods are displayed to him in according to his request.
So, in Angular this is done quite simply,
Here I display a list of products

<tr ng-repeat="product in products  | filter:query | orderBy:predicate | orderBy:price"> 
            <td> {{ product.title }} </td>
            <td> {{ product.price}} </td>
            <td> {{ product.description }} </td>
            <td> {{ product.mutch }} </td>
            <td> {{ product.state }} </td>
          </tr>

And then I filter it by name

Tittle: <input type="text" ng-model="query.title" class="form-control">

Or, for example, by any other parameter, for example, by select

<select id="bedroom-filter" ng-model="query.mutch">
               <option value>All</option>
               <option value=1>1</option>
               <option value=2>2</option>
               <option value=3>3</option>
             </select><br />

I was advised not to do filtering in this way, but to implement the output of the required collection in the controller or service, but then the user will not have the opportunity to do something himself. Can you explain what is the harm of such manipulations? Thanks in advance!

Answer 1

but then the user will not have the opportunity to do something himself

I already wrote to you in the comments to another question but I will duplicate it. When the user selects some other sorting or filtering option, we simply notify the controller of this. He will already ask the services to provide data according to our new conditions. The service will do all this and return the data to the controller. We can prepare the data for our view a little more and spit it out in the view (in fact, the data falls into the $scope). Further, due to the date binding, the view reacts to a change in the state of the data and adapts to them according to your description (all these ng-repeat, etc. It’s not for nothing that templates in angular are called declarative).
This is actually MVC, with this approach, our view will not care deeply about the implementation of filtering, and our model (logic for working with data) does not care about how this data is displayed. And the controller will be only an intermediary who will know how these two layers communicate with each other.
I decided to make an example, which I will refer to further:
Example
And now I'll explain a little why you need to drive like this at all and when it's acceptable to filter everything in the controller or in general in the view, so that there would be no misunderstanding.
Let's imagine that we mentally divide our application into two layers: a layer that works with data (M), and a layer that displays this data to the user (V), and, in combination, handles user interaction with this view (forms for example).
To simplify the support of the system, we need to reduce the coupling of these two layers, making them as independent as possible. So that changes in one layer do not cause a special need to change something in another. To do this, we introduce an intermediate layer - controllers (C). This is essentially the main idea behind MVC. Divide and rule.
Now let's think. Here you are making a catalog of goods according to the scheme ala "we load all the data on the client and filter everything there." And everything is going well, we quickly washed everything down and now there is already a lot of data. So much so that the application starts to kick or just loading all the data takes a monstrously long time. And now you have decided that the filtering will now take place on the server, and you will only download what you need now.
If your work with data has already been divided, this will not be a problem. We will simply change our ProductCatalog and replace the methods there with the ones we need. View from this will not change a bit. Moreover, we can safely cover this functionality with quick unit tests.
But there is also such a thing as technical debt. This is when we need to file this same filter for the first time, a client or manager comes up to you and says "no time to explain, you need to urgently explain it the day before yesterday." And we have a choice here:
- argue with the customer about what needs to be done right
- to spit and make the fastest possible implementation, thus taking "borrow" from our code. That is, everything works, but in the future we will have to repay this debt. They say we decided later to transfer the filtering to the server and it will take more time, since we once saved on development.
In short, you need to strike a balance. Sometimes such decisions are more than justified.
But back to the realities of anuglar. The fact is that when you use filters in templates, they will twitch on EVERY $digest cycle, this is how date binding works. That is, with a relatively small amount of data, our application will already pedal terribly. Therefore, it is excusable to use filters with collections in templates only if you are 100% sure that there will be little data yet, and then it will be possible to redo it.
Something like this. Since you have the option to use Angular filters inside services or controllers, the "economical" option will take no more development time and maintain such code will be easier.