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:
-
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.
-
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.
-
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.