Hey folks!
A lot of updates from Bubble today. I thought I’d share how you can take advantage of them, and the quirks you might want to know about.
Buildprint will soon make a
/upgradeskill available, which automatically updates your Bubble app to take advantage of the new Bubble features, and remove workarounds for you. Stay tuned!
Global expressions
- global expressions are available in the new ‘Global’ (formerly styles) tab.
- global expressions take optional input parameters, and return optional output parameters.
- you can think of them in a similar way to how you’d think about custom events taking parameters and returning data, except these are in expressions
- you can use a global expression in a global expression
Let’s see some use case examples:
Lots of you have external APIs you might have built yourself. You might have a test API URL, and live API URl. Currently, you either use an option set, a data type, or perhaps a custom event to return these URLs.
A global expression is useful here. We can create a Get API URL global expression that calculates and returns the API URL we need to use.
We can create it like this:
Anywhere in our app (frontend or backend) we can use this expression to dynamically give us a text (in this case the API base URL we need to use):
Other use case ideas include:
- complex expressions you use frequently
- suppose you have a public API where you return JSON - you should have a global expression that takes a single data type, and returns the JSON for that data type. You can use that global expression anywhere you want to convert a data type to a JSON text
- permission checking, where a Current User has a hard to calculate list of permissions (probably an option set) and you want to use the same expressions on elements and in workflows (without referencing custom states/group data variables as that would be insecure)
Trigger a backend custom event
- This feature introduces a new workflow action, Trigger a backend custom event
- This does not allow direct return data from backend API workflows - only custom events
- It’s a great first step - in my opinion it now makes custom event/API workflow a bit awkward (a bit like how custom states/group data/properties have a lot of overlap but should really be one thing)
- caution that at the moment, any action results from the backend custom event (e.g changes to things, API call responses) will be returned to the frontend. The inputs to those actions are not returned to the frontend - only step results.
This has maintainability benefits as we can define code once, and re-use it in multiple places. This is particularly valuable for:
- people building native mobile apps that want to avoid duplicating logic
- people who want some of their app’s logic to be hidden but still used from the front-end (e.g AI system prompts)
Descriptions for reusable properties, and display names for arbitrary text, arbitrary dates, and searches
- This is a maintainability and developer experience improvement.
- It is advisable to add descriptions to all reusable properties. Irrespective of whether they’re useful to you, remember that any description you add will be seen by any agents working on your app (whether that be Buildprint or Bubble AI). The same applies for texts/dates/searches, though it’s only worth naming expressions that are actually complex/notable - don’t rename everything as it’ll cause you more confusion than it’s worth when scanning an expression.
Other features released that don’t require much ‘guidance’ include:
- editor dark mode
- conditional styles
- image gen in editor
- plugin editor redesign
- in-line workflow editing
Unrelated to these updates, I recently discovered that privacy rules that use Current User’s X can now be chained much longer. So, you can have Current User’s X’s Y’z Z’s P’s’ Q if you really wanted to. This doesn’t change the limit on This Thing’s X’s Y’s Z - only expression chains starting from the Current User (as those only need to be evaluated once per query).
Hope this helps!
