Podcastindex-org/web-ui

Performance improvement for displaying comments

Closed this issue · 10 comments

This is a leftover of #218.

I started doing some tests, looks feasible - @nathangathright , I might ask for some support with design related changes for this, as comments will show up progressively in the UI while they are loaded on the back-end.

If we wanted to add a reply button for each post, I’ve just discovered some URL methods that should make that very straightforward.

  1. Visitor clicks Reply on a given Mastodon post
  2. Site displays dialog requesting their home instance
  3. Visitor enters their instance URL
  4. Site saves that in localStorage
  5. Site redirects visitor to: https://${visitorInstance}/authorize_interaction?uri=${postURL}

If we wanted to add a Follow button, it’d be similar except:
https://${visitorInstance}/authorize_interaction?acct=${user@mastodon.instance}

@nathangathright , that's more a comment for #233

@ericpp that's an interesting alternative. I have mixed feelings, as this kid of hides the limitations of AP as a Client-to-Server API.
At the end, the standard is based on AP.
I need to do some investigation about that.
Anyway, if we use it, maybe it would be better if that is added to threadcap directly instead.
@johnspurlock-skymethod, I'd like to have your thoughts on this topic.

Threadcap actually includes Mastodon API code already - it falls back to it when the AP replies collection is unimplemented (cough Pleroma). I also tend to agree we should stick to AP whenever possible.

Note that when enumerating a thread with Threadcap, you need to provide a Cache implementation. This is so you can do smart server-side caching instead of doing everything on every client from scratch every time. Since this will differ from backend to backend it is up to you to provide an implementation of the interface (or use the InMemoryCache, which only lives for the duration of the calling isolate).

You might consider doing all of the comment fetching server-side, so results can be cached on your side and shared for subsequent calls. Completely up to you.

I sent a PR that implemented an optimization by pushing comments back to the UI as soon as threadcap loads their responses (just the list of responses, not body): #236

@ericpp , I'm still interested in using the Mastodon API as performance optimization, but since the index is kind of a "reference implementation", I'd prefer to keep it as close to AP as possible.

@dellagustin Makes sense to me. I agree that making this work with AP is the best option and ensures compatibility with all possible commenting systems.

This was implemented with #236, aside of adding server side (persistent?) caching, this is as good as it gets, so I'm closing the issue.