Hey all,
I’m kicking off my new Substack with a piece on the new Global Expressions feature. It launched without that much fanfare, but it’s actually a really nice addition to the Bubble toolbox.
The article covers what global expressions are, six use cases I think they’re good for and some thoughts on how they fit into the broader picture of Bubble’s development.
Would love to hear what you think, and especially if there are use cases I missed.
Thanks @petter for all the examples explained in the article.
Btw, do you know if global expressions are transferred to another app when a component that uses them is copied, like with color variables?
I know that the logic in the expression can be different for different apps, so issues should appear in this case, but I mean if the the global expression reference is carried or not.
From what I’ve seen, they’re not. I’ve tried both regular copy/paste and Copy to another app, and the expression breaks in both cases (and nothing to be found in the Global tab).
Thank you for this article! I shared it with my dev team because we were chatting during the livestream and trying to think of ways we could use this new feature.
A question was asked in another thread on the forums about privacy - what lengths should someone go to when using global expressions to ensure nothing private or sensitive is being exposed?
Essentially the same rules as in every other dynamic expression.
Privacy rules handle the data layer
The global expression becomes part of your app’s source code, as you can see below in the dynamics.js file (Cart total is the expression), so no sensitive data in the expression itself.
I didn’t see the original thread, so not sure what the question was, but take the same precautions as in every other part of your app. No sensitive data outside of the database, API Connector and backend workflows.
global expression not giving the same results when using in backend workflow has anyone had this issue, when comparing 2 numbers to Yes/no variable it will not work when using it with global expression and I have no idea why, I copied the same expression to Only When workflow condition and it worked fine
@moe.uxuidesign sounds like a pretty basic setup. Could you share a screenshot?
Or if you’re sure it’s wrong, you can submit a bug report. It is in beta after all.
Awesome update and I love it. Question on it Petter - if you use Do a search for as global expression in a Single-page app with hidden groups as pages - and if I reference global expression Do a search for - is it just running it once, or it’s running the expression each time i reference it? Question is basically performance effect of global expressions. Thanks!
Thanks for your take. I think the best example of usage of a global expression is for file size, converting it to megabytes or kilobytes based on its value… It’s something I always store as a snippet on a reusable and just copy and paste it throughout an app. I’m just glad to have it like this.
As long as you reference the exact same expression (with no, or identical parameters) it should only perform the search once (same as Bubble in general: two identical searches will only be performed time).
Global expressions won’t noticeably affect performance, but they can help you avoid accidentally slowing down your app. For example, you might set up two nearly identical searches where the slight difference between them doesn’t actually matter, yet Bubble still runs both searches. With global expressions, you guarantee the search is identical every time, so it only runs once.
They can also technically reduce your total amount of code by a small amount.
That said, both of these benefits are more theoretical than something you’ll actually notice.
I see, it’s more for better organization inside app, with small performance benefits. Thanks for clarification!
Global expressions can be used to take a date, and return a relative time text, with no plugins 
This is the most impactful update since custom event return data and reusable element properties.
It would be great if the Global Expression parameters behaved exactly like Reusable Element Properties.
Currently, the Global Expression section provides a simplified parameter configuration, while Reusable Element Properties support additional options such as Optional, Default Value, and Description.
Instead of maintaining two different parameter models, the Global Expression parameters should reuse the exact same configuration and behavior as Reusable Element Properties, including all available property settings.
I definitely agree on that. All parameters being required making some use cases a bit hard.
Meaning, the value of ‘cart tool’ itself is not visible in the code?
I was excited for this… but… it doesn’t look like you can set a time zone for the date which I really need. Am I missing something?
Edit: Had another look as I thought maybe there was a setting I didn’t have turned on or something, and am now even more confused. For every date I display, I apply a custom format and the box where you set the format usually includes the option to set the time zone (which I usually do). In the new editor, you can’t seem to set the time zone anymore?
I don’t think you’re missing anything. As far as I know, this isn’t specific to Global Expressions or the new editor — Bubble has always worked this way.
Dates in Bubble are stored as timestamps, without a timezone attached to them. Bubble uses the browser timezone by default when interpreting or displaying a date, unless you explicitly override it.
What’s confusing is that operators like :formatted as, :extract and :rounded down to let you choose a timezone, but Arbitrary date/time doesn’t.
So if you create an arbitrary date, it’s interpreted using the browser timezone. Setting a timezone later in :formatted as only changes how that timestamp is displayed — it doesn’t change how the original arbitrary date was created.
For things like “5 minutes ago,” that usually isn’t a problem. But for “today,” “yesterday,” start of day, or any calendar logic tied to a specific timezone, it definitely matters.
The workaround is to either pass in a date that’s already normalized, or build the date from Current date/time using operators that do support a timezone override.
It would be great if Bubble added a timezone field to Arbitrary date/time and Current date/time, just to make it consistent with the other date operators.
Are you using timezone override controls feature?
