Ask HN:How do you structure comment trees to handle pagination, sort, recursion?
I've got basic lazy loading implemented. Click expand on comment, it API calls for replies. It will show load more if there are more to load.
Contrast this with something like hackernews, which loads many layers at once. I can conceptualize a recursive way to retrieve the whole tree, but...
Supabase limits to 1000 rows returned; while I have not hit those limits yet, future proofing may be a good practice. Or simply limiting in general.
But limiting, paginating, and sorting all run into hurdles with a recursive call of arbitrary depth using one API call.
If the limit truncates one comment's replies, do I just need to have a column counting direct replies to compare to? Over fetching doesn't quite work here, does it?
Is it possible to sort within the recursive query such that if one of them still needs to load more, the order will be correct?
For ex, if my limit is 100 comments, there are interesting cases where it runs out breadth first or depth first.
I've been informed that I'm currently implementing something called adjacency list, but I'm not sure how I should implement eager loading of a few layers
See also the nested set representation of trees which makes it fast to get subtrees.
[1] https://github.com/etrepat/baum [2] https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem...