fuchsiaaaaaaaaaaaaaaaaa
mastodon api griping
i've mostly said this before, but it's so annoying how the mastodon timeline api's refuse to give you the tools to ensure a non-gappy timeline...
the websocket/sse streams just spit toots at you, with no context of ordering and if you missed anything, the pagination api uses link headers but only contain information about the chunk you just received, so you're totally blind on what ranges are continuous unless you make sure to request overlaps and merge based on that...
re: mastodon api griping
GoToSocial could absolutely improve things here, but there's no point because you're forced to accommodate mastodon's shitty design just because of market share, and then you're just doing lots of double work
re: mastodon api griping
@f0x I've implemented it similarly:
Whenever I fetch posts, I store the last post id.
Once the user scrolls to that, I render a load more button that will ask for all posts between the last one and the first I've already had in cache. Once the end of those posts is reached, I do the same, simply removing the button if nothing else is in between the posts I've already had cached.
I don't have the websocket stuff implemented at all right now because it alway irritates me when new posts come in without any user interaction, instead I've got a manual reload action that will ask for everything newer than the newest post I've got cached and repeat the above process.
It seems to work pretty well but I also don't really know how to check if I've missed any posts to be honest.
Pinafore seems to show the exact same posts that my app does, but that's just not proving that I missed something, not disproving it.
re: mastodon api griping
so I think the best i can do is:
- on load, request newest X toots from the timeline (up to the second toot in the stored historic timeline, so you can detect overlap)
- if there's no overlap, add a 'gap' element which renders as a triple dot/load more
- at the same time, open the websocket stream for new events. hope you didn't miss anything between the head of the timeline, and the first websocket event you receive. Just to be sure though, you could request the range between the websocket event and the stored timeline
- on websocket reconnect (or page reload), repeat this whole dance
- cry because all the added complexity in favor of never missing a cat pic in the timeline