Let’s imagine I have a reusable element with an error popup, a processing grayout popup, as well as a contact/support popup. I then inserted that reusable element into a dozen other reusable elements (payment, chat, edit profile, etc.).
When the page is loaded, are those reusable elements duplicated, creating dozens of same elements on the page,
or,
are they referenced, as in “Ok, payment module is calling the reusable, let’s pull it up. Now, chat is calling it, let’s pull up the same reusable element”.
It is copied with reference to the original reusable. This means you can have multiple of the same reusable in a page and when you update the design of the reusable, these copies are automatically updated as well.
@flusk Thank you for the reply. I understand how reusables work in the sense of updating.
My questions refers to the amount of code being downloaded to run a page. If I have a 100 of the same reusable on the page, has my page grown to 100x the amount of code/data required to download it. Or is Bubble smart enough on its own to know this should be a different instance of the same reusable.
Probably, yes. A RE that requires 10 hypothetical lines of HTML (among other things) in your browser would require 50 lines if pasted 5 times.
Whether that means you’re downloading 50 lines from the server, rather than 10 and your browser rendering five on the front-end, is unclear. But it’s not particularly important. There’s no real harm to loading tons of groups, though when excessive it could hurt page load times particularly on mobile. The harm is when you’re loading data in these groups that things slow down or begin to cost
It is copied and duplicated so you will be having excess data retrieved from server as well as code downloaded. You will also have any workflows associated with ‘on page load’ run for each, so unnecessary amounts of WUs consumed.
You should create the reusable and put it into your reusable header, but from the sounds of it, the error popup can just live in the header itself and can be structured properly to be used for ALL errors that might occur throughout the entire app, processing payment greyout likely is fine in header itself as well as I’m assuming you are using URL parameters to determine when to show the processing payment greyout, contact support popup should go into the header as well and use a custom trigger to show the popup, then where-ever you have the contact support button (assumption on pages and not in the reusable footer) you will also on that page have the reusable header, so you can from the button click on page trigger custom workflow from a reusable element to show the contact support popup.
I did the header-based approach, but the issue there was double-nested reusable elements.
Index page:
header
reusable1
Reusable1:
Reusable2
Reusable2:
reusable3
So when there’s an error in reusable3, I have to have it trigger a custom event in reusable2. Then it has to trigger a custom event in reusable1. Then index page has to trigger a custom event from the header.
It just becomes very convoluted very quickly, I wish there was a way to reference a library of placed reusable elements, so we could trigger custom events from other reusables regardless of how many elements “away” they are.
You can use a Javascript to Bubble element to trigger any action, in any reusable element, from anywhere else on the page (including inside other Reusable elements and RGs).
It’s a much simpler, cleaner, and more efficient, way of working with REs.
That way you don’t have to duplicate REs, clogging up the DOM… just place one on your page, and you can call it from anywhere.
I also want to avoid running anything from the URL, as the app can then be manipulated by anyone bored enough to play in the address bar.
The other approach was to write errors to a “session” database table. Then have the header respond to “when Current User’s Session’s Error is not empty”. But that uses WF.
Highly unlikely but also can be avoided if you use a unique value for the URL parameter, which was only assumed you were already using for a payment greyout, but if you are not, you can also just use a custom trigger for showing the payment greyout, which can not be manipulated in any way.
