This week I worked on fixing the code for records mode.

The records mode was not working as well as the rows in the infinite scrolling PR. I have spent this week identifying and fixing the problems with records mode, which mostly circulated around the ways that records are rendered.

One of the things that we discussed in a meeting was the performance issues in records mode. A significant problem with records is that the rendering is done record wise, which means that even if the cap to load a given number of rows (which is the same variable used to cap the records) is set to a particularly small number, we do not have any control over just how many rows will be loaded (since a single record can contain many rows). One of the ways this could be solved is to change the rendering method to row wise for both the modes. This means that if the page size is set to 50, only 50 rows will load (even if the first record itself might contain 100 rows). This could be done by keeping a variable in the records model which will keep track of the last loaded row.

For example, say we allow 100 rows to load at a given time. The first record contains 50 rows and the second record contains 100 rows. By using the mentioned page size, we can load rows till the 100th row or till the 50th of the second record and save that position. When we go to load the next set, we can check what the value of this variable is and start loading the records from that position. This would require some discussion on the mailing list and significant changes in the backend. Since records mode in itself is not in its best format, trying to change the rendering might get redundant later on when we try to restructure the entirety of records mode.