Toolbox (Expression Element) Throwing Error Suddenly

[keith]

So, I guess it’s “random new error popping up” day around here. All of a sudden - and for no good reason - I am seeing the Expression element from Toolbox suddenly reporting an error. It seems to be non-critical(ish), but I only just noticed this error now and it is happening on both dev and live.

I’ve not pushed an update to live since 1/1/19… so this is new behavior NOT CAUSED by anything that I have done.

I have an Expression element that does some date math for me. Said Expression is NOT triggered until all libraries that it relies upon are loaded. And yet, the first time it is run, it returns an object of the wrong type. (It’s supposed to return a list of dates, but apparently returns a list of objects the first time it is run.) It seems to automatically re-run itself, even though I don’t believe my own code asks it to do this.

You can observe this in my live mode app happening here:

GRUPZ Booking Widget for BLUE BELL KNOLL TEST 1 | Los Angeles, CA Vacation...

(Again, this page DID NOT throw errors like this earlier in the month.)

The console log “America/New York” is the Expression reporting the timezone it is working with. It then proceeds to generate dates for the calendar and then returns them in an array of date type.

However, as you can see, when it tries to return those, the object returned is invalid. In my dev mode version of this, I have added more console logging that shows that the array is NOT an array of dates but of some other type of object.

The second console log “America/New York” indicates that the Expression runs again. This time, no error is thrown and the fact that we’re looking at a calendar at all tells us it must have succeeded.

@bubble, any ideas as to what might be going on here? @mishav, FYI.

In my dev app, I’ve upgraded to the very latest version of Toolbox (1.1.4). My live app is on 1.1.3 of Toolbox. Both versions behave the same.

Here’s my dev mode app with enhanced debugging turned on:

As you can see, a list of things that are not dates are returned. Then it runs again and succeeds…

[neerja]

@keith This involves custom code from a plugin so @mishav is the point person here

[keith]

Thanks, @neerja (also @mishav). I found the source of the issue – interestingly, [edit for clarity] when I deployed these changes on the first of the year, these changes worked without throwing any console errors. But one of the changes I had made to this page/widget was adding some custom states that are initialized when the widget loads.

I hadn’t paid much attention to the positioning of those initialization steps vis-a-vis the checks I do for libraries being loaded. While this wasn’t an issue at the time I deployed those changes, it turns out that NOW, my libraries are getting loaded more quickly (for whatever reason) and the custom states are not properly initialized before the call to generate the dates is being made.

So, I’m not going to complain about this any further. Something (either in the speed of the CDN or the speed of Bubble or both) has improved for the better (libs loading faster) and so the fix was just to move the custom state init steps to before I bother checking for libs being loaded.

tl;dr: Mystery solved. Something DID change with Bubble, but it’s a good thing AFAICT. Deploying my fix for this issue (and a bunch of other stuff soon).

Leaving this here on the remote chance that someone else observes a similar situation in the future.

[mishav]

Well done Keith finding and fixing the issue, getting the timing right for multiple libraries to load can be tricky.

How did you get the expression to wait for the custom state init?

[keith]

You were a huge help in helping me sort the loading out in the first place!

As for the fix, it’s just that first check for loading (wait for moment.js to be defined) was being kicked off before starting to init the custom states. These custom states are performance optimizations essentially (they are values that otherwise I’d be calculating dynamically many, many times, so they are just done here once).

Anyway, here’s a pic of the revised workflow:

The run javascript shown (you actually helped me write this) had been in about Step 3. It’s been moved until after Steps 12-14 which relate to the custom states (one of which is used in the Expression – the issue was that this value had become undefined before Expression was allowed to run).

You’ll note that when this script succeeds it pings another JS to Bubble element. On that trigger, we run another similar script that checks for moment-timezone being loaded. (I realize I could collapse those into one check – as you had originally suggested – but the modularity here is useful in other places)…

That second check – ensuring that moment-timezone is fully loaded – increments a JS to Bubble’s value to 2 when it is successful. And, so, the Expression only has a function in it once that state is achieved:

By moving the initial JavaScript that starts checking for moment.js AFTER the Set State steps, we ensure that those states are valid AND that moment and moment.tz are defined before “allowing the Expression to run” (meaning, before it has any script in it…) before it reaches this state, its function is just a comment – as you had suggested to me! – that says “// Hey, the expression is over in the Conditions tab!”.

[mishav]

Sounds like a need for elements to be able to have a list of dependencies or preconditions to be satisfied.

Thanks for explaining!

[keith]

Well, I suppose I could have wrapped the function call in the Expression with an:

“if state { function that depends on state being defined }”

… but I had not anticipated that being necessary, as I was assuming the state initialization always happened way before the Expression gets anywhere close to being functional.

(The expression script defines a function and then has a call to that function at the end of the Expression field.)

Aside: The central issue all of this exposes is that Bubble (like all rapid development environments) kind of encourages us to get a thing working (“Oh hai! That works!”) and then move on, without considering corner cases. But of course the Bubble environment is fluid and, without proper checks, things that work today may not work tomorrow for any number of reasons… It’s just hard to simulate / think about those cases… So you just charge ahead.

In fact, the reason this particular topic came up is that it turned out that my previous zone-aware calendar code WAS buggy. It actually worked just fine all through 2018 and neither me, nor any of my users, tickled the bugs (at least not that anyone noticed). But as 2019 rolled around, certain users in certain timezones started to see odd behavior. (Date math will do that.)

So I spent a good part of the holidays redoing the code and making it faster at the same time. That part is more-or-less bulletproof now, but I hadn’t even thought about a race condition between these new states and the library loading checks. There simply wasn’t any issue there at the time.

But, suddenly, now there is. DERP! But my widget dealies are pretty sophisticated and it’s not like any of this would be any easier if traditionally coded.

[mishav]

@keith

Bubble (like all rapid development environments) kind of encourages us to get a thing working (“Oh hai! That works!”) and then move on, without considering corner cases.

I totally agree. Bubblers can jump into the design and programming, and not even be aware of the other parts of the software development lifecycle (SDLC) like all the different testing and implementation stages.

@keith

I had not anticipated that being necessary, as I was assuming the state initialization always happened way before the Expression gets anywhere close to being functional.

A fair assumption given its purpose is initialisation. But without documentation to state that it should do it, can we call it a bug if it doesn’t?

It’d be nice if we could have some animations to complement the Bubble docs, to show dependencies, asynchronousies, and reactiveness etc of client/server, database, page load, elements, scripts. I’m thinking of those medical animations that show blood cells moving through veins lol…

[keith]

I’m totally with you here. Unfortunately, someone writing the ultimate guide to Bubble (whether a third party or someone employed by Bubble) is about 10x - 100x users away… As it is, I feel like there are roughly a couple dozen folks in the world hitting these sorts of edge cases.

Some of them are fellow moderators or regulars here in the forums. I assume the rest are on dedicated server plans and hence Bubble is nothing more than yet another framework in use at the end of the day.

[A bunch of stuff about how Bubble positioning is completely and totally wrong deleted.]

Long story short, there’s way too few Bubblers for anyone to be concerned about such a thing. It’s a shame, cuz things like Netlify (also an awesome product) actually have that 10-100x (maybe even 1000x) user base that Bubble needs… and such things are SO boring.