Is the airdev method of Popup hidden variables still useful? Like for navigating between tabs in a page? Or is page paths more than enough? Who still uses the Popup hidden variables method?
You can user custom states, hidden variables, url parameters, or DB fields to store the āstatesā or temporary values that you page needs. Each option has its usefulness and pros & cons.
Gotcha, but what are the benefits of using the popup hidden variables method vs just using page paths?
You can bookmark a page path.
URL path are mainly for navigation while hidden variables can store objects, lists, be resetted, and so much more through workflows
Hey, I was wondering if using the hidden variables popup method slows down the loading time of a page. For example, if I have a hidden variable in a reusable element on a page, and both the page and the reusable element have their own hidden variables popups, does this make the app slower? If it does slow things down, is there another way to get the same benefits without affecting the loading time? Thank you!
Donāt store variables (states) in popups. Use floating groups instead. Storing in popups can cause issues.
I think itās a pretty legacy technique now, there very rarely seems to be any benefit to hidden variables while having a few downsides, custom states were built for a lot of the things people used to use hidden variables for. I just find them frequently confusing for other developers and debugging, and commonly slowing down load times if people are daisy-chaining groups or RGs together to then use as a data source.
Custom states canāt be dynamic (easily)
Wow, I didnāt realize It was a legacy technique. I got it from Matt Nearyās ThinkitBuildit course, but I guess one or more of his topics in the course are outdated.
Are there any courses/bootcamps that are updated as Bubble continues to evolve/change?
Or what do you read to stay updated with best Bubble practices?
It is not a legacy technique, it still has itās purpose but @ihsanzainal84 is correct to state to store them in floating group and not popup, just make sure floating group is set to float beneath the page.
Custom states were around at the time the use of hidden variables was first setup, so custom states definitely were not purpose built to eliminate use of hidden variables.
The main difference now, and then, is that people have become more aware of how to use them more effectively.
use properties on resuable and pass the values through from the hidden variables to the resuable through properties.
The forum. This is where you will find full time developers sharing their techniques and hashing out what is better, more efficient or optimal way of doing certain things.
Thanks for your answers. I have a few more questions.
Why can storing variables in popups cause issues @ihsanzainal84? Are you talking about loading time problems? Also, why are floating groups better for storing hidden variables than popups?
As @georgecollier mentioned, we use hidden variables in popups because custom states canāt easily be dynamic. We also need to set conditions, and we canāt do that right now with just custom states and reusable item properties.
Iām currently reorganizing our our app, and I need help with our hidden variables popups. Iām looking for a balance between an efficient app and a well-organized one. Right now, we use hidden variables popups, but Iām considering changing that.
Hereās an example from our application of how we use the Hidden Variables popup. We store a list of a specific data type, which weāll call Post. Based on the user role, we want to display different data sources.
For example:
- Admins see all posts.
- Teachers see all the posts from their classes.
- Students will only see posts from the class they are in.
So we have a repeating group that we use as a variable called posts
with the content type set to Post. This variable has three conditionals for each user role that set the data source to a Do a search for, and we reference this data source in a table for example. Of course, the posts
variable is inside a hidden variables popup. Still, it seems to slow down the application, and Iām sure there are better methods to achieve what weāre doing now.
Also, how do you decide and organize who can perform certain actions? For example, again taking the data type Post
, we have a reusable element called RE [Post] Controller (which acts as a controller, just like in Ruby on Rails) where all actions go through. From a UI perspective, this controller looks like a dropdown menu.
We always have basic CRUD actions on each controller, and another hidden variables popup called āAuthorizationsā. For each action on the post controller, thereās a variable such as canCreate
that checks if a user is allowed to create a post. We do this because we need to have different conditions on that specific variable based on the userās role. So when we add a new action like flagging a post, we create a new workflow (e.g. flag_post
) in the controller and add a variable called canFlag
in the āAuthorizationsā popup. This variable also has conditions to check if the user can flag the post based on their role.
These variables are then used in the flag_post
workflow. Is there a better way to organize this? If needed, I can provide diagrams and screenshots for clarity.
Right now, all of our reusable elements and pages have a hidden variables popup (which stores all kinds of variables), that makes our app sluggish. As Iām reviewing our app to understand why itās so slow, Iām wondering if thereās a better method than what weāre currently using. Any suggestions are welcome!
In any case, Iāll definitely compare storing variables in a floating group instead of a popup to see if it makes our app faster. If thereās an explanation for why a floating group is faster/better than a popup, that would also be great.
could you not just have a condition on the repeating group to have a different data source if the user is a student/admin/teacher?
eg: if current user role is Admin
data source: Do a search for posts (all)
Iām pretty sure the discourse over popup vs floating group is due to what gets loaded when. Iāve understood it as data in a popup wonāt get loaded unless the popup is opened or another element references one of the variable RGs/Groups inside it, whereas a hidden floating group (floating under the page) loads all data immediately and you can also put plugin elements in there.
If youāre getting slow load times, Iād take a look if youāre chaining together RGs within these hidden popups, if the data source for a visible repeating group (say āPostsā) has a data source of āRG var 1ā, which gets itās data from āRG var 2ā, which in turn gets it from another etc it can slow things, idk if it works this way on yours but I see this fairly commonly.
Other people may offer more info about bubbleās page loading, but I donāt think the raw number of popups on the page should actually really affect loading time, because theyāre only loaded when they need to be, (unless theyāre all being loaded immediately through some kind of workflow). Why your app might be sluggish probably depends on what exactly is being slow, is it page load or repeating groups loading etc, advanced filters are a common culprit too. Hope this at least helps a little! Optimising can be a pain haha.
I had some state groups (I organize states in 1px by 1px group elements and name them #loading #data #ui. This helps me organize my states) and plugin groups (same idea as the state group) stored in popups. At a certain point in time they didnāt load on page load and I realized itās because of the popup. I just store them in a floating group at 1px by 1px so I know they load.
IMO the best way to control loading of data is still using states. Why?
- You can only alter states through actions in a WF
- State lists do not update in realtime because you cannot store Search expressions so I know I will only load data when I want it to load. Realtime search per item in a state list still update in realtime
Because of the above:
- I have more predictable control.
- I can batch load data by scheduling custom events (eg. load 50 first then load the rest at as part of the UX or when I know there isnāt much load happening on the page).
- I can load data in parallel using scheduled custom events too (eg. one WF running 2 schedule custom event actions 1sec apart)
- I can pass a Search as a custom event parameter or/and result (eg. The custom event can trigger a āNo Search Results Foundā WF or otherwise based on the search count.)
- I now donāt have to deal with messy conditionals in RGs or whatever. Only RGs and plugins can store realtime search lists. For me I have my own plugin to store those (I needed triggers when a realtime list gets updated)
For your use case you can have different custom events loading different data. Then run (when appropriate) a WF that runs whichever custom event based on the user type in action conditions.