When we released global expressions in beta, the response from this community made one thing clear: You’d been waiting for a way to stop copy-pasting the same logic all over your apps. Today I’m happy to share that we’ve moved global expressions to GA, and it’s picked up some of your most requested updates along the way.
A quick refresher
Global expressions are reusable dynamic expressions. You build an expression once in the Global tab, give it a name, and use it anywhere in your app, including elements, workflows, and backend workflows. Edit it in one place and the change cascades everywhere it’s used. You can also add parameters to tailor a global expression at each place you use it.
What’s new in GA
Since the beta launch, we’ve been building alongside your feedback. Here’s what’s new:
Folders and sorting: Organize your global expressions into collapsible folders as your library grows, and sort them alphabetically or by creation date.
Optional parameters with default values: Mark a parameter as optional and give it a default to fall back on, so one global expression can flex across more use cases
Descriptions: Add a description to any global expression or parameter. Hover to see it, or view it when selecting a global expression on the design tab
How to get started
One thing to note: You’ll need the new property editor enabled to create and edit global expressions. If you haven’t yet, toggle it on at the top of the property editor.
From there:
Head to the Global tab in the editor (it’s where the Styles tab used to live) and open the Global expressions subtab.
Create a new global expression: Give it a name, description, return type, and any parameters it needs, then build the expression itself.
Use it anywhere in your app by selecting the Use global expression operator and filling in the parameter values.
To set up a global expression from existing logic, right-click any existing expression to convert it, then audit your app and replace old expressions accordingly. You can also check where any global expression is being used from the app search tool, which makes cleanup and refactoring more straightforward.
Give it a try and let us know what you build. And if you’d like to explore some clever use cases, check out this post by Petter Amlie.
Looks quite interesting. I just tried to use it but it asked me to use new editor. Is it possible that we can use them somehow in old editor?
I am not able to use new editor due to low contrast. Can’t read properly. Old editor has black, yellow, red, blue, white, gray colours. New editor has just white, black, grey (that too quite light).
BTW, Global expressions are a huge enabler and have partially mitigated the lack of being able to edit mid-expression by simply reducing the need to rewrite expressions overall. Big big feature. One addition that is needed is the ability to toggle expressions as “Private” (similar to how we can do with API call parameters/URLs/etc.). For lots of expressions they may either contain proprietary data or proprietary business logic that should only be running on the backend and would present a security/IP risk if exposed to the front end. This also has the added side effect of reducing amount of data that’s downloaded/rendered by the browser.
Private (or “Backend”) Global Expressions would basically make this feature-complete.
It would be nice to be able to use `current date time` in global expressions at render time. So far, when I need to use it, I have to pass the date as parameter, but it would be great to just write `current date time` and have it pick up the value.
The thing is current date time, doesn’t work inside a global expression. If I’m doing a do a search over a data using current date time as a constraint for any date type it doesn’t resolve. I have to add a Date parameter onto the global expression to use the current date. I found redundant. Don’t you think?
