Howto suspend background page refreshes when a modal is open?

Developers
#1

Does anyone know if it’s possible to suspend DOM refreshes of the wiki DOM that is shown in the background when a modal is open and interacted with?

Sometimes, like when you have the More → Explorer sidebar open, things can really slow down. Normally, it’s just a single click to activate a different sidebar tab to speed things up again. But with a modal open, you’d have to close the modal, click another sidebar tab, reopen the modal, and possibly retrace other steps you did there.

Since the background is dimmed, hardly visible, and cannot be interacted with anyway, I wouldn’t mind if the refresh processing for it was halted while the modal is shown. In this discussion it seemed to me that modal refreshing is processed differently, so maybe this can be leveraged here?

Even if not fully automatic, I could imagine setting a tiddler to some value ($action-setfield) while calling the modal, and then unsetting it when closing the modal. While the tiddler is set, refreshing is paused (maybe by temporarily activating a check for open modals at the top of refresh processing).
There is some danger to that, as wrong code could make the wiki unresponsive, but I’m not proposing a general change to the core, but only a custom thing for me.

Have a nice day
Yaisog

#2

You can set the state tiddler $:/state/sidebar–595412856 to $:/core/ui/SideBar/Open So it will show the Open tab.

You can also clear the $:/StoryList - list field. So if no tiddlers are shown, there is nothing to update.

When you close the modal, you can restore the stuff. … done … everything works out of the box. No changes needed

#3

Hi Mario, that’s a pretty clever idea. :nerd_face:

I’ll change the details a bit (I’ll set the sidebar to an empty transclusion, and I’ll fold instead of close), but that is secondary.

BTW, currently I’m using a “hack” which exploits that modals don’t respect the volatile condition (at least I think they don’t). So, by only changing $:/temp/volatile tiddlers in the modal interaction, everything remains very responsive no matter how complicated the background wiki is – that was the reasoning behind the OP. The refresh times this way are 2–3 times faster still than just closing everything in the background. At least until the deferred refresh fires. Neither approach feels laggy, though.

And with your proposal I don’t need to be afraid that modals will get “fixed” one day – Jeremy said somewhere that he would like to integrate them into the main refresh mechanism at some point, which would likely kill my “hack”.

Have a nice day
Yaisog

PS: Do you know how to trigger actions when the modal is closed by clicking outside it (with mask-closable set to yes)? Starting actions when opening the modal is not a problem, of course…

#4

Hi @Yaisog using volatile tiddlers is a great trick if it can work for you. But generally I think you’re running into exactly the issues with modals that have driven the conclusion that it needs to be re-engineered along the lines we have discussed.

#5

@jeremyruston: Also, I don’t wanna be the one that’s blocking the re-engineering when the time comes, only because it’ll break my code. So I’ll be looking into what Mario suggested.

Maybe I can replace the whole ViewTemplate with just a blank screen…?

It might be cool, though, if regular page refreshing could be completely suppressed while modals are open. Maybe there’s a way to slip this in in the process of modal optimization…

Oh, might you know if there is a way to trigger actions on closing the modal by clicking outside it, as per my P.S. above?

#6

Hi @Yaisog

If we moved modals into wikitext then it would be possible to wrap code such that it would only be displayed if a modal were not displayed. That’s not possible with the current implementation.

Do you mean globally, or as an option? Once modals are in wikitext in the main widget tree then that would be much harder; it would be equivalent to the ability to restrict refresh to only occur within a given subtree of the widget tree.

The ability to dismiss modals in that way was added fairly recently as a PR. You can use git blame to find it in Allow click outside to close (layout) switchers' modal by linonetwo · Pull Request #7072 · Jermolene/TiddlyWiki5 · GitHub

[EDITED to remove a suggestion about moving these discussions to GitHub; on reflection, it can be hard to tell which forum is best for which questions, so perhaps it is best addressed by clearer guidance]

#7

Hmmm, I see. Well, the current implementation works for me. When changes are implemented, we’ll see what works then. I think it might be a good idea to set some state tiddler already in the current implementation. Similar to popups, but not (yet) used for anything, just reflecting the presence of one or more modals.

I think I could make this work with an adaptation of Saq’s refresh widget from here. One could wrap it around the view template and tie it to the modal state tiddler (if there was one). I’m not sure that something like this is of general interest and needs to be in the core, though (the refresh thingy, not the state tiddler)…

If I was going to do something about it now, I would probably add another field to the modal tiddler which takes the name of a state tiddler, which is then created when the modal is drawn and deleted when it is closed, like I wrote above. Not sure if I want to change another core tiddler that I have to track later…