In extjs 7.5.1 all gridpanel are "infinity scroll" ones and have the plugin https://docs.sencha.com/extjs/7.5.1/classic/Ext.grid.plugin.BufferedRenderer.html
"(...) users to scroll through thousands of records without the performance penalties of rendering all the records into the DOM at once. (...) It is instantiated automatically and applied to all grids"
I am struggling with a application migration to extjs 7 from an older version. It works as expected in the source extjs 4 version (with same amount of lines ~80k). First step was to remove explicit creation since it is not supposed to be used directly anymore.
This is a private utility class for internal use by the framework. Don't rely on its existence.
What is the best approach to try to troubleshoot what is going on?
In the browser DevTools:
grid.bufferedRenderer.isBufferedRenderer <true
grid.bufferedRenderer.isPlugin <true
grid.bufferedRenderer.disabled <false
grid.bufferedRenderer.id <null
This last one may seem suspect... But if I do a getId() instead it gets an generated Id from that point on.
Given my lack of tim, I am unable to reproduce a example of the code, and I am not allowed to share the real code.
I have a before application (extjs4) and an after(extjs7). So we migrated the version of the extjs for a new version and fixed a lot of broken functionality, most of them had an explicit error and we could track the error to a location in the code (many times in extjs framework code, since it would manifest itself there).
Memory snapshot shows 4GB of ram mostly in DOM objects, so BufferredRenderer is not doing it's job.
I have reviewed the code looking for suspicious overrides or configuration that might have cause conflict with new version of extjs. I have and will try debugging code, but since the issue occurs in extjs side of code, I am taking a lot of time to try figure out what is going on with very little progress. Maybe I will try to stub data to fix volume of lines in a fast to iterate but big enough to check the Dom for the opitmization, hoping 200 lines will suffice.
We are still trying to understand exactly what happened, but we have found an effective workaround: creating or binding a new store for each search.
I replicated the issue outside of my application with a helper static data file. We are using extsj 7.5.1, and I will try to make a fiddle if I find some free time (not likely).
If I do a dynamic binding using grid.bindStore(store), it effectively shows large amounts of lines; if I use the Ext.grid.Panel store configuration, it doesn't and blows up with an Out of Memory exception. Suspect something regarding a buffered renderer bug. Not sure.