Hi @mishav, Hey, I found a very “Bubbly” way – and “Toolboxy” way – to ensure that long-loading scripts (such as moment / moment-timezone) are loaded before firing off an Expression.
(As a quick recap: My use case has been that I’ve modified the “custom calendar” technique originally offered by @codurly to work in a more “timezone-aware” way. The new Expression code that generates the calendar dates does so using moment/moment-timezone. The issue of late has been that – unless the scripts for those are put into the HTML header of the page, the Expression will try to fire BEFORE those libraries are fully loaded.
And as you and I recently discovered, making the Expression code only load on “Page is loaded (entire)” is not 100% bulletproof. In fact, that event can happen substantially before moment/moment-timezone is ready.
I recently took the Calendar widget I’d built and turned it into a Reusable Element, further complicating the script loading issue. I didn’t want to have to move the scripts that the RE relies on into the parent page itself… And I also didn’t want to waste time loading those scripts twice [even though that’s not really an issue with moment, but of course it could be with some other types of scripts].)
So here’s what I’ve done:
In my case, there are in fact 2 things to wait for. First,
moment will become ready and afterward the
moment-timezone functions (moment.tz) will become ready. Here’s how I check for those and how I’ve configured the Expression element:
1. Rather than executing the Expression code on “page is loaded (entire)”, I’ve set it to wait until the value of a JS to Bubble element reaches a certain status value. Like this:
You’ll see that on success, we fire bubble_fn_moment(1). That JS to Bubble element is set to trigger and, on reaching this state, executes the next step of our wait, which is just like the first step…
3. But now we are waiting for
moment.tz to be callable. Like this:
Upon reaching the value of 2, the Expression element becomes active as configured in Step 1, above.
This technique seems to be both quite performant and very reliable.
Testing with CPU throttling, slowed network, and cache disabled in Chrome Dev Tools yields console logs that look like this:
You’ll note that we waited for about 800 ms for moment to load beyond when Bubble tells us “page is loaded”, and an additional 100-200 ms for moment.tz to become fully ready.
Without throttling, we of course wait much less. Here’s what that looks like on my machine with net and cpu unthrottled (but still disabling cache to ensure we are not fetching these things from local storage):
Seems to work just fine, so thought I’d share this idea with you.