Journal pagination order

[upsuper]

In #2058 an automatic pagination mechanism was implemented for journal to improve perceived performance with journal page while keeping all its functionality virtually the same.

However, it was implemented in a way that only loads entries in the date descendant order for simplicity reason, and review comments from @yagebu ([1], [2]) want to see it's implemented also for date ascendant order. I'd like to discuss about the high level design before pouring too much time in implementation.

Challenge

The main challenge here is that the order is currently stored locally in the client side, and all sorting is done there. This information is never passed to the server side.

We may be able to pass the order in followup requests initiated from fetchAllPages. But this part actually doesn't matter much. Even if the server side only supports date descendant, we can pretty much just reverse the fetching order as well as fetched result at client side, and do some smart insertion to make it work seamlessly as date ascendant order.

However, the initial list of entries without page= would still be vastly wrong.

Potential solutions

There are three possible easy solutions for it:

First, give up the initial list. All entries should be loaded through paginated requests when pagination is enabled. This means the initial page load would come with no data, slows down initial viewable data by another request.

Second, generate the initial list items from both the start and the end of the journal, e.g. 500 first and 500 last entries, so that regardless of the order, the initial list always contains the foremost entries to be shown. This would complicate the addition of fetched entries. We need either communicate where the mid-point is, or apply sorting unconditionally when new entries are inserted, which can be quite slow. This also complicates the pagination algorithm.

Third, have the initial page using date descendant, but subsequently fetch data based on the reverse order if the local order is date ascendant. The up side is its complexity is more manageable than the second solution and it doesn't give up the initial list for date descendant as in the first solution, but the down side is there will still be a moment where the list is wrong for date ascendant order.

Discussion

My main question is actually, does it really worth this complexity? How much would a user with a large amount of entries worth pagination really want to see the journal ordered in date ascendant order so that they can always see the earliest entries first? I'd strongly doubt.

[yagebu]

First, give up the initial list. All entries should be loaded through paginated requests when pagination is enabled. This means the initial page load would come with no data, slows down initial viewable data by another request.

This is implemented in #2138. With the composition of the rendered journal parts being driven from the frontend, adding an option to have different sort orders was pretty trivial to do.