Is it bad practice to make direct paging on the front end?

Asked

Viewed 1,075 times

0

I have some systems Java + AngularJS, in some pages on back-end, using paging of Hibernate, ex:

query.setFirstResult(0);
query.setMaxResults(10);

But recently I found some libraries from AngularJS paging, I noticed no difference in performance because I don’t have much data to test. This is the library that I’m using.

  • Making direct front-end paging with these libraries is a bad thing practice? Why?
  • These actions can hinder the performance of my system?
  • If they get in the way, when I should wear them?
  • 3

    If it’s too much information, and the user usually uses just the first page, you’ll always be carrying a lot more information than you need. If it is little information, and/or usually the user needs almost all of the pagination, it may compensate for the savings of requests. As usual, the magic answer is: depends on!

2 answers

3


I believe that you should take into consideration when designing a page would:

  • Amount of information displayed;
  • User’s need to consume all this information;
  • Agility to get new results with the same agility you would have when just displaying new data;

The AngularJS is very good in this regard as you can control the amount of results displayed in a ng-repeat through the filter limitTo. It’s more than proven ng-repeat has a major impact on performance when misused and/or with large amounts of data. So in this case, bad practice is more associated with the way you use the ng-repeat than to pagination in front-end proper.

I think you should take into consideration, especially, the user’s need to consume this information. A portfolio pagination, news, for example, is different from the pagination of a survey. In the portfolio it is more common for the user to browse the results, while in a list of search results, if not found in the first views, it is more likely to be a new search rather than a navigation. As is the case with the second page of Google.

So try to answer the following:

  • How long is your data list to create a performance bottleneck?
  • How many tabs the user will browse?
  • How fast between "add +1 page" vs "perform another request"?

Changing only the filter limit quantity limitTo you have the most data display well say instantly.

I find it hard to have any case where it’s easier to do the request in stages, than do the request whole from the start. Even because nowadays, hardly anyone will navigate through a list so long that it is unlikely to make her entire shipment at once. Be patient...

3

Making direct front-end paging with these libraries is a bad thing practice? Why?

In no way is it a bad practice. It all depends on the amount of data to be recovered from the server. This should be your guide when evaluating pagination client or server side.

Do not believe when you are told that server side is always the best option, because if the amount to be recovered from the server is not large, So why complicate your life by having to implement Hibernate paging if you can delegate it to a library like this one or several others? The jqGrid library, for example, works very well with both options.

If the system consists of several tables of registration, then for those that must display few data (eg: < 100 records), use the pagination on the client side. You will be well served and avoid server-side code.

In addition, client-side paging avoids requests, as a pagination server side requires at least one request for each requested page.

These actions can hinder the performance of my system?

They can get in the way if you delegate a lot of data to the customer. Note that to paginate on the client side it is necessary that you have all the data loaded into the client’s memory, therefore you need to recover them on the server. Depending on the amount of data, this may take time and make the system slow down for the user.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.