Avoiding page reload when switching tabs

[valankar]

First Check

• I added a very descriptive title here.
• I have checked the FAQs for a similar question and didn't find it.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the NiceGUI documentation, with the integrated search.
• I already searched online "How to X in NiceGUI" and didn't find any information.

Example Code

N/A

Description

When I switch from a NiceGUI app to another tab in the browser, then switch back, the page sometimes reloads. This happens much more frequently on Safari/IOS. Is there some reason the page needs to reload or something that triggers it?

Many times I will be filling in a form on my NiceGUI app, have to switch to another tab/app, then come back, and the page reloads resetting everything I entered in the form.

NiceGUI Version

2.16.1

Python Version

3.12.10

Browser

Safari, Edge

Operating System

Windows

Additional Context

No response

[evnchn]

Hello @valankar. Let's learn more about NiceGUI internals.

On each NiceGUI server, there are Client instances, which follows the lifetime of the NiceGUI pages to provide interactivity.

• In the "auto-index page" (the stuff outside any @ui.page decorators): A single Client serves all connections, never despawns, and has a shared state
• In the page builder functions (the stuff inside @ui.page decorators): For each connection, a new Client is created for a separate state, but that client despawns after 3 seconds of no connection (default configurable in reconnect_timeout in ui.run(..., reconnect_timeout=30) or in @ui.page(..., reconnect_timeout=30))

In this case, you are under the second situation. Since a shared state is useless for a form, there are two things you can reasonably do:

• Increase the reconnect_timeout (short-term solution)
• Store the user's intermediate entry into storage (https://nicegui.io/documentation/storage), and then on page load, it is restored from storage, making the reload transparent and non-impactful to the user

[valankar]

Thanks for the info. Regarding storage, is it really intended to use storage after every character is pressed in a form? It seems excessive just to keep a static page from reloading.

Also, why is 3 seconds chosen by default? It seems arbitrary. I get quite a bit of timeouts connecting seemingly due to going over 3 seconds.

[evnchn]

It looks like app.storgae.tab is what you want to use, if you want to avoid frequent writing to the disk.

https://nicegui.io/documentation/storage#storing_data_per_browser_tab

It is implemented as below:

nicegui/nicegui/storage.py

Lines 149 to 161 in 42d24d4

	@property
	def tab(self) -> observables.ObservableDict:
	"""A volatile storage that is only kept during the current tab session."""
	if self._is_in_auto_index_context():
	raise RuntimeError('app.storage.tab can only be used with page builder functions '
	'(https://nicegui.io/documentation/page)')
	client = context.client
	if not client.has_socket_connection:
	raise RuntimeError('app.storage.tab can only be used with a client connection; '
	'see https://nicegui.io/documentation/page#wait_for_client_connection to await it')
	assert client.tab_id is not None
	assert client.tab_id in self._tabs, f'tab storage for {client.tab_id} should be created before accessing it'
	return self._tabs[client.tab_id]

Since it's a dictionary at the end of the day, it doesn't get written to file, and no disk access is involved.

---

Also, I need to emphasize, that what I am suggesting is not "to keep a static page from reloading", but rather "to make it so that, even if the page did reload, it is seamless"

I can't tell you exactly why 3 seconds was chosen, but here's my two cents:

• Allocating a client takes up some memory. If we increase the connection timeout, we could make it easier to DoS attack the server
• Was introduced in this commit: 0c3e522 (and subsequently was moved around but the default of 3 seconds stayed the same.

[mummynobbit]

I think the modern browsers may suspend an inactive tab, in that case NiceGUI will consider the websocket connection as hung and will recreate it whenever the tab becomes active again.
I'm not sure if it's possible to get a notification from the browser before the tab is suspended, and then even if it is, the user may close the inactive tab, and what should NiceGUI do in that case?

[valankar]

Using storage for this does not really make sense to me. The problem is not only with forms, it is with any page. If I have a page with many graphs (e.g. Plotly), they unnecessarily reload when I switch tabs for a few seconds. There is really no reason for them to reload like that.

If increasing the connection timeout here is suggested solution here, I'll try that.

[amks1]

Having used NiceGUI in production for the past 2 years or so, this is the problem that most bothers me.

1. Disconnections due to Slow networks: As mentioned by OP, this breaks the user experience particularly in data entry applications. The user may be in the middle of typing something, and the page suddenly resets. All entered data is lost.
2. Mobile browsers: On Android (and presumably on iOS), when pressing the home button from the browser, all websocket connections are killed. So any page that keeps some kind of state is immediately refreshed on next load.

Could the local storage solution be built into nicegui that automatically restores all state on reconnect?

[falkoschindler]

This might be related to #2410, where @rodja proposed to implement a service worker keeping the connection alive in the background.

[amks1]

The approach for that feature request is to run background threads in the client to keep connected to the server to prevent system dialogs from breaking the communication.

That won't solve the problem that's being discussed here, because:

1. Slow networks would cause the background thread also to lose connection to the server.
2. Mobile OSes (maybe even MacOS like OP mentioned) would kill background threads too when one presses the home button/ switches to another tab.

At the end of the day, background threads are also at the mercy of the browser and OS, so if we want to solve the underlying problem we have to implement a way to pause the current state when the connection is broken, and pick it up seamlessly when it resumes.

[falkoschindler]

I see. My recommendation would be

1. to increase the reconnect_timeout (to a few minutes maybe), and
2. to bind inputs to user storage so that values can be restored if the page still reloads.

Edit: I just noticed that this is basically what @evnchn said.