I'm using lemmy-js-client for app development. I want to render comments in the nested form (like normal people do).
The problem is, the lemmy backend spits out comment lists in a fashion that is unfriendly for nested rendering. Why? It outputs comments whose paths are like follows (for example):
0.1.2.3.4
0.1.2.1
0.1.2.3.4.5
0.1.3.1.5
0.1
Let's say the limit that I've set here is 10. Many a times, the parent comments of the comments in the page are out of the page.
For example, let's say I asked lemmy for comments for a given post. It gives me an output like above. There are many children comments here on page 1 (like 0.1.2.1, 0.1.2.3.4 and so on). Their parent (0.1.2) is NOT on this page. It is on the page that follows.
Hence, I would need to do client side bs to get the correct parent comments.
What is your approach for doing the above?
This is what I have settled for now unfortunately. I fetch all the comments under a post and then convert them in my nested form. This means, that my app doesn't paginate. This thus results in really slow loading times for posts with more comments. The more comments a post has, the slower they will load. This sucks.
I tried other ways, mind you. While implementing pagination, I simply removed orphan comments when on a given page. If the user decided to go to page 2 (simply by scrolling), suddenly, these orphan comments would not be orphans anymore due to them finding their parent comments. This in turn, fucked with my ui completely (which was obvious), thus making the list randomly scroll like crazy. This was a really shitty experience for the user.
Sooooo what have you guys done? How have you handled the situation?
I use
maxDepthrather thanlimit.That gets all the top-level comments and only the child comments
maxDepthdeep. If a comment has children that aren't shown, there will be a "load more" button below to fetch and render them.Ohhhhhh... That's actually quite smart. However, there's a tradeoff between convenience (the fact that users would need to do a lot of button mashing to see comments that aren't that deep) and efficiency. Do your users complain because of this or are they fine with it?
When clicking to load more, I use a maxDepth of 5 to fetch the comment's children (the depth is based on the parent comment ID passed to the API call, so it's 5 more layers from there rather than from the root). I haven't had any complains, but it would also be easy to make those additional fetches configurable. If I do get complaints, that's probably going to be the way I change it.
Yeah, it's a trade off. I tried setting maxDepth much higher on the initial fetch, but it takes a lot longer to load the comments when there are 100 or more or if there are deep, nested threads. I'm also not sure how
maxDepthandlimitinteract when used at the same time. I want to say depth takes precedence, but I'm not 100% sure.The only complication with using that method is when direct-linking to a very deep comment. If the post page is called with a comment thread param, I set maxDepth to 15 which works for most cases. Very rarely is that not deep enough, but when that happens, the linked comment doesn't show until you "show more" to its level. It's a known edge case I haven't fully addressed yet.
Naah I think maxDepth just works like a filter. The limit is there always for pagination. So if you say "limit:20" and "maxDepth: 4", it will give you the first page with 20 items on it, none of which are > 4 units deep.
Oof. Ideally all of this should be server side code, not client side.
I think I'll just stick with the "downloading all comments" thing for now. I'm really bored with working on this one thing for so many days now lol. I want to get more features done. The best way to do this is doing it server side (in a way that parent comments come always before children comments). I think I'll try doing that after all basic features have been implemented in my frontend.
Either ways I am going to have to make some changes to the backend (I'm thinking of getting stuff like push notifications in), so it won't be that unholy to consider this.