refactor pagination: change pager params

[enkodellc]

change paginationMaxBlocks/paginationMinBlocks to use pager settings pager {minBlocks: 5, maxBlocks: 11} to allow future enhancements of pager. Set defaults to 5,11 if they are undefined.

BREAKING CHANGE tableParams paginationMaxBlocks/paginationMinBlocks are updated to use pager {minBlocks: YY, maxBlocks: XX}

PR 1 as suggested in #656 by @christianacca

[christianacca]

Couple of pointers about the commit:

1. You don't need to update the CHANGELOG.md as part of this commit
   • the content of that file is code generated from the commit messages
   • the file is updated only as part of creating a release, which usually happens after a bunch of committs
2. The commit message itself should follow our conventions

Have a read of the following to make sure you got all the details:

• contributing guideline
• release guideline

[christianacca]

Actually Keith can you:

1. amend your commit:
   • remove the CHANGELOG.md change you made
   • change the commit message to follow conventions. Here is an example to follow: 6bb2aba
2. push this to your fork
   • this will automatically update this PR

[christianacca]

I've been thinking about the counts field:

Is counts only purpose just to configure the pager?

I think a reasonable test is to consider infinite scrolling. If infinite scrolling (#560) was added would it use the counts value.

Looking at the #560, it does not.

Therefore I conclude that the counts field should also be moved into the new pager settings object you're creating.

So this gives use:

var setttings = {
    /* snip */,
    pager: {
        counts: [10, 25, 50, 100],
        maxBlocks: 11,
        minBlocks: 5
    }
}

Can you add this to the current PR (#674). It should be a separate commit once you've amended your previous one.

[christianacca]

BTW, we're doing significant breaking changes here... that's acceptable in this case as we're pushing to get to a 1.0 release and the api needs tidying up...

[enkodellc]

@ccrowhurstram Read the docs, made most of the suggested changes, changing pushed commit messages looks messy. If every commit / commit message needs to be perfect then I will have to bow out from making further PR's. I understand the need for consistency but it seems like you know exactly what you want and I am not sure if my edits will be sufficient as I am fairly new to git / Angular / JS.

[christianacca]

OK, but shame as my time is going to run out shortly at least for the next couple of months so this change might not make it in.

It can get fiddly for sure to amend a previous commit already pushed. However, it's definitely a good tool to have in your toolbox...