How can I "write to console"

[laurence]

I am having some very odd behavior in my app. I am doing updates to a thing, followed by more updates to the same thing. Updates the app makes in early steps of the workflow seem to be getting lost, and the thing’s field values are being restored to to what they were prior to the last set of updates.

In order to begin understanding what may be happening, it would be helpful if I could write values to something like a system log and be able to review it to see what custom state and the thing’s field values are at various steps in the workflow.

Is this kind of thing possible with Bubble?

[keith]

Short answer: Yes, it’s possible.

The Debugger (the thing that shows up at the bottom of the browser when “?debug_mode=true” in your URL is present) is kind of sort of ALWAYS console logging for you. It just does that in a very interactive way.

I think you know the first part: If you set a breakpoint, execution will stop. The second part is: when execution stops, you can click through various values and variables and expose their values.

This is the interactive equivalent of JavaScript’s console.log(‘something’);

But I feel you… Sometimes just spitting things to the console would be a LOT easier!

You can do that, though:

Use Toolbox “Run JavaScript” action to LITERALLY write stuff to the console (the actual JavaScript console in your browser, usually revealed by hitting F12).

If you have Toolbox installed, you can execute the “Run JavaScript” workflow action in any workflow and literally console.log() stuff to your heart’s content.

Caveats: It’s weird how this works. (Actually, I find it slightly weird this works at all.) What happens is that “> Insert dynamic data” things you insert become ACTUAL TEXT in the executed code. So you have to anticipate and string delimit things in your console.log() statement.

ODDLY ENOUGH, I’m actually working with some Toolbox stuff right now and Console Logging the heck out of stuff, so it was easy for me to divert for a moment and give you this example…

So here’s an example for you. In the thing I’m working on at the moment, I pre-load some data on “page is loaded”. I know that that’s all working right, but let’s say that I didn’t.

Here’s how I can write some info to the console:

Note how I string delimited all the stuff I want to show.

When run with the console open, I see this (please ignore the fact that there’s a shit-ton of stuff in the console… I’ve highlighted the stuff that’s coming ONLY from the Run JavaScript action shown above):

At this point you are saying:

“Oh cool. Also, I see the highlights, but WTF is the red pen mark???”

Well, the red pen mark indicates that link I’m gonna click so I can show you the CODE that appears in the page when you do this. This is the part that I think is weird, but this is how it works.

What you’ll see is that this dynamic data just shows up as text in the code of the function we’re running. So when I click the “VM5446:5” link, here’s the code we see:

Crazy, right?

But hey, there you go… using console.log() with Bubble.

[NigelG]

I tend to create a “log” table and write stuff to it for just this reason.

[Bubbleboy]

Write to Console (Diagnostic Tool) Plugin for Bubble

[laurence]

Thanks, Keith.

I’ll study this, but I sense it will open the door to other possibilities for having a bit more control and visibility into Bubble when I need it.

I haven’t touched JavaScript in a long time, but I guess now is the time to see how much I’ve forgotten and how quickly I remember what I need as I need it.

Again, I thank you for a comprehensive explanation and the visuals.

[keith]

It’s super easy to do and quite handy. I assume the zerqode plug-in basically does the same thing but wraps it in Bubble interface elements.

[laurence]

Keith,

You wrote:

The second part is: when execution stops, you can click through various values and variables and expose their values.

As far as I can tell, when execution stops, the only elements or states I can see the values of are those directly referenced by the instruction at which execution stopped.

Example:

The only element I can see the value of is the custom state DateDue.
The Inspect button is unavailable.

Am I looking in the wrong place?

[keith]

Well, I didn’t say anything about Inspect being available (and, indeed, it turns out that Inspect is only available when regular Run mode is going on – that seems kinda sorta strange to me but I’ve literally never noticed that).

What I meant is what I said: That you can drill down on the value(s) there in the breakpoint step or you can continue to step, of course and you might find something intersting. In your case, the thing at that step “set state of DateDue” is DateDue is null. End of story, about it I guess. If there was something more complex going on, you might be able to drill and drill and drill.

I’m sure you’ve seen that in Inspect (I hardly ever use it, but there’s certainly a great deal that can be gleaned there.)

Anyway, that preamble wasn’t the point: I was just setting the stage for answering your question about if there’s a way to shove stuff to the console. (And there is and it’s easy-peasy if you’re comfortable with strings).

[laurence]

I appreciate your thorough explanation.

[keith]

No problem. BTW, if that step is interesting or problematic to you (like, you didn’t MEAN to set DueDate to null), what you’re being told there is that you forgot to fill in the “right hand side” value of the set state step.

That’s actually a very interesting problem in Bubble land. In most cases, if you forget to fill something out, the Issue Checker will nag you about it. There is one important exception:

The way that you set a value to null (“is empty”) in bubble is to “make changes” or “set state” (depending upon whether the thing is (1) in the database or (2) a local variable (“custom state”)) is to leave its right hand side empty.

This does actually create a situation that breaks the metaphor typically used by the Issue Checker. In the case of setting something to null the Issue Checker simply has to assume that you meant to do that.

In case it’s not clear what I’m going on about: Both of these are valid and will not throw an issue:

1. Make changes to a thing > Some thing > change field SomeTextField = “some text”
2. Make changes to a thing > Some thing > change field SomeTextField =

Neither of these represents an error. #1 sets the field to a new text value. #2 sets the field to a null value (which Bubble calls “is empty”… which sometimes drives me bonkers, but what are you gonna do?)

If we were on the Conditional tab of an element and we created a new condition and left the “When” field blank, however, the Issue Checker would of course throw an issue and nag us about it. (“Don’t forget to tell us when we should show this conditional state”)

[laurence]

Thanks, Nigel.

I went ahead and did the log table, and it helped me identify two bugs in Bubble.
See this post if you’re interested: Is the Debugger buggy?