Return to scroll position on reload

Greetings smart Tiddlywiki folk!

In my Kansas Railroad wiki, I have what can be a long list of railroads that I have in a scrollable window. I was wondering if there was an easy way to be able to return to the last viewed scroll position next time I load the wiki. Googling the web, I see that there are javascript and jquery solutions, but I don’t know how to do that within Tiddlywiki. Has anyone thought about this before or am I treading new ground? Is this even reasonable? Thanks in advance!

1 Like

This has being raised a number of times over the years, the first thing raised is if your wiki is structured into tiddlers, you can save the tiddler and have that reopened, but if you want to move to a position within a list, you need to define and capture the position, be it in a tiddler, and use a startup action OR using anchors on the url. It is possible to make use of links and anchors , but you will need to programmatically generate them.

  • Some smart developers may be able make a method to capture the scroll state of a list for use on reload.
  • If you designed the scroll system of a list to maintain a position you can use this on reload.
  • Another approach may be to capture what we may call the last focused railroad, then you would have a value to return to on reload. It may not remember the scroll position, but it could list the last focused railroad at the top.

There is a lot to this issue, so keep the conversation going until you can find an appropriate solution, but I recommend keeping an open mind to alternative approaches because some are a lot simpler than others to implement and maintain.

  • Unlike other websites, which move from one html page to another, tiddlywiki is one page with lots of internal navigation, that’s why using anchors, that exist in a pages “scope” are less straight forward than regular websites. If an anchor is not on the page you can’t jump to it.

I am not that smart developer, but my first thought was that the DynaView plugin might be part of the solution.

Yes I was thinking that to, but we want it to respond to the list items, not the tiddlers on screen.

Dynaview tracks elements with class="tc-dynaview-track-tiddler-when-visible" - despite the name, the elements don’t need to be tiddlers, though of course they could be.

Actually, now that I’m rereading the documentation, it looks like Dynaview may have this functionality right out of the box:

Scroll position preservation during refresh

Some recent browsers have a feature called “scroll anchoring” whereby they suppress the apparent scrolling that occurs when elements are inserted or removed above the current viewport. (See GitHub - WICG/ScrollAnchoring: Spec and explainer for the Scroll Anchoring web platform feature. for more details).

DynaView can optionally polyfill this behaviour for older browsers by setting the configuration tiddler $:/config/DynaView/PreserveScrollPosition to yes.

Startup scroll position restoration

Optionally, DynaView can store the current scroll position in local storage and restore it upon startup. Set the configuration tiddler $:/config/DynaView/RestoreScrollPositionAtStartup to yes.

Note that it is not recommended to use this setting at the same time as the “UpdateAddressBar” option.

Thanks to all. I will have to check out the Dynaview plugin.

After looking at the Dynaview plugin and reading its documentation, it appears to me that the scroll position functionality only works on the story river.I would like it to work on a tab in the sidebar. Am I reading the documentation incorrectly?

The example use of the dynaview shows the position in the sidebar?

Perhaps you could describe what you mean a little more deeply such as;

  • I may not be able to help, but it may assist others to help you.

You may need to combine a way to get to a tiddler, tab, window or view first, then restore the position.

I should have done this from the beginning. I’ve included a screenshot of my railroad wiki. On the right side, in the railroads tab of the sidebar, there is a div that lists the railroads that meet the criteria of the selectors above it. In this case, it is quite long. Being the lazy person that I am, I would like to not have to scroll to the position where I left off. Of course, I can always use my little navigator at the footer of the open tiddler to navigate through the list shown…

This is more of a curiousity question than it is a must have.

Jeremy just published an experiment, that contains a scrollable widget with a “bind” parameter.

The parameter expects a tiddler title, that will store the current scroll position of a scrollable widget.

Then open this empty version from the file and drag & drop import your existing wiki onto the emtpy.html

  • Import all your tiddlers
  • So you should get your wiki back.
  • Now modify your scrollable widget in the sidebar according to the docs
  • docs ScrollableWidget bind parameter
  • Scroll to a position
    - save the wiki
    - reload

The scroll position should be restored.

The PR is a draft at the moment. So it will not be part of the TW prerelease.

The GH PR is at: Allow scrollable widget to bind scroll position to a tiddler by Jermolene · Pull Request #7649 · Jermolene/TiddlyWiki5 · GitHub

Thank you @pmario, I was just about to make a post about the experiment but you beat me to it. It’s just an idea, there may be a better way of doing it (I think it might be worth exploring a more generic mechanism for binding DOM node attributes to tiddler fields).

1 Like

Thanks @jeremyruston and @pmario. This works pretty much exactly as I had visualized. It was also very easy to setup. I used $:/state/my-scroll-position to store the scroll position so that they dirty indicator wouldn’t turn red when I scrolled. I’ve only played with it a short time so not sure if there are any issues with it other than the scrolling is less responsive than without the scrollable widget. I’m assuming that this is because each time I scroll, it has to store the scroll position in the fields of the binding tiddler.

Edit: question - is there a way that the fields of the binding tiddler could only be written to upon a save of the wiki to increase the performance of the scrolling? I guess that would require some other temporary storage mechanism for the scroll position though.

1 Like

That’s right. I plan to improve things by debouncing the updates so that they are not generated so frequently. As long as the update to the binding tiddler isn’t triggering an expensive refresh the performance should be reasonable once that’s done.

Thanks @jeremyruston. I really appreciate this experiement. I hope to see this included in the next release.