View Full Version : Infinite grid does not work with small page size

14 Aug 2012, 10:47 PM

we are migrating our applications from Ext JS 3.3.3 to Ext JS 4.1. In most use cases we used until now a grid which is much like inifinite grid (but it was own development). We decided to migrate to the Ext JS 4 infinite grid.

The problem is that if we set a small page size (10, for example), the grid does not load the data successfully (we have the loading mask and no data is loaded - of course, it is received from the server successfully). If we increase the page size to be bigger than the number of visible rows on the grid, it works.

Also note that we have variable height grids (the user can change the height of the grids). We tried as a workaround to dynamically set the page size but we got an exception in the store: pageSize cannot be dynamically altered (this was introduced in Ext 4.1).

We also tried to tune your example (http://docs.sencha.com/ext-js/4-1/#!/example/grid/infinite-scroll.html) to use a smaller page size and it does not work with page size 10 either. Did you check it?

In the release notes (http://dev.sencha.com/deploy/ext-4.1.0-gpl/release-notes.html) we found this error: EXTJSIV-4747 pagingscoller does not work with small page size marked fixed, but it looks like it is related and is not.

What do you suggest? What can we do to have the Ext JS 4 infinite grid in our projects working properly?

19 Aug 2012, 10:39 PM
I am also interested in this problem. It looks like a bug.

21 Aug 2012, 1:58 PM
This shows as corrected in 4.1.1 GA

Do you still see this behavior?


21 Aug 2012, 11:09 PM
We use 4.1.1 GA in our project and we still have the problem.

Due to our service implementation and performance issues we want to use a small page size (10) for our grids. This is fine, as long as on the grid view we have less than 10 rows. However, if we have more than 10 rows visible on the grid, page size 10 is simply not enough (as we experienced, page size must be greater than the number of visible rows on the grid).

We also tried to set larger page sizes (50, 100, etc.), but for us, scrolling was not smooth enough then.

Please try the Ext example on the sencha site (http://docs.sencha.com/ext-js/4-1/#!...te-scroll.html) with the page size 10. It won't work.

What do you suggest? How shall we solve this problem?

26 Sep 2012, 4:38 AM
Sorry for the delay. This slipped by.

I will attend to this today and get back with you.


26 Sep 2012, 10:17 AM
This seems to be corrected in 4.1.2+

In 4.1.1, setting pagesize to 10 caused the grid not to load rows and loading mask remained on screen. This is not the case in the latest release.


2 Oct 2012, 12:08 AM

we just tested the grid with different page sizes using Ext JS 4.1.2.
Scrolling with small page size works fine now, however there is still a small issue: on the first load, the grid is loaded with exactly pagesize number of rows, even though the grid size is bigger. Is this a feature or a bug?

Steps to reproduce:
1. Set a small page size (10).
2. Display grid with larger height.
3. The height of the grid is quite big, it could display more than 30 rows. Unfortunately, only 10 rows are displayed.
4. If we try to scroll, the remaining rows are also displayed, and the issues will not happen any more.

This happens with the sencha example too.

In case this is a feature, how can we configure our grid to display rows for the whole visible grid size when we have a small page size set?

2 Oct 2012, 11:17 AM
I would say this is by design. The rows should detect the difference in size an make the adjustments to populate the entire grid instead of just the number of rows you set on the page size.

This would of course be a bad way to buffer .. less records that were displayed.


2 Oct 2012, 10:56 PM
Our use case is as follows: we need in our applications 'infinite grids' for which the height might be dynamically changed by user interaction (from fitting around 10 rows until around 40 rows).

Our big question is then, is it possible to configure the grid (and how) in order to be used in our use case?
If not, do we need to override parts of the paging mechanism?