Topic display UI needs pagination

[kollivier]

Summary

If a topic contains a lot of nodes, it can take an inordinate amount of time to load and possibly time out. We should use pagination + infinite scrolling to avoid this scenario.

Category

BUG

(Declaring bug for the timeout problem, which breaks editing.)

Usage Details

• Browser: Latest Chrome (OS X)
• Channel: https://studio.learningequality.org/channels/5357e52581c3567da4f56d56badfeac7/edit
• Topic/Content Item: Root topic

How to reproduce

1. Click on the link above, wait a while...

Real-life consequences (anything community should be aware of, for instance how it affects end users)

Sometimes channels will not load properly, other times they will take significant time. Either way it provides a degraded UX.

[jayoshih]

I would advocate for infinite scrolling as it seems tricky to add pagination without making the interface feel cluttered

[jayoshih]

Short term, there is some chunking logic for fetching nodes. We can prevent some of the cases by decreasing the size: https://github.com/learningequality/studio/blob/develop/contentcuration/contentcuration/static/js/edit_channel/models.js#L370

[kollivier]

That may actually worsen the problem, since a large part of our performance hit for many API calls is the latency of setting up the database connection. The less calls we make the better, until we implement connection pooling.

That being said, if we're already passing an ID list, infinite scrolling would just mean calling it for the first 50 alone and loading that, then waiting on scrolling events to fire to fetch the next 50.

[radinamatic]

Infinite scrolling has significant accessibility issues, and if in any way possible, pagination would be preferred.

[rtibbles]

I don't think we need to implement infinite scroll, but we should also avoid page number based pagination (and prefer next and previous pagination instead) for performance reasons and to reduce interface clutter.