When executing goTo in clientPager with a page number which is out of bounds (1 <= page <= totalPages), clientPager tries to navigate to it and we get 0 records and currentPage = page number.
I would expect that (1) it will thrown an exception or (2) will navigate to the default page (paginator_ui.firstPage).
I tend to prefer option (2). I will create a pull request for that.
@alanrubin (or) may be (3) If user is on 11th page (out of 20 pages) and goTo is called with 100 then just do nothing.
This was our client requirement.
@addyosmani @alexandernst what do you guys think?
I would favor (1) but done in a way that the application could basically continue working. i.e we return optional status data that developers can use to say, show an error message if they wish, or, support the behavior @skusunam mentions above if they prefer. I feel that if we were to default to (2) one might think there was something wrong with the application.
fwiw, at google we basically just state no results could be found if the page is out of bounds, like in this example
Well... I'm a C++/Qt4 guy, and in those cases Troll's docs say an exception should be thrown. This is not the best practise in JS, so...
On the other hand, returning something from goTo will mean that we should convert a "void" function to "< type > function" which, in some cases, won't be really reasonable because there maybe won't be an option to get the returned value.
Maybe a (mixed) solution would be do both a + b, being a and b:
a) Create a second parameter in goTo which will specify what/how should goTo behave in case of out bounds;
"GOTO_CLOSEST" ---> will go to the closest possible existing page;
"GOTO_CLOSEST_AND_ERROR" -> do the same as the previous one, but make sure to throw an exception too.
"DO_NOTHING" --> ......
b) Always return something so the dev could still be able to know if something bad happened.
@alexandernst @addyosmani Looks like we are all in agreement with returning some kind of special data when goTo page falls out of maxPage. Question is how should we do this?
@alexandernst I got what you are proposing and as a library we should not care what user want to do when this case arises as long as we return some kind of data showing what went wrong.
@skusunam Yes, indeed. But we must provide devs a way to control goTo in case it fails.
If we just return something (say 0 for OK and 1 for KO) then devs should expect a 0 or a 1 and then do stuff. But what if devs just can't < wait > for a return?
There are some cases in which you just run a funcion and can't wait for it to return anything. In those cases devs should be provided with a way to specifi how goTo should act. And that's were my previous comment comes in.