Need help for lazyloading

Suite and Optimus Suite 8
#1

Hi all,

i have a table of 50.000 rows
i made a standard load service for a grid on this table
it worked fine returning 50.000 rows
I have dhtmlxSuite Pro 8.3.9

I adapt my service for lazyload
so with
var lazyDataProxy = new dhx.LazyDataProxy(url_dila_rar_liste_lazy, {
limit: 5000, //i expect that this will throw 10 requests of 5000 each
prepare: 5, //note that i don’t understand for what this is useful
delay: 150, //i expect that each request will be launched every 150ms
from: 0 //i expect that first request will be launched with this parameter
//will be launched first with 0, second with 5000, third with 10.000 and so on
});

the output is :
{
data :[…], // data retrieved from my table with rank between from and from+limit
total_count: 50000, // total_size of the table
from : 0 //identical to from parameter
]

when i launch it, the get url launched is
https://apex.qualif.pgi.dila.fr/ords/apex_ebs_extension/dila_rar/liste/lazy/0/18810/1?limit=5000&prepare=5&delay=150&from=0&responseType=text

I receive correctly in my grid the first 5000 rows,
but no other requests are launched in background to receive the other 45000 rows

do you have any idea what is wrong ?

#2

Hello,

First of all, my apologies for the very late reply on this thread.

In short, the behavior you see is expected: LazyDataProxy does not automatically send 10 requests of 5,000 rows in the background. It sends the first request, and all the next requests are triggered only when the Grid asks for more data, when you scroll down to the bottom of the currently loaded rows.

So, with your config:

var lazyDataProxy = new dhx.LazyDataProxy(url_dila_rar_liste_lazy, {
	limit: 5000,
	prepare: 5,
	delay: 150,
	from: 0
});

the mechanism is:

  • The first request is made with from = 0, limit = 5000 → you correctly receive 5,000 rows.
  • The Grid will ask for the next portion (for example from = 5000) only when it needs to render rows beyond the currently loaded range (e.g. when you scroll down).
  • delay: 150 is not a timer that fires requests every 150 ms; it is the minimum interval between consecutive lazy-loading requests, to avoid too many requests during fast scrolling.
  • prepare: 5 means “load some extra rows in advance” (prefetch), in addition to the rows that are currently needed for the visible area.

The official description of these parameters is here:

And the live sample that demonstrates the expected behavior is here:

#3

Hi maksim,
Thx for your response, it is more explicit than the documentation.

My thoughts was to download ALL in background to save times.

Actually my grid has 50.000 rows with many columns and filters,
It is loaded in 15 seconds.
I need it to be fully loaded for filters.

I expected loading first rows quickly
- first 5000 loaded in 2 seconds
- loading 45000 in background, and when fully loaded i could filter my grid

So in my case, i can’t use it. (scrolling all lines to force full download, and then enable filters don’t seem a good option), i will stay with my 15 seconds

1 Like
#4

Hello,

Possibly, for your case where filtering must work on the entire dataset, a better approach would be server-side filtering instead of trying to combine client-side filtering with lazy loading.

A typical setup could look like this:

  1. When a header filter changes, the Grid does not filter already loaded rows.
    Instead, it sends a request to the server with filter parameters, for example:
    GET /api/grid?from=0&limit=5000&filters[country]=China&filters[name]=abc

  2. The server applies filters directly in the database query and returns:

  • the requested slice of data (from / limit)
  • the total number of rows matching the filters (total_count)
  1. Lazy loading can still be used in this setup: the Grid requests the next chunk only when the user scrolls, but all chunks belong to the already filtered dataset.

With this approach, the first rows are displayed quickly, filters work on the full dataset, there is no need to load all 50,000 rows into the browser, and both initial load time and client-side memory usage are reduced.