dirPaginate: on-page-change function called on page load.

[nehakansal]

Hi,

The on-page-change function gets called when I load my page, without clicking on any of the pagination controls, is that expected behavior? Ideally, I don't want the function to be called for the first page, are there any changes I can make to support that? <dir-pagination-controls pagination-id="tweetPaginate" boundary-links="true" on-page-change="tweetPageChanged(newPageNumber)" template-url="./js/dirPagination.tpl.html"></dir-pagination-controls>

Thanks.

[michaelbromley]

Hi,

I just looked into this and I think the answer is no, this is not the expected behaviour.

Check out this unit test which tests that the on-page-change callback is called 0 times after compilation, and 1 time after a page link is clicked.

Also, if you check out the demo plunker and open up your console, you'll see that the callback (which logs "going to page x") is not executed on page load, but only upon clicking a page link.

Check that you have the latest version of the script and then let me know if it is still not working as expected - show me some code too in that case.

[mlbcodes]

I am experiencing the same issue. I will update with a code sample to demonstrate.

[nehakansal]

Okay, thanks. I will update to the latest version and get back to you. Thank you.

[nehakansal]

Using the latest version of the script did fix the issue. Thanks a lot!

[Alexabix]

I had a similar issue - the cause was that I had the pagination controls within an div using ng-if.

[mlbcodes]

I haven't been able to put together a code sample to demonstrate, though I am using the controls inside a ui-view partial (using ui-router).

[michaelbromley]

@Alexabix I looked into what happens with the controls inside an ng-if, but in my test the callback was not fired on page load, see: http://plnkr.co/edit/eiLE6cSHx2Bo8pmdQ3RC?p=preview

Are you able to create a plunker or provide code where the callback is fired on page load?

@mlbcodes okay, having it in a ui-view might be to blame. Did you find a way to fix it?

[Alexabix]

I've not been able to recreate the issue on pInker though it was similar to this except with server side paging done an API call via an angular service. http://plnkr.co/edit/jwSj5IkoninJsQATIzmU?p=preview

I think the issue was more a design fault on my page, the ng-if over the pagination controls shouldn't have been set to the results object. What I think was happening is that when the object was over written with the new async results the ng-if was causing the paginations controls to be removed from the DOM and then re-added. Then that was firing off the page change event for the default page number.

[michaelbromley]

Thanks @Alexabix for the explanation and the plunker. Does that mean you have fixed it now?

[Alexabix]

@michaelbromley I'd fixed it when I made my first comment, I just thought I'd leave a note for anyone else who searched for like I did.

[Bighamster]

I have a similar issue - the cause was that I use server-side paging. The file: data.json gets called twice at strart up. http://plnkr.co/edit/EFCQ8V7j90AiaAP2JmMM?p=preview

[michaelbromley]

@Bighamster Thanks for that plunker demo - really helpful. I found that the behaviour in this case is caused by the dir-pagination-controls directive being declared before the dir-pagination directive.

When they are declared in this order, it seems that the "itemsPerPage" value is undefined when the controls directive is compiled, but then when the pagination directive is compiled, the "itemsPerPage" value is set to the value specified in the filter. This causes a $watch to fire in the controls directive, causing that behaviour.

I've got an idea of how to fix this which should not take long.

[sudheervm]

Check if you have multiple pagination controls in the same page. if yes set pagination Id. Add one condition in ng-if when the data is null donnt load pagination controls.