Another Beginner thing: learning “custom state” was a game-changer; feels like I gained a new superpower. I’m putting most of my custom states on the Page element, so I can find them easily in workflows and from other elements, etc.
Two Questions:
Are there some ‘good’ practices for using custom states? (I know how to use them, just not whether there are things I should keep in mind).
Is there a simple / ‘good’ way to access custom state across different pages? Can I do something like declare a js variable somewhere and then access it as a ‘custom state’ everywhere in my app? Or is it still better off using the database even for temporary user state data…
Thanks.
I am thoroughly prepared to be stoned and vilified for this but…
I vote for database.
Using global variables is akin to hating puppies for some developers. Personally, I still think they have their place since you do often need data to persist for a certain lifespan.
I know there are bubble plug-ins to write out cookies, but to be honest if I have something that I need to persist for the duration of a transaction, and I know that the user may not necessarily complete the transaction immediately and/or on the same device, I write out what I need to the db.
I will readily admit that this may not be a “best practice”, but it works.
BTW: what type of info do you need to both write out to a custom state AND pass said info across different pages?
Writing cookies isn’t really the correct way, but using some variety of browser storage isn’t a bad way to go. (It’s the tool that we have.)
Yeah, if you need something to persist across not just the current session but also across different devices, the only way to do that is via the database.
But one doesn’t always need the second part. If one just wants to preserve some data across browser sessions (or simply within the current session), use some form of browser storage. (SHAMELESS PLUG: Floppy)
But to the OP’s question:
Any data held in memory in a page (e.g., in a custom state or a custom state-like thing like a plugin element’s outputs) goes away across page loads.
So, you can pass the value to another page via the querystring (i.e., “send data to a page”, which is a pretty terrible misnomer), or you can write it to browser storage (using a non-crappy storage plugin like [SHAMELESS PLUG] Floppy).
(Floppy supports all three varieties of universally-supported browser storage - session, local, and IndexedDB - depending upon what you need/desire to do.)
Granted, @firstfifteensoftware, Bubble’s lack of support for objects beyond Things makes database storage attractive (for Things), but there are many cases where one would desire to store some bits of data without having to keep passing them along from page to page via querystring parameters (which won’t survive the session anyway) or by generating cruft in one’s database and having to manage removal of it once done.
I suspect a write to the DB might be my answer as well.
FYI – the info I need to (possibly) pass to different pages is just user experience-y state stuff like current choices… so when they go to a new page, that part of their context is still available to my ‘code’ on that page. Or for some game-like activities, their in-progress “score” needs to go to the next page. This MIGHT not matter because I’m still weighing whether the whole SPA is what I should be doing, but still… I’m new to all this, though thank-you!
Much appreciation for your willingness to shameless plug
Going to check out Floppy!
I’m still so new to both Bubble and web apps in general, so my being a dinosaur old-skool desktop Java programmer is proving a pretty useless background. Still getting my brain around not having everything just BE THERE… I expect my state variables to be kicking back on beach chairs sipping margaritas somewhere on the heap regardless of what my app is doing.
It’s a fun challenge though and I’m grateful that there are people like you crafting “non-crappy storage plug-ins”