remember list scroll positon

[oskarrough]

Hi, first of all thank you for your work here. Much appreciated!

The editing experience would be much better if it was possible to edit a post without loosing your scroll positions in the post list. Especially since the post list is using infinite scrolling.

I propose either to open the edit view on top or remove infinite scrolling and list all posts by default.

[ideag]

hi, @oskarrough. Thank you for your input, it is also much appreciated!

Loading all posts to the list is not too practical, as there are instances there that would mean several thousands of posts being loaded. Making editor view modal is also something I'd prefer not to do.

I have another approach in mind for this functionality, though - storing scroll positions in localStorage and then loading them back if user comes back from editor screen. I modified your issue name accordingly. I hope to have this in the next update.

[oskarrough]

Cool. But say you've scrolled so much that infinite scrolling triggered five times. When you edit, you can save this scrollTop but how would you make sure the same posts are still loaded?

[ideag]

@oskarrough I'd save current item ID, not scroll top. Then I'd look for list item with the saved ID. If there isn't one (it wasn't loaded yet), I'd trigger infinite scroll once, look for id again. If ID is still not present, repeat, until ID shows up.

Of course, I need safeguards for situations where saved ID is not available anymore (post deleted, etc.), but this is the general idea.

[ideag]

@oskarrough I pushed changes for this functionality to master of this repo. You can try it out by downloading https://github.com/ideag/gust/archive/master.zip and installing it.

[oskarrough]

Hey, thank you very much! It works but only for the first post you edit. If you edit another one directly after it won't scroll.

[ideag]

Will look into it.

[ideag]

Hmm, everything seems to be working in my eyes. Let me explain how this works.

1. When user goes to editor view, the ID of that post/page is stored. Posts and pages are separate, so one ID per post type.
2. When user comes to list view, Gust checks for stored ID, and, if there is one, scrolls to that post. The ID is deleted from local storage, so if user clicks on list view again, it comes back to the beginning of the list. This is expected behavior, aimed to users who want to go back to the top of the list.

so in editor view, Gust always stores current ID, in list view - the ID is retrieved, scrolled to and then reset. And this is independent for different post types.