dirPagination: on-page-change called 6 times each time I change page (version 0.9.4)

[ghost]

I don't think it used to happen, but now I see that every time I change page the on-page-change event is triggered anything from 2 to 6 times resulting in slow list updates as each time it is called I refresh the page from the server (I am using server paging)

When debugging the code

  scope.$watch(function() {
                if (paginationService.isRegistered(paginationId)) {
                    return paginationService.getCurrentPage(paginationId);
                }
            }, function(currentPage, previousPage) {
                if (currentPage != previousPage) {
                    goToPage(currentPage);
                }
            });

triggers the goToPage function multiple times when I change from one page to another

all the variables paginationId, currentPage and previousPage as as expected, it just calls the goToPage multiple times

[michaelbromley]

Hi,

Please could you fork and edit this plunker demo and try to reproduce your issue? Paste the link to your updated demo here so I can take a look.

Note that the latest version is 0.11.0 - although I'm not sure if that should make a difference.

[ghost]

I have recreated on plunker... here is the link

[http://plnkr.co/edit/wMSxBaJgmQ94QoOEySwz]

If you view the console log whilst changing page, you will see that it calls the event twice for each change of page

I know what the issue is now.... but I dont know how to fix it

I like to have 2 pagination controls, one above and one below the list, which is fine as I use the pagination-id to keep everything in sync. Because each pagination control has an on-page-change attribute, you will see that each time I change the page the event is fired twice which in my real life case, causes to hits to my API (I am using server paging in my real life case). If I were to remove the on-page-change attribute from one of the pagination controls then it all works correctly. However I prefer not to have to do that because in my real life case I use different pagination templates for different screen sizes and my code is more like this plunk (albeit with the pagination controls wrapped up in my own directive)

[http://plnkr.co/edit/wbNOx6OLo79GPgU3CUpf?p=info]

Now with this more realistic example get at least 4 hits to the API each time I change page...see the console log

I hope you understand my issue and can point me in the right direction

Many thanks in advance

[michaelbromley]

Hi,

Thanks for the clear demos. I have a few suggestions:

1. If you were to use ng-if on your controls directives, the extra callbacks would not fire. In your case this might not be desirable since you are reacting to screen size, and tracking that in JS may be too much of a burden.
2. You can safely remove all but one of the on-page-change attributes and, assuming the one with the attribute set is in your view, it will fire when any of the linked controls are clicked.
3. The best way to go might be to get rid of that callback altogether and instead just use a $scope.$watch on the value of currentPage. This means that it does not matter how you change the page - it will only invoke your page change function once. I modified your last demo to show this: http://plnkr.co/edit/lM8UKlPwSWoiFB4C364U?p=preview

[ghost]

I think option 3 is the way ahead... many thanks I can make that work :)

[ghost]

Alternatively, I might check that the page has changed by storing the last page requested in a variable and block calls that are not genuinely for a new page

This is what i mean

[http://plnkr.co/edit/sRPIn3jBxbpbn5Xi8laY?p=info]

I think might be neater than having $watches all over the place - I use a lot of lists!!

My though was perhaps you might include similar logic in your directive so it always "just works" even when people (or idiots) like me want to have multiple pagination controls per list.

I mean something like

 scope.$watch(function() {
                if (paginationService.isRegistered(paginationId)) {
                    return paginationService.getCurrentPage(paginationId);
                }
            }, function(currentPage, previousPage) {
                if (currentPage != previousPage && currentPage != lastRequestedPage) {

                    lastRequestedPage = currentPage;
goToPage(currentPage);
                }
            });

instead of what I found in your code

scope.$watch(function() {
                if (paginationService.isRegistered(paginationId)) {
                    return paginationService.getCurrentPage(paginationId);
                }
            }, function(currentPage, previousPage) {
                if (currentPage != previousPage) {
                    goToPage(currentPage);
                }
            });

Just a thought :)

[Mangesh-P]

+1

[michaelbromley]

@hplloyd Yes, that's a good suggestion. I'm going to leave this issue open with an "enhancement" label to remind myself to consider implementing when I make the next update to the lib (no idea when that will be at present).

[ghost]

No worries, my fix is working fine for me until you implement :)

On 19 May 2016, at 5:48 PM, Michael Bromley [email protected] wrote:

@hplloyd https://github.com/hplloyd Yes, that's a good suggestion. I'm going to leave this issue open with an "enhancement" label to remind myself to consider implementing when I make the next update to the lib (no idea when that will be at present).

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/michaelbromley/angularUtils/issues/324#issuecomment-220251897

[GregaVrbancic]

Any news regarding this issue? Or is it still the easiest way to solve this issue the way @hplloyd solved it?

[michaelbromley]

@GregaVrbancic For now I have made not incorporated a fix into the code. Just go with one of the work-arounds mentioned above. To be honest, this module is not something I require for my work projects, and is therefore not high on my list of priorities for spending time on.