Value
This is the value to assign to the custom state. It should be of the type of the custom state defined when the state was created
what does this mean in layman’s terms?
I think it means the value or data you are trying to add in to the custom state isn’t the same as the data type you have assigned to the custom state.
So lets say you made a custom state a number and you are trying to assign it some text.
In your case it maybe you have chosen a data type like user and you are trying to assign it something else.
My best guess anyway 
hmmm still confused 
@i.naseem.in24 When you create a custom state, you will see a popup where you get to define a type like text or number or a custom type. When you set state and assign a value to it, the value should be of the type you defined so that you are adding number for number types and text for text.
possible for an example please?
Further to the points above: All data values in Bubble – be they primitive or complex – have a data type. In a sense, “custom states” are simply local variables in which we can temporarily (while the page exists) hold some value. (The core data types are the primitives you know as text, number, yes/no, date, etc. Complex data types are “Things” you create as custom data types in your database – e.g., Car, Message, User, Menu, Pet, Favorite Thing, etc.)
In JavaScript, we would just do something like create a variable (let’s call it my_thing) and put some value in it:
var my_thing = "here is a string we want to remember"
The variable my_thing is now of type string and contains that string value (a string is what Bubble calls a “text”). You will note that I did not have to tell JavaScript what data type my_thing should be before I put a value in it.
In JavaScript, the type of a variable can morph between different data types. Even though my_thing is currently a string, I could immediately go and turn it into a boolean (what Bubble calls a “yes/no”):
my_thing = true
In Bubble, our variables (custom states) do not have this property. We must tell Bubble what type of data we wish to store in the state. We can do that in several places, but one way is from the inspector - we click the little “i” icon on our element on which we want to create the custom state, and then we click the item for create a custom state, like so:
This gives us the custom state dialog:
As you can see, we must give the state a name (this is like my variable name in JavaScript), and we must also assign it a type:
And now we can shove values of that type into our custom state. For example, in some workflow:
And then…
^^^ in this case, I am storing a constant of text type in the state. I just typed the characters I love tacos.
But of course this state can hold anything of text type. So I might set it to be the value of some other text thing:
^^^ in this example, my custom data type called Foo has a field on it called Name that is of type text. So I can store a Foo’s Name in this custom state.
What the Bubble reference is explaining to you is this: Since the custom state is of type text, I can only store a text in it. I cannot store some other type of data, like a Foo itself (a Foo is not a text – a Foo is a Foo).
.
What happens if I try to store a Foo there? Well:
^^^ the Issue Checker informs me of the data type mismatch. The expression in the Value field is red, indicating that there is a data type mismatch. In case I don’t realize what the problem is, the Issue Checker gives me explicit detail:
“Hey pal,” it says. “The custom state is of type text, but you are trying to put a Foo here.”
4 Likes
BTW: This is nearly all that the Issue Checker does. It is mostly around to inform us of data type mismatches like this. (And in a complex project, this is very helpful. You will note that, from the Set State dialog itself, I cannot immediately see what data type is assigned to this custom state. So, instead of thrashing around, we can just consult the issue checker… “A-ha, I created this state to hold a text.”)
This is basically the only type of “syntax error” that is possible to make in Bubble. The vast majority of issues that the Issue Checker will tell you about are simply this data type mismatch sort of thing.
The Issue Checker will warn of several other things that are much less common. For example, some workflow actions can only appear in a certain place within a workflow. The Navigate > Go to Page action is one of these. When you use Go to Page, that’s the end of your workflow. No actions that appear after it will be executed and so the Issue Checker will warn you of this.
(This preceding example is somewhat of an arbitrary decision on Bubble’s part. As was noted in another thread – I think by @luke2 – there’s really no reason that Go to Page must be the last action in a workflow as Go to Page has an “Only When” condition on it. One might desire to have a different Go to Page that appears after this particular Go to Page action that triggers on a different condition. So what the Issue Checker forces us to do in this case is to create a separate workflow where we might execute the other Go to Page.
This sort of thing is intended to make Bubble goof-proof and make it difficult for us to make certain types of errors. But once one gets a certain level of skill with Bubble one starts to go, “Oh, c’mon…”
Thankfully, there aren’t a LOT of things like this in Bubble.)
I’ve actually been thinking of compiling a list of all the things the Issue Checker can identify as it’s kind of interesting…
2 Likes
thanks Keith some light reading done, and will review again morning but that makes sense now! you have educated me today 
1 Like
Yeah the error checker is interesting. This reminds me, I think there is a bug when copying workflows that have been categorised into folders, that are then copied to another page, it would be flagged as an error and therefore I’d have to just reset the workflow group to empty - I’ll check if this bug is still present later on.
But yes, just for context, the post @keith is referring to is the issue with having the workflow actions ‘Go to x page’ and ‘Refresh page’ used together, when the go to page is the current page, simple workaround, but just odd logic.
This topic was automatically closed after 70 days. New replies are no longer allowed.