Pro tip, @LinearPhase: if you click the issue in the Issue Checker, it will take you to exactly the place where the “issue” is occurring.
(Aside: the issue checker isn’t much of an “issue” checker. There are in fact very few “issues” that Bubble alerts on. Mostly, the issue checker tells you when you’ve formulated an expression that resolves to the wrong type for the field in which the expression is constructed.
Bubble is a strongly-typed environment. All data values in Bubble have a type and the type is essentially declared before a data value is created/stored somewhere.
That is (for example), if a field expects a number, any expression used there must resolve to a value of number type — and not a string (“text”), boolean (“yes/no”), date, etc.
Additionally, arrays are their own thing and Bubble differentiates between scalars of a given type (e.g., number) and arrays of a given type (e.g., an array of number type, called a “List of numbers”).
As an example, let’s say that some field expects a number. You can put a numeric literal there, like “5”, or you might build an expression that resolves to a number.
Consider the following: Let’s say your User object (“data type”) has a field on it called First Name. Obviously, this would be a string (a “text”, as Bubble would have it).
And now, you have a field somewhere that expects a number. And you enter into this field:
Current User’s First Name
The above expression obviously resolves to a text. So this expression turns red in color, to indicate to you that the expression is of the wrong type. Simultaneously, the Issue Checker will show a new issue telling you about this.
Maybe you were just messing around and so, to resolve the issue, you would just right click the field and clear it.
However, you might have simply forgotten to finish your expression. And so, to resolve this, you might continue with your expression building thusly:
Current User’s First Name :number of characters
This expression would resolve to a number. If the User’s First Name is “Keith”, this expression will yield the number 5.
The other most common thing the Issue Checker will flag is a required value that is missing. Some input fields are optional and some are required.
Required fields will be outlined in red as in your screen cap of the two Conditions you created (but didn’t fill in).
You were probably just experimenting and created those new conditions just to explore the interface. However, those conditions come with — you guessed it — required fields. So the resolution in this case is just to nuke those conditions (by clicking “remove condition” in the upper right above the condition).
I’m not a Max/MSP guy, but I’d assume that in Max you can drag out an oscillator or filter and then not hook it up to anything and the environment won’t complain about that. You just did something dumb (or just decided to finish it later), but that’s not an “error”. Certainly that’s the case in, e.g., Nord Modular or NI Reaktor — you can have “modules” in a patch that aren’t doing anything (and ain’t hurtin’ nobody).
Not so in Bubble. The Issue Checker is what we call “opinionated” and enforces not just literal, actual errors, but also style to a certain extent.
There ARE actual errors that the Issue Checker will call out, but these are rare. For example, let’s say you create a custom state somewhere and then somewhere else you have a workflow step that sets the value of that state. If you later delete the custom state, the issue checker will raised an issue about the fact that you’re referencing a state that no longer exists. This would be a real error, as your code will certainly fail there.
There are other examples, but mostly the Issue Checker is a data-type-consistency and required field checker.
This probably sounds stupid to you, but keep in mind that Bubble is an environment that attempts to enable not just “non-coders”, but folks who have no experience with any kind of programming/algorithmic design.)
