Bug when changing page size and using paging?

Webix JS
1

I am trying to add a page-size dropdown to my datatable, so my user can choose the size of the table. For this to work, I set the size-property of the pager and reload the data. This works.
The problem happens after I change the page size. When I navigate to the next page, the page size is completely wrong. It seems like the original page size is remembered and the data is added to the end of the table.

I have an example: http://webix.com/snippet/f9cc7e92

My data comes from an api. When debugging and using the pager, I see the wrong page size is being sent to the server.

2

If forgot to mention: when making the page size larger, the problem isn’t visible. When making the page size smaller than the original page size, the problem occurs.

3

Check the updated snippet

http://webix.com/snippet/dbfeb9e0

The key point is

$$("mypager").config.size = newv*1;

size must be a number, when you are providing a string it breaks the inner math.

4

Aah, I would have never caught that, thank you!

I now have a similar problem. It’s difficult to illustrate with a snippet, because the data is loaded from my (local) server and served in chunks/pages. I tried to set an example up here. It’s the same logic I use: http://webix.com/snippet/1a211c8b

The problem with this, is the sorting. When I click a header that is set to server sorting, the GET is executed normally at first. But after I set the page size (I use loadNext to load the first page again), every sort action will result in 2 GET executions. The first GET does not include the “start” and “count” headers and the second does. I added a onAfterLoad to show what I mean. That event is called twice in my code.

I know it’s a tricky issue, since the snippet works correctly. I can simulate it perfectly on my machine. When I return the complete resultset from my server, the problem does not occur (like is simulated in the snippet). When I send only the requested pagesize, the problem starts.

5

It seems like the problem has fixed itself after refactoring the functionality. I guess it was a programming error from my side.