Can you make page states persistent during a user session?

I am starting to use custom states more. On one page I have filters to a query tool that I would like to have persist even if a user browses around on the site. They are the main pages on the site so we expect they will be returning to these pages often and would prefer this.

What are some methods to do this? It would seem logical to allow this scope to simply be enabled somewhere on the site as a setting. Persist custom states yes/no.

You can pass the states from page to page as url parameters. In the Navigation action you can send alternate data as a url parameter. Then on each page just on the page is loaded workflow assign the values of the custom states from the url if those parameters exist.

1 Like

Yes that would work. However, only while the window is open. I would like to make this app appear smart, as these are sophisticated query tools and people will be configuring them various ways. I am coding some of the options into the user db for now, but I didn’t want to put all of the search conditions in there, as there is so far about 10 form controls for the search… and that is expanding to possibly 20-30 and there is multiple of these query tools (one for each major type of content in the site)…

Essentially, is there any way to use the session scope in Bubble? So far my searches on this haven’t returned much info.

Hey @mc3digital, in web app development, persistent states – during a session or even between sessions – can be made persistent using various types of browser storage (more on this below).

Custom states are Bubble’s version of local variables that we might define in JavaScript if we were using code-based web development. As such, they are held in memory and, of course, only exist in the context of the current page. That is, they are created in the page and when we close or leave the page, they no longer exist.

Of course, data can be “passed” from one page to another via URL parameters (querystring parameters) or by having objects (Things, or some field(s) on a Thing) in our database that represent states that should persist in our app. Bubble natively supports both of those.

Browser storage, which the Bubble app itself takes advantage of, but doesn’t give Bubble developers a native way of accessing, is a third way to make data persist either within or between browser sessions.

There are 3 basic types of browser storage in use in modern web apps today and these are:

  1. sessionStorage: Data held in session storage persists for the duration of a given session. A session in this context means a browser tab. Data held in sessionStorage will survive a page refresh or a social login/OAuth workflow, but is cleared when the session ends (e.g., when that tab is closed, the site is left, etc.). Session storage can only hold string (text) values and we stringify values before storing them there and parse them when we read them back (using JSONstringify() and JSONparse() respectively). Data is stored as key/value pairs. Note that two different tabs in a browser open to the same app do not share sessionStorage – because those are different sessions – and the values are unique to each tab.

  2. localStorage: Data held in local storage persists across sessions in the same browser. So, a user can do something on your app at one time and then come back later and those data stored in localStorage could be accessed. For example, this can be used to store preferences, favorites, in progress shopping carts, etc. An app open in two different tabs in a browser will share localStorage and if localStorage is updated in one tab, other tabs can know if a given key/value pair has been updated, enabling a crude form of cross-tab communication. Local storage is otherwise identical to session storage for the most part.

  3. IndexedDB storage: Modern browsers support a front-end database via the IndexedDB API, which is actually very much like Bubble’s own backend database. It’s more sophisticated than session/localStorage and is intended for storing larger volumes of structured data. The API is very complex and certain libraries (like localForage) are often used to provide simpler key/value pair storage using IndexedDB as the storage medium. Data in IndexedDB does not have to be stringified (it stores actual JavaScript objects) and unlike session/localStorage has an asynchronous interface.

You can learn more about browser storage (and how you might use it in Bubble) in my videos and posts about my Floppy plugin, which supports all 3 of the aforementioned browser storage formats:

Note that in ye olden days cookies were sometimes used to store small amounts of data, but this is not the appropriate method today as it has privacy, security, performance, and capacity limitations that browser storage was designed to eliminate.

Also, it should be noted that there are lots of crummy implementations of the sessionStorage and localStorage interfaces (these are fairly simple APIs and easy to implement for a novice plugin developer, but developing robust and truly useful Bubble plugins requires a substantial amount of effort) and caveat emptor applies.


Wow, thanks for dropping such a detailed reply here. I think session storage would work in most cases here as at most I have a string of texts which can be stored as a string. I am going to keep this option in mind.

Side note - Saw reference to caching API data in the loom video, which was a question I was planning to ask about soon. Dealing with a slow loading API and a few calls that are pointless to pull over and over as the results don’t change but maybe twice a year. For this one though, I would want to cache it at the application level (for all users).

This topic was automatically closed after 70 days. New replies are no longer allowed.