Hi I’m merging my app to a native app and I used a lot of reusable element. I know we can’t use the action go to page even if it’s the current page when using a native app, so I’m merging the parameters to statement but I would like to know more from the community on how I can mix my statement knowledge and reusable elements. Any other points of view is appreciated !
fascinating read and well articulated in 1 place. Sometimes, i can be running around many youtubes and guides
1 Like
Great read… Very Informative!
How about using draggable elements from one reuseable into a drop area of another?
Thanks @petter for this post. I think it’s still relevant 3+ years later. I’ve enjoyed your books too btw. 
A quick question if you (or anyone else) might have a thought on this:
Prior to making the change to FULL reusables, I had a multipage app where each page needed to connect to a single reusable element… the header. In order to have an action on a page trigger an action on the reusable header, I made frequent use of the “do when true” action on the header. On any page, I set the state of the reusable header from that page, and then the “Do when true” ran on the RE header to trigger an action. Pretty simple, and it works great.
Recently from I made the switch to a single page architecture, and went all in on reusables. As you point out, dev-wise this is far easier, but the challenge of working across reusables is definitely more tricky. I now have numerous REs on a page, and as before an action within one of these REs needs to trigger an action in the RE header.
Here’s the question/idea I had: Rather than using a plugin, would it work to create a single global reusable element that had no visual elements in it, but only contains a bunch of states you wish to set (let’s call this element “DT EL - Global States”). And then nest DT EL - Global States within each other RE. Then whenever you want to set the state of something across your app, you set it on DT EL - Global States (from within any RE where DT EL - Global States is nested). If RE1 and RE2 both have DT EL - Global States as a nested RE, my thinking is this should enable two-way communication between RE1 and RE2 because both sides would be able to set and clear the custom states?
I’m asking because logically this seems like it should work, and yet, I’m not getting it to (sigh). It seems like it’s conceptually similar to Env Variable, but perhaps easier because it’s native bubble.
Thanks in advance if you were tracking on the above and have a minute to point me in the right direction 
Hi @trevor.goss
From what I understand in your description, you are thinking of placing this reusable element across your app and use its custom state to trigger different things. Each reusable element is considered in isolation by Bubble, which means that two instances of the same reusable element could hold two different values (or no value) in their custom states.
The logic of placing workflows, popups and other stuff in an invisible RE is completely sound though – as long as you keep in mind that they are treated as individual instances.
Let me know if I misunderstood you here!
2 Likes
Thanks @petter !
Ah, that’s why it’s not working then. I’ll admit it does seems weird that two instances of the same reusable on a page (both visible) could hold different values at a time, but what you articulated makes sense as to why my workflow wasn’t producing the desired results.
Given that limitation, I’m assuming this is where the env variable plugin @gaurav developed comes in (i.e. it is global and that makes its states available to RE1 and RE2, etc)?
You can now use ‘go to page’ = current page in workflows to make things a bit easier with reusables, rather than hard coding the page and reloading.
There is also now a dynamic page option.
There are some drawbacks you can read in the thread below but i thought it worth adding to this thread.
hi @petter
I have bought your new edition for performance. But I already bought the initial one. However, it seems I managed to do it without being registered in gumroad. I can’t even find in my inbox any confirmation emails.
Is there a way to get reimbursed?
(I also bought the ultimate guide for security btw)
Hi @nassmim972 ,
Could you DM me your email address, and I’ll look into?
great guide, thanks!!
For those reading this guide in 2024 and later (and if you scroll this far down…); after Bubble added custom parameters to reusable elements, the sharing of data between them has become quite a bit easier.
Many of the points in this guide would probably be over-engineering at this point, so I recommend people get to know how the reusable element parameters work, and use them if they can solve the problem in an easier way.
5 Likes
I know this is pretty late, but for anyone who might need it, you can check out this plugin: Browser Storage X Plugin | Bubble.
Demo: Browser Storage - Plugin Demo
1 Like
@petter Im a big believer in reusables - and global variables - used well they can definitely make a difference.
However, I experienced something interesting the other day. The debugger was reporting an error, which I tracked down to a value that was being passed to a reusable. This error was being caused by one of the parameters on the reusable being using as a URL in a display element within the reusable - but at a time when the text value being used wasn’t a URL.
At that point in time the reusable wasn’t visible and wasn’t required, so my assumption had been that the reusable wouldn’t be checking on the data that was passed to it. The error was solved by simply changing the reusable so that the parameter was left empty - with a conditional used to pass the parameter only when it was required (e.g. only when the value of the text parameter was actually a URL and so wouldn’t cause an error).
This makes me wonder… is it worth using reusables in a way where they only get data via conditionals rather than via the provided fields? Could it even be worth putting a simple conditional ‘this custom element is visible’ so that Bubble only retrieves the data when really required?
I had assumed that Bubble wouldn’t bother doing anything with reusables when they were invisible, but it looks like it does.. and that might be a drain on Bubble resources and slow things down for the app… Any thoughts appreciated!
Yeah, it makes good sense to use some lightweight condition to control when data is loaded.
You can be strategic about when to actually load the data. For example “when X is visible” is a lightweight, easy way to set up a condition, but your users may also experience a slight delay if you intend to show the data right then. If so, you can find ways to start the loading a bit earlier so that it’s ready for when the element is visible.
Do you think it’s worth doing this as standard? Putting parameter values on conditionals is a little harder to manage as you have to manually add them in via the editor (e.g. it doesn’t automatically give you the full list of parameters for the conditional) - so could add quite a lot of extra editor maintenance work when things change. Am thinking maybe only worth while bothering with where its clear the parameter loading is impacting on performance.. especially if it needs some clever handling to get them to load before becoming visible…
Yeah, I think your final points is important, and I try to include it whenever these kinds of discussions come up. Over-engineering is a real and costly thing, so keep your eye on the goal: optimize the processes that truly affect WU and/or performance, but don’t implement countless minor adjustments as a “default”.
Also, keep in mind that keeping things in reusable custom properties (I assume that’s what you’re doing) makes it easy to come back and optimize later. So if your app and current user base is spending 10% of your allotted WU and performance is acceptable, you can choose to take note and optimize as needed later.
To put it bluntly, it doesn’t really matter how much WU any given process spends if you’re still well within the plan limit and user-perceived performance is good enough. As your app scales, you can adjust. If your aim is to optimize page load speed, it makes sense to approach it early though.
yes, thanks, makes sense. Saw that you wrote a book back in 2020 on optimising bubble - do you think it’s still useful with all the changes Bubble have implemented in the last 5 years? Im looking out for any non-obvious tricks that might improve performance (e.g once you’ve got the database, etc, optimised, what more can be done!)
Well, I’ll leave it up to readers to tell you whether it’s worth the buy, but from a purely technical standpoint it does touch on more subjects than just database optimization, and I’ve tried my best to take a holistic approach and explain how different decisions affect performance (while hopefully succeeding in helping readers find their own solutions and compromises while designing instead of taking a tutorial-style “do this” approach).
With regards to Bubble updates, the principles outlined in the book mostly apply to web apps in general (but seen through a Bubble lens), so they don’t necessarily become irrelevant even if the platform evolves.
There are a few points where Bubble has evolved that made me change the book or where I feel it’s a bit outdated:
- The first one is just the simple fact that over time Bubble has become faster. Performance was a more pressing issue when the book was written, so users, myself included, were more inclined to seek out methods to optimize it. That doesn’t make the methods wrong, but as I pointed out, it’s worth balancing optimization and over-engineering.
- Processing data in the backend has become a lot more stable and efficient without needing to resort to workarounds like recursive workflows (that are costly from WU perspective). Over time, Schedule API workflow on a list has become the more efficient option in most cases.
- WU wasn’t around when the book was written. I’ve updated it to include it, but it’s worth noting that the book focuses on creating fast apps, not necessarily on keeping down WU. The two sometimes go hand-in-hand, while other times they’re in opposition.
- The “new” responsive engine has also made it necessary to balance some of the advice in the book. For example, keeping element count down is one way to speed up page load, but the responsive engine relies more on containers (groups) to resize and align elements properly, whereas in the old engine it was easier to reduce the number of unnecessary nested groups. Of course I doubt you’ll find anyone who prefers the old engine.
That may be a longer response than you needed, but it was interesting to do some personal reflection 
In the end, I shouldn’t be the one to judge its quality, but I do think the book is still relevant technically.
1 Like
Thanks Petter - I’ll give it a read. Always interesting to get better insight into how Bubble works! Interesting you say above ‘Over time, Schedule API workflow on a list has become the more efficient option in most cases.’ - I’ve always avoided ‘on a list’ actions as I’d read so much over the years about not using them, but maybe its time to start giving them a try!
1 Like
Awesome! Would love to hear your feedback after.
Regarding Schedule API workflow on a list, I specifically mean in comparison with recursive workflows. I wrote a manual article a while back that details the scenarios where the latter is useful: Recursive API workflows | Bubble Docs .
Recursive workflow used to be the better option in a lot of cases, but with improvements in how Schedule API workflow on a list performs as well as the introduction of WU means that’s no longer the case in most common scenarios.