Super newb - Signup element group conditions

LinearPhase · 2021-02-08T19:11:24.017Z

Hi my name is Jonathan. I apologize in advance for this, “super-newb,” question. I have a lot of experience with music production, music software, and object oriented, modular music software development programs such as Reaktor, Buzz, and Max, and experience with html, some javascript etc…

I’m scary good at Excel (don’t ban me from forum for this).

But I am not able to figure out these four issues, or how to make the arguments for the Group Conditions. I am sure it is just being new with Bubble’s Logic.

I am all signed up for a Bootcamp that is starting on the 16th. I am just trying to get some scratch ideas down. and I hate when things like this hold me up. because my brain gets stuck and I can’t move on…

ScreenShot-12560×1440 278 KB

adamhholmes · 2021-02-08T19:47:15.965Z

The first 2 issues are just due to the 2 empty conditionals on the ‘Group Log In’ group (the 2 red squares in the image you included).

So just remove those conditions, or define them, depending on what you’re trying to do.

The second 2, I can’t be certain from the image, but it looks as though a workflow action is trying to set a custom state that doesn’t exist (it’s probably been deleted or copied from another element).

You can check what custom states the element has by clicking on the ‘i’ button in the top right of the element inspector. Or just see where the issue takes you when you click on it in the issue checker.

It will probably take you to a workflow action - you could just delete it as it’s not currently doing anything - but my guess is that at some point is was to do with setting the state to control whether the signup group is displaying a login or a sign up form, so with the missing states it wont currently work - so you’ll need to make sure they are there and working correctly.

It’s probably a good idea, if you haven’t done so already, to work through the basic Bubble tutorials so you can get a good understanding of the basics such as using conditionals and custom states.

LinearPhase · 2021-02-08T20:54:42.329Z

Hi adamhholmes,

Thank you. Yes, I have done the tutorials. I will probably run through them again. I appreciate the help. You are right on the work flow thing. I think it is just a question of my becoming a little more familiar

Cheers!

keith · 2021-02-09T08:29:54.452Z

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.)

sofiabelle · 2021-02-09T08:39:10.600Z

Thanks for your valuable feedback.

LinearPhase · 2021-02-09T21:25:32.166Z

Awesome!! I love it, you know Reaktor

system · 2021-04-19T19:11:29.169Z

This topic was automatically closed after 70 days. New replies are no longer allowed.