Let's work on a "page group cache" for tables with a large scale of table row items

Created on 21 January 2023, almost 2 years ago
Updated 6 October 2023, about 1 year ago

While the purpose of a Javascript driven table is the prevention of reloads and server performance hits with repeating calls of table content after filtering or sorting or changing the limits of items show, etc., by loading all data in the background, we need a cache idea to prevent a unique very large and slow server hit by calling a table of 2000 or more complex items. Since the way how such Javascript implementions work by "hiding the rest until it is required" makes a 100% call of ALL data even if just 10 or 50 of them are shown to a server hug. In such cases it would be great if we could work on a second level of scalable cache paging option to, let's say, change the difference between shown and called/cached items step by step. Like if we would have 2 pagers, one for the view and another next level for the "middle cached page" holding the viewable pages already loaded.

Example:

  • Viewed
    • 20
    • from 100 of 3500
    • view pager with steps of 20 items per page of all, 100 already loaded in the background.
  • Cached
    • 100
    • with 5*20 loaded of 3500
    • cache pager of a cache with 100 items already loaded for changing the view pager quickly until we hit the next 100 items

.

All changable of course. Thougths? Let's talk about it ;-)

Feature request
Status

Active

Version

2.0

Component

Code

Created by

🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024