Next/previous button on single dweet pages

[joeytwiddle]

I would quite like a next/previous button on the single dweet page.

If this was done using pushState and pre-caching, it could potentially be fast and lighter on resources than the feed.

Disadvantage: If it's not clear which feed the user is browsing, then this feature will be limited to navigating the dweets in the order they were created. (Obviously, it will need to skip deleted dweets too.)

[lionleaf]

Interesting idea. I think the main issue is exactly what you mentioned; what ordering to use?

Would hotkeys that jump to the next dweet down the feed, as in #50 , be sufficient for the use case you want? In my case jumping to the next with a keystroke would be the main reason to have "next" on the direct dweet page

(Yes, if you're trying to use it as a way to escape loading a long feed, that doesn't help. But in my opinion we should rather make the long feed not eat all resources when you get far down)

[joeytwiddle]

My main goal is to make it as lightweight and fast as possible. (The convenience of having a navigation between siblings is only a minor goal.)

In theory we could reuse the one iframe and one canvas, so loading the next dweet could be super fast, just like pasting new code into the edit box is now. (Plus a few DOM updates for the dweet card metadata.)

But you are right, the ordering problem limits the usefulness of this feature.

We can certainly try to make the feed pages more efficient first. That might lessen the need for this feature.

Perhaps we can reframe this idea:

I want to be able to optionally limit the normal feed pages to keep only a few dweets in the DOM at a time. (At the extreme, only 1.) This could be a parameter, so we could also choose to keep 20 dweets in the DOM at one time.

I will close this and open an issue for improving the feeds. #393