Open michaelbushe opened 1 month ago
One way you could get around this issue without having to go through with internal API changes, is by pagination. I still don't know whether or not your problem is with cells in particular or just a high number of rows. But you don't have to create all rows upfront. I'd say you could implement a pagination mechanism of your choice, and then dynamically add the rows to pluto grid based on the page you're on.
You can make use of onLoaded
method inside the PlutoGrid
widget to do so. Use the insertRows(index, row);
method provided by the plugo grid stateManager to dynamically add rows. You don't even have to manually trigger the PlutoGrid rebuild when your page changes. Using the state manager to add rows will automatically trigger a rebuild of PlutoGrid if you want it to.
Now that the baseball season is over, I'm back into PlutoGrid to create a baseball app for next season. I hope to help out and improve PlutoGridPlus.
The core PlutoGrid API seems weak or even faulty at scale. Am I missing something? I'm looking for something like Java's JTable/JTableModel - can it be done?
AFAIK with PlutoGrid, for all 50 baseball statistics for all 1,000 players that played in baseball last year, I need make a 50,000 cells upfront even though the user can't see any more than maybe a 200 cells at a time on their screen:
Good thing I'm not working with DNA! I'd have to make millions of cells instead of 50,000. This API doesn't scale.
Here's how Java's JTable scales:
The JTableModel is only called for values when the cells are visible. You never make cells, the column renderer is a cell "stamp" and it's backed by the table model.
You might say you need all the cells for summaries but with JTable you just have to special case footer rows:
Is there a way to get PlutoGrid's API to be scalable like Java's JTable? If not, how could I make it so?