0

The table

Let's say we are running a webapplication for the Superhero Association. In there, there is a table of 1 000 000 super villains which need to be watched. Everytime a super hero gathers new information about villains he updates the table.

The table itself is paginated, sortable and filterable.

Example

The user is on the first page of the table, all over there are 1 400 results, displayed are the first 5 results, sorted by strengt. A request is sent to the backend, it delivers the first 5 results.

Inital view

The users edits the last two entries.

View before page switch

The user now switches to the next page. Again a request is sent to the backend to retrieve the next 5 super villains.

Problem

Since the list is sorted by strength and the user edits strength, the order changes. In this example, that means two things: The user stumbles again over the entries already edited + he skips the entries which silently slip on the previous page. Therfor we want to remember the order of the objects in the initial view at all time while editing and switching pages.

Discarded Solutions

  • Prefetching all the data. There is a potential of millions of entries, way too much data, that would not work.
  • Prefetching only the IDs and then request single ids to retrieve the next full page. Similar concerns, the list might get way too large.

That can't be a problem that only the Superhero Association has, are there any best practices? Thanks in advance!

3
  • Most sites simply ignore this problem and hope that the user can cope with it. E.g. if you switch to the next page on stackexchange, and a new #1 post has been created in the meantime, you'll see the same post at the top of page 2, which you just had at the bottom of page 1.
    – mtj
    Jun 25, 2020 at 10:05
  • Yes. Yet I did not even find an example site, where this behaviour is implemented.
    – sevic
    Jun 25, 2020 at 10:17
  • You can circumvent the issue to a certain degree by using an infinite scroll and the cursor pattern, rather than using regular pagination. However this means the given section of the application would probably differ a lot from the rest, if the rest of the application uses regular pages.
    – Andy
    Jun 25, 2020 at 10:47

1 Answer 1

2

Step back a bit and look at situation from a cost/benefit perspective:

How much is gained by implementing the feature (or how much is actually lost by not implementing it) versus how much does it cost in development and operations to have this feature?

Most organizations decide that the benefit of having a stable pagination versus occasional duplicates or holes is just not worth the cost of developing it.

You already found some possible solutions and decided they were too expensive compared to the gain (otherwise you'd have implemented one of them.) It is very likely that there just isn't a solution cheap enough to be worth implementing.

If you settle for less than perfect results, there may be simple alternatives which at least prevent some undesirable effects. For example, you may empirically know that no superhero would flip through all pages, most would stop after 5 or 10. So you could get away with caching 50 results with almost no one noticing the cheat.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.