[Feature Request] "Infinite scroll" (load more) on large posts or posts over certain size (1000s of comments)

[supernovae]

Pitch

Add infinite scroll/pagination to posts containing thousands of responses to help reduce load time and response cost of popular posts. I've had a few posts get 1000s of replies and it can take a while - especially for a mobile client to download. Pagination/scrolling would also smooth out resource utilization into smaller requests.

Motivation

I have had several posts get 100s if not 1000s of replies and it can be difficult to stay ahead of demand on loading these large posts. An "infinite scroll" or "load more" pagination inside these large posts so you don't have to wait for the entire object to download to read/reply would improve user and operator experience.

[renchap]

Similar to #20345 #20421

[nemobis]

Pagination is good. Infinite scroll is evil. I'm not sure what's being asked here.

[Gargron]

What’s being asked is to not return an entire thread in the same API request but to support paginating it. It’s a non-trivial question for a tree structure, expertise is welcome.

[kirkbrauer]

I have some experience with this in GraphQL APIs. It appears that the emerging standard is opaque, cursor-based pagination. Facebook’s Graph API implements a version of this see here.

This allows for an infinite scroll for very long lists of data by just using the last cursor of the previous page to move forward in the list. The cursors are opaque because usually they’re base64-encoded entity IDs or some other type of identifier that we can sort by in the database. This lets the underlying implementation to be changed without affecting clients. Clients can also specify a limit to how many items they want per page so they can make their UI more pleasing for different use cases.

[renchap]

The issue here is that this is not a "simple" list of contiguous statuses to load progressively, but a tree of replies.

First Status
  | First direct reply
    | Second level reply
    | Another second level reply
      | Third level reply
  | Second direct reply

So you probably want something like:

• on first load, load the N first direct replies, and their M first replies
• then you have a button to load more direct replies, or buttons to load replies to the first order replies you clicked on
• what about 2nd level replies and further? When do you load them? How do you paginate?

[kirkbrauer]

@renchap I still think taking a page from the graph APIs is a good idea for this scenario. A client could specify how deep it wants to load replies initially and how many for each of those threads. If the user goes deeper into the nested replies, we would simply load more by executing another request for the replies of A.

Within each of the threads we could use cursor pagination, which would give the option to specify something like: "First X replies of A after cursor Y." A client could use the scroll position to determine which parent to expand and when to go to the next page for that thread. If it encounters another nested list, we just have to issue another request for the first X replies for the given thread.

[santiagocezar]

Hit this after Gargron's recent toot. The API response for the status is >5MB uncompressed and took 18 seconds to load on fosstodon.org, which surpasses the 10 second timeout on the Android app.

I thought about some solutions and I'll be using this example thread:

A: [thing] is cool
| B: [other thing] is cooler
| | C: i don't use [other thing] because [reason]
| | | A: yeah that's my reason too
| | | | F: can't agree more
| | | | | G: why
| | D: though [other thing] is not the same
| | | B: it works for me
| | | F: this is true
| | | G: why
| F: so much this
| | G: care to explain?

I thought about only loading the longest/oldest branch of the tree for each direct reply. That would probably lower the visibility of 2nd level comments and below, but it'll also make reading threads a lot easier by only showing one continuous discussion. It would look something like this in a flat structure:

A: [thing] is cool
┌ B: [other thing] is cooler
│ C: i don't use [other thing] because [reason]
│ A: yeah that's my reason too
│ F: can't agree more
│ G: why
└ ...show other replies to B
┌ F: so much this
└ G: care to explain?

Another possible solution would be implementing something like Reddit comments: tree structure, threads get cutoff at a certain depth and some replies are hidden if they have too many siblings.

[trwnh]

support paginating it. It’s a non-trivial question for a tree structure, expertise is welcome.

for tree structures specifically, i'd point to how reddit handles their nested contexts. there is a context parameter that controls how many comments to go up the branch. you would want to allow pagination in two dimensions, effectively, and have a "show more replies" indicator when replies exist beyond a certain boundary.

the alternative is to "flatten the tree" and instead consider the thread to be a context or conversation, like on traditional forums. all posts belong to a thread. paginate the thread chronologically and treat replies as metadata instead of as a tree structure. you can still fetch ancestors for a post by following the reply chain up. using a depth parameter like reddit's context would work well here.

in either case, you can also order pages by an alternative algorithm -- reddit uses "best" (most upvoted), "new" (strict chronology), "hot" (a formula that favors both upvotes and recency), and "controversial" (which doesn't make sense without downvotes or dislikes). if you know the depth of every single branch ahead-of-time, you can also sort by deepest-first.

[brendanjones]

@supernovae if this is done then I think it also solves #20345 (which can then be closed)?

[renchap]

This is not done (but is on the roadmap).

I suspect that @supernovae closed it because they do not want to be involved with Mastodon anymore.