I had one of those multi and-or-and/or expressions and I was losing my (back) hairs trying to troubleshoot it. So I split it into a custom trigger and my hair grew back again.
@petter would the documentation be more accurate like this?
5 Likes
Also, I always consider custom triggers when I need to use some intermediate result or calculation more than once.
1 Like
My mantra for keeping my sanity in Bubble is to not have complex expressions in workflow conditions.
I treat custom events like classes and functions to keep things easier to manage.
5 Likes
I need to do this for one of my actions that has a 40-step condition.
(One day.)
1 Like
Interesting. Could you expand on that?
You can have backend custom events as environment variables.
4 Likes
In code we create classes and functions not just for repeated code, we also use them to partition complex blocks of code so it’s easier to test, read and make changes.
I treat custom events the same way. I don’t like long complex workflows cause they make it hard to read and troubleshoot. It’s also cause I don’t take the effort to rename my workflows so this makes things easier to understand what’s happening when I troubleshoot.
2 Likes
I think what I meant is: did you make a difference when you said:
I’m guessing they are both the same. Maybe a class always returns only 1 thing and a function might return 0 or more things?
Oh, no I’m just generalizing classes and functions.
2 Likes
I like that, too.
And, I recently moved a couple of env vars like these to an actual db thing so that I could change the env vars without a deploy.
these are the threads I love
I usually go for custom triggers when I have to reuse a specific calculation or intermediate result more than once.
Hey @georgecollier - any arguments against this security wise? (I’m not saying there are)
Obviously you can’t use in front-end, but it means:
- you’re not hardcoding secret or secure values in multiple places
- you’re not going to accidentally leak them in screenshots etc
- by being in backend they’re not manipulateable
Thanks for getting back to me! Yea just checking in to see if there was anything to consider there.
Another way is to store keys in the DB then just make sure you access it server-side exclusively. Privacy rules still apply since it uses the current user’s permissions. It’s an easy way to get around storing and retrieving keys that don’t use the API connector’s private values. **
If I am wrong somewhere here, do let me know 
**do take into consideration the additional WU costs over time
This is definitely the way - maybe there’s a place for both solutions?
- 1-3 keys required - backend variable can work
- changing/multiple keys/bespoke keys for users - in db protected by strong rules
1 Like