Why pagination with GCE v3 is so slow compared to v2? You can check the loading speed in the links below:
Pagination with v3:
Pagination with v2:
As we can see (from the links above), in v2 the xhr request is triggered instantaneously. But in v3 in takes more than 1000ms to trigger the xhr and starting fetching new data! I suspect the some new js events (maybe some overlay like gc-datagrid-loading) is delaying the xhr request.
Is there any way to speedup v3 data loading/pagination?
In short, there is a delay of 1 second so the user will decide which page they would like to have. I am testing the grid into 1,000,000 rows and every query request is heavy so I am trying to have as less requests as possible.
So in short:
first page or last page → Since the user know that they would like to go in the last page then it is happening instantly
next or previous page → How many times you want to go into page 3 and instead of typing the number “3” you just press 2 times the next button. I do that often
At the above example the request started 1 second later and the user has been informed with the extra loading icon. Also we have skipped the request for the page “2” which is unnecessary. Keep in mind that even if I cancel the request, the backend request (e.g. SQL query) is still running causing performance and memory issues.
The solution to have it instantly is to press the page and then press “Enter”. This will send the page to be triggered instantly.
There is lot of optimization in the background and a hard-work checking every little scenario even for edge case scenarios like this. I hope it make more sense now
Okay, now it makes sense to me.
I know I’ve asked for too many features, but if it’s (super) easy to implement, wouldn’t it be worth creating an option for the user to disable this delay/behavior? I wonder if such a feature would not negatively affect the experience of most users, in exchange for a hidden benefit, difficult to understand on first contact.
and make sure that you have the “publish_events” configuration to true. For more about how to use JavaScript events you can check JavaScript Events | Grocery CRUD v3
In fact, this removed the delay in the pagination click but, unfortunately, it resulted in another error when clicking on the buttons for the 1st and last page: Error: Internal Server Error. / empty response
After playing around with the paging (to solve the filtering issue) I’ve decided that I will remove completely the delay . As I said to the previous post, I am preparing a new major version (no breaking changes don’t worry!) which will be the 3.1 so please be a little patient.
Thanks @johnny, I’ll give the new version a try. What exactly the new option “Display JavaScript files into the main output (default is false)” do? What is it used for?
As I’ve also wrote to the configuration value it self:
Include JavaScript files in the main output and don’t return them at ‘js_files’ variable.
This is useful for quicker installations/demos, but it is recommended to set this to false
and have all of your JavaScript files at the bottom of your page before the tag.
Please consider that when JavaScript files are included directly in the output, you lose the ability
to control when and where these files are loaded.
So in short if this is true you can remove the js_files from your view. It is one step less for newcomers basically
In the future, I am trying to have installations with less steps. I will also probably create a blog post for version 3.1 to also describe this configuration in more details.
