BTW, I worked around not being able to figure out why external scripts were not available in Expression by passing things off to a Run JavaScript.
I was thrilled to find that bubble_fn_index; works in Expressions.
But the explanation you provided here will let me streamline this greatly.
Thanks, again, @mishav!
BTW, this worked great. And it is faster to have all my moment-based conversion in the Expression, rather than handing it off.
Hey @mishav: Have you ever run into a situation where delay until page loaded (entire) does not work? I have a page which is kinda like any of my other pages where it needs to do the type of date transform Iâm doing.
It has an Expression on it (exactly like other ones Iâve been modifying) where Iâve moved the expression code into the Conditional tab and set the condition as page loaded entire.
However, rather than working (as all my other Expression things do), this page throws an error telling me moment-timezone is not defined. That is, it seems NOT to wait until page is fully loaded before trying to execute the Expressionâs code.
Iâve looked for all the obvious things like âis there a duplicate of the Expression hiding somewhere?â (no), etc.
The only fix Iâve been able to find is to make the Element that contains the Expression NOT visible on page load and then manually display it. (Like, have a button to show it.) When I do this, it executes properly.
Anyway, itâs got me stumped as to why this specific page would act any differentlyâŚ
Hi @keith, interesting you should ask, I encountered the same thing today, the page loaded event happened before the elements loaded, and it showed the sequence in the browser console.
Maybe something has changed recently in Bubble? For example, have you tried creating a new app?
My example was for a loading javascript library. I ended up adding an additional wait in a page load run javascript by doing this:
$(document).ready(my_init_function)
Do the other pages that used to work, still work?
EDIT - possible workaround, setup the above document ready on page load, feed a value in Javascript To Bubble, and use the value in the Expression condition.
Yes the other pages still work fine. Iâve not tried creating a duplicate from the problem page and seeing if that changes anything. But I will.
@mishav So, I cloned the page and the cloned page exhibits the same behavior. (Screenshot of the error thrown highlighting the problem Expression pasted below. This doesnât tell you anything you didnât already know, but FYI!)
I havenât tried creating a new app.
Like you, all Iâm doing here is waiting for libraries to load (moment, moment-range, moment timezone).
Sounds to me like if âpage loaded entireâ is being fired before thatâs really true, that would be a bug. (And thatâs clearly whatâs happening here, though I cannot explain why it happens on THIS page and not on others.)
If you have a simple example that shows the incorrect behavior, could you notify support@bubble.com and create a bug report? My own page where this happens (and pages where it does not happen) is just a bit too complex, I fear, to be a good illustration of the problem.
Best regards,
Keith
Iâm not sure I can raise this as a bug, because do Bubble actually say that âpage is loadedâ means all elements have finished loading? Theyâd probably make an exception for this when considering added HTML/javascript.
Today the same problem wasnât occurring, and coincidentally, my internet was at reasonable-ish speeds. So I ran an experiment, I throttled the speed using Chromeâs dev tools, and did a âhard reloadâ.
Sure enough, the problem reappeared, on page loaded event the library hadnât finished loading / initialising. Even my workaround of wait for document ready didnât work.
The is using a HTML element with <script src="...">. If I switch to jqueryâs getScript() this means loading at a later stage, but triggers a js event when loading is done, so should be more reliable, and testing shows this works on a slow connection. Unfortunately it is a much more complex way of loading, especially for multiple libraries.
Ideally the libraries would be loaded in the page header, but this is not always appropriate.
Hmmm. Well, Page is loaded (entire) should be akin to âready functionâ right?
I dunno what to think.
Iâve gotta go back to my problem page and see if thatâs still an issue.
The thing that concerns me is there was no inconsistency before, but now it seems to be a âcrap shootâ as to whether the libraries load before the Expression executesâŚ
(Aside: Moment Timezone is a potentially slow-loading library as it must be loaded with a bunch of supplemental Timezone data. Itâs just interesting that this issue did not come up until very recently.)
You might want to stop answering my questions as it seems that every software thing I touch immediately breaks. Itâs like the old âshow and tellâ joke:
âShow me a new feature and Iâll tell you about where itâs broken.â 
Consider your breaking stuff as an âapp hardening exerciseâ :_) Like how a few years ago there was a ceramic ball created that got harder every time it was bashed with a hammer.
I agree about the inconsistency, and it could be related to the timing of the different CDN servers involved, like how many attacks they are fending off.
Is there a way you can incorporate asynchronous (or lazy) load into your page, so the user can do something else while waiting for it? "Here is a crossword to solve ⌠"
Lolz. Well, thatâs why my solution was to hide the calendar in this particular page behind a button pressâŚ
Iâm just glad this isnât happening on all pages as that would be very very bad.
I missed this comment/suggestion when I first read your comment, @mishav
Today, I discovered another page exhibiting flaky âpage is loaded (entire)â behavior. Instead of having the scripts in an HTML element, I moved them to the page objectâs âHTML for Headerâ field and this seems to be more robust.
(At least in my particular case, loading these moment-related scripts in the header is fine.)
FWIW, while I was working on this stuff today, the problem became more frequent and after a while, I got the âWe were unable to load your application dataâŚâ error on page loads. As usual when this happens, the problem quickly rectified itself, but it seems like these issues (Expressions that should wait to fire until page is loaded (entire) firing anyway) and Bubble exhibiting slow accessibility are related.
(I guess whatâs going on sometimes is that things are taking too long to load and so Bubble decides to proceed with execution of certain things anyway, maybe?)
Anyway, thanks for the tip about moving scripts to headers. Hopefully this will alleviate the seemingly random issues around this.
status.bubble.is . update: you know 
Yeppers. (But the issue that Iâm discussing with Misha is in fact something we see on certain pages even when things are working properly. I guess today I could have guessed that eventually Iâd see the âcanât load app dataâ error page⌠Could kinda see it coming on!)
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:
2. In my REâs equivalent of âwhen page is loadedâ workflow, I have a Run Javascript step. What this JavaScript does is evaluates the âtypeofâ of moment. This seems to be the most correct JavaScript way of evaluating whether or not a function is ready to go. If moment() is not yet callable, evaluating typeof(moment) will return âundefinedâ. If it ready, typeof(moment) will return âfunctionâ. Note that evaluating typeof does not actually call or attempt to trigger the function, so errors are avoided.
If moment is not yet ready, the script executes setTimeouts iteratively until it is. (This of course doesnât block execution of anything as itâs all asynchronous JavaScript.) That looks 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:
On success, this Run JavaScript fires bubble_fn_moment(2), indicating that we are done waiting.
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.
Youâre putting your app in a straight jacket and handcuffs : )
Good idea. Youâve set up polling using a low overhead method.
Some small improvements if you feel like modifying something that is already working âŚ
Can use setInterval, and cancel it when done.
Can check for both libraries loaded in the same function. This would be a little more robust, to make no assumptions about the loading order, to be more general and also when for a weird reason, moment takes longer to load than moment-timezone.
High-five for a robustness improvement exercise, Keith : )
EDIT - I wonder if, by including the JavascriptToBubble result in a dynamic expression, youâve made the expression reactive to the result, i.e. reactive to the loading of libraries.
Then it could be part of the Expression expression, and would rerun when the loading is complete ⌠not useful for your particular use case, but might be for other things.
Hey, @mishav: Couple of things⌠1. I actually could not do both tests at once. Because moment-Timezone extends moment (like moment.tz() ), if you:
typeof(moment.tz)
Before moment is a function, JavaScript will throw an error. This kind of seems silly but it is true. Hence the two steps.
I believe this is because the syntax something.anotherThing is unambiguous. If you check typeof that, you are saying, âOK, JavaScript, tell me about the anotherThing method of function something.â To which JS replies, âsomething is not a functionâ if indeed something is undefined. Itâs the same as if you call the function before it is ready.
(Though I realize the single Run JavaScript could do both steps of these checks⌠good point.)
It would seem that whatever triggers THAT action is the true âpage if fully loadedâ event and it would be handy if Bubble exposed that condition, whatever it might be!
As for having this check inside of Expression: I had wondered about that. And I had initially tried there but got hung up on the âtwo wait stepsâ issue â that is, I could not figure that out until I broke the problem down. (I was also curious about when the workflow Run JS step might execute relative to Expression.)
Anyway, you COULD include this type of check inside the Expression, but in my case this expression gets evaluated anytime the user browses to another month (the script generates the 42 dates displayed in the calendar).
While a couple of IF checks are not high overhead, itâs just better for me if we initialize once and then know with confidence that we can allow Expression to do its thing as fast as possible.
This does lead me to a question: WHAT ARE the rules for Expressions firing? It seems that it fires (1) when its script is allowed to load and (2) whenever some underlying Bubble value that it depends on changes, yes?
Should Expressions have a trigger event? It might be nice in some cases if one could force evaluation by sending a trigger event. (I realize that duplicates some functionality of Run JavaScript.)
Thanks again for your awesome plugins!
Try this:
if (typeof moment == 'function' && typeof moment.tz == 'function') {
// both are ready
}
I wouldnât rely on the banner as indicating any specific stage, there is no documentation or expectation of its timing, and so could change its timing at any time.
If you want to try loading the libraries âlaterâ, try something like this:
setTimeout(function(){
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.22.2/moment.min.js', function() {
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.21/moment-timezone-with-data.min.js')
})
},2000)
I was referring to checking the result of the JavascriptToBubble, as that makes the check dynamic. Yes I agree its not suitable for your Expression.
Not a significant difference in performance, more a coding style thing, recursion vs explicit repetition.
Yes thatâs generally the case. Some additional times it can be triggered:
Do you mean for the Expression to send a workflow event? Hmmm maybe, but having the multiple triggering times as described above might make for too many events to be useful.
Do you mean for the Expression to receive an event (or a function call) from javascript, before evaluating? Hmmm maybe that too.
Keep up this train of thought, a few examples might help to design a New Improved⢠Expression element.
: )
This will not work. This is a very subtle JavaScript parsing thing:
Evaluating typeof something (or string version typeof(something)) is always possible. The object something may be undefined and thatâs OK.
However, evaluating typeof something.someotherthing (or string version typeof(something.someotherthing)) does not mean:
âWhatâs the type of something? And further, what is the type of someotherthing?â
What JS takes it to mean is:
âWhat is the type of someotherthing, a property of something?â
If something is not defined, JavaScript throws an error. Because we asked it to check a property of something. If something is undefined, JavaScript cannot check properties on it. Undefined things have no properties and apparently we are supposed to know this! 
(Another way of saying this: undefined.undefined is NOT undefined. Undefined.undefined is a syntax error!)
So, I guess the second part needs to be written as a function (one that returns false WITHOUT checking something.someotherthing before something !== undefined, but once something is defined can safely check something.someotherthing without erroring out).
More this. Like it could be forced to re-evaluate by triggering it (like from a function call). Could even have a âmanualâ mode in which the expression ONLY evaluates when asked to (again, via a function call). Might be usefulâŚ
Javascript stops evaluating if the first part returns false, and the second part has AND condition &&.
Something like JavascriptToBubble, but when invoked by javascript or a workflow step it evaluates an expression? Could include the parameter as part of the expression âŚ
bubble_fn_recipe(âappleâ) â or workflow step run_recipe, parameter: âappleâ â
ingredients.push(parameter)
ingredients.push(dynamic expression: âflourâ)
bowl.add(ingredients)
bowl.mix().spill(floor)
floor.mop()
return bowl.soggyRemnants()