Hey, thanks for the ever rapid reply @gaurav! Yes, I’d love to start using all the totally cool things you have developed… and maybe one day this will feel okay for me 
Thanks for the pointer to the airdev document (or video?). Couldn’t find it on their web site, do you have a link to it?
All the best, Antony.
PS - Just found their blogs… did you mean those?
Hey @antony: Greatly appreciate the clarification about this Idea post. Also, I didn’t mean that summary to sound quite as snarky as it does upon re-reading! (The main point being that – while it would be nice if state defaults had a little more sophistication, and after looking at this a lot it’s not clear to me that there’s a good reason for that omission – one can always initialize a custom state on page load via a workflow.)
The point you raise about text concatenation in the Set state dialog’s value field is a good one. As I was playing around with custom states, I did not run into this. BUT, what you observe is absolutely true:
It is not obvious (like, really really not obvious) how to concatenate text values in that field.
The value field there seems to be (for lack of a better term) a “pure, single-expression” field. One cannot mix a text expression with text typed via the keyboard, nor can one chain two dynamic text expressions there. This makes it seem like concatenation may be impossible in that field.
(Further, when we look to see if there’s a :concatenate operator or something like it, we don’t obviously see one…)
We are used to seeing text fields like the one in the text element or in the boolean :formatted as text operators dialog, which DO allow text concatenation. (Spoiler alert: I think we just found the solution…)
So the question becomes: Is there a way to go from the pure expression field to a field where we CAN concatenate text. It turns out that there is: We can do the :formatted as text operator on a boolean expression and, when we do that, we get a more robust text-specific input where we can do all of the text things and return whatever text we want.
Here’s an example of how:
Note that we could have used any boolean expression in the Value field shown above and slapped :formatted as text on it. But what I chose to do is evaluate whether some dynamic text expression (that’s part of what we want to concatenate) “is not empty”.
Here’s how this works: The first part of this expression is a boolean expression. It looks at Current User’s Last Name. If that field isn’t empty, it will return yes/true. If that field is empty, it will return no/false.
Now we put :formatted as text on it to turn those true/false values into a text. And when we do that, we get the handy Boolean formatting dialog, which has full-featured text fields in it (note it even has Rich text editor links!).
For the yes case (Last Name has some text in it), we return concatenated text that’ll be something like “Smith is your last name!” For the no case (Last Name doesn’t have any text in it), we return the empty string (though we could do anything – for example, return “Hey, we don’t know your last name!”).
Having done this, we can see that there are probably other similar approaches like using :search and replace or :replace with regex, which will also present us with full-featured text fields, but I think a boolean :formatted as text is the easiest approach.
As i said, we could use any boolean expression to trigger :formatted as. Note that we always have access to at least 1 boolean expression that’s easy to snag: Current date/time is empty or Current date/time is not empty (take your pick). Current date/time is NEVER empty, so the first expression always evaluates to no/false and the second expression always evaluates to yes/true.
So we could do this:
One caveat: These “pure expression” fields like Set state’s Value field DO seem to have a bug that I often run into. Sometimes, the list of available dynamic expressions seems to go haywire and you’ll find that there are only a few options. If that ever happens to you, just reload the page and when you next click, you should see the full list. This drives me bananas and it seems to happen entirely at random.
You can tell when this is happening as things like Current date/time will not show in the list. While I was constructing this example, in fact, this happened to me. Here’s what the list looks like when it’s behaving properly, BTW:
4 Likes
A couple of additional observations about custom states and their values:
The issue of “I can’t set a custom state via an expression” is one that crops up semi-regularly here in the forum. There are two things that account for this: First, the bug I mention above. When that issue strikes, the list of available dynamic options becomes really short and if you’ve never encountered this bug before, you just assume that Bubble is saying, “Sorry pal, here’s all the options you have.” And then you’re like, “Oh man, this sucks.” And you might just stop there.
Second, as some of the examples above show, some expressions that should be easy to construct are perhaps more difficult than they should be. Alternatively, it sometimes seems that a given operation is impossible. This is rarely the case, but it’s often not obvious how to achieve the operation in question.
I think the free-form text modification / concatenation example is right up there with “where is the boolean not operator?” example.
The general philosophy in Bubble seems to be that, if something has already been made possible (even if it’s non-obvious), there’s a general reticence to supply alternative solutions (which might be redundant, but are easier to find!). This might be a smart approach in terms of simplifying ongoing maintenance and development of the Bubble platform, but I do sometimes wish there were more, and more user-friendly, operators.
Examples:
-
Inverting a boolean: To invert a boolean we have to evaluate
some_boolean is no. It literally took me hours to figure that out when I first ran into this need. An operator likesome_boolean:invertorsome_boolean:notwould be way more obvious even though the ability is already there. -
Arbitrary text manipulations: The concatenation example is just a special case of this. While we have
:search and replaceand:extract with regexand the trick of transforming a boolean into a string via:formatted as text, it does seem that a text operator like:editedor:transformedor:free transformwould be most welcome. (Such an operator would just display a dialog with one full-featured text input area in it, allowing us to modify or replace the current text value with any arbitrary text expression.) -
There are some operations that are literally impossible to do in a single expression, even though they “should be” possible. One example is if we desire to construct a date range “on the fly”, but we want to do some manipulations on both the start and end points of the range. A range like
now:+days 2<-- range -->now:+days 1is impossible to construct because the date/time operators are only available on the left hand side of the range. (Instead what you have to do is pre-compute one of those bounds, either in a database thing or in a custom state and reference that. But this is not always possible, as when you need to evaluate something like this dynamically in a Condition – you must be able to collapse the operation into a single expression.)
An approach that would get around this would be for dates to have a :to range operator that would pop up a dialog with 2 expression fields in it – one for each range bound. (This is also true for the numeric <–range–> operator.) … <-- actually, this would be a very good request for enhancement and I should probably file that as a bug report/RFE…
I’ve hit the “sorry pal” bug a few dozen times… Just don’t have anything to submit. @neerja consider this a +1 on its existence, but nothing concrete as to replication. As Keith notes, refresh always fixes.
1 Like
I think the “sorry pal” behavior is similar to the low-memory state in the editor that first causes the editor to slow and then crash out (forcing you to refresh) unless you refresh manually first. But it seems to happen far in advance of the full-on memory crash. Another irksome bug that probably has a similar cause is when the “> Insert dynamic data” flyout decides to stop showing up and is replaced by a nearly-impossible-to-select 1 pixel wide strip of blue.
^^^ the above shows the “normal” state of the insert data flyout (rather than the bugged state), but I think errbody knows what I’m talking about…
Basically, missing dynamic options and the missing flyout are symptoms of an impending low-memory situation. When I see them, I’m like “Alright, alright, I’ll refresh my page…”
3 Likes
Instead of ‘reload’ the page, simply take another object, open ‘Only when’, and return to your actual object. It reset the bug. This new bug as been persistent for approx 2-3 months now.
Thanks for that tip, @JohnMark… I’ll have to try this next time I see that bug happening.
1 Like