Each month, Million Labs developer Joe Harris shares 3 of his top insights for the month. If you're building or improving your app, these are well worth a look in. 

New expression composer beta: is it worth it?

You might be aware that Bubble has recently been trialling a new expression composer and is collecting feedback on it. It’s easy enough to toggle on/off through the interface, as there’s a toggle at the top of any applicable element.

As such I’ve taken a look over the new public beta version of Bubble’s expression composer, curious as to what changes they’ve implemented.

My first impression is that there’s been some nice QoL changes, especially the “add dynamic data” button. It’s a rather tiny thing, but it’s much nicer to be able to easily and directly insert an additional separate data call instead of trying to click the end of the composer, after it invariably moves itself around several times, just to click the “insert” popup. The “Rich text editor” button is also significantly more readable.

What seems to be the main bulk of the changes, though, I have some mixed feelings about. While I can’t deny that the new format is definitely significantly more user friendly for those with less experience in Bubble, as someone with significant hours spent in the editor, it just doesn’t really feel much different. Everything functions exactly as it used to, but now all dynamic expressions are significantly more “spaced out” and the “brackets” appear to have been replaced by these tiny little “up-ticks” in the underline of a section. In my opinion, lines with small “ends” are harder to read than parenthesis, but I may be biassed as code revolves quite heavily around (), {} and [], so I’m just very used to reading them.

I can see how the lines may be of benefit in incredibly long expressions, especially as each line highlights just the relevant content as you hover, but on the other hand, following a single underline along multiple lines of an expression, using only the little “ticks” as guidance isn’t the most immediately readable thing out there.

Naturally, other people may much prefer this approach to the old system, but in my own opinion, I feel like this should remain as a firmly optional (but probably the default) feature, with the legacy/current composer made available as an option we can enable if we so choose. This way, the main bulk of users gain the benefits of this new style, but those of us who like the old way better can still have our cake and eat it too.

Integrate Calendly into your application through Webhooks

I recently set up an integration for Calendly but with a slight twist on the usual “attach Calendly booking link and call it a day”. While the client wanted the booking to be done off-site on the standard Calendly link, there were a few extra details we needed to sort out.

For this one, the client wanted to have multiple calendars available, one for each employee, which the site’s user will pick from through a dropdown. They can then click a button to access that user’s calendar. While this should be a simple list of links, the other caveat is that any booking made to these calendars (off-site, through calendly) should be fed back into Bubble through a webhook.

Due to how Calendly works, you can’t set up a webhook directly through their own website like how Stripe lets you manage them, it requires you to follow some API documentation. You instead have to do this via a POST API call to https://api.calendly.com/webhook_subscriptions where you specify the user, organisation AND the webhook URL you wish to send the desired events to.

However, to do this, you need the User ID, Organisation ID and Access Token of the desired user to configure this all. Luckily, once you have the Access Token (which is generated on the account, through the “integrations” menu), you can make a simple GET call to https://api.calendly.com/users/me where all you send is the token as a header in the form:
“Authorization: Bearer [token]”. This API returns the exact User and Org URIs that you need.

From this point forward, you just need to load these values into the POST call and trigger it to get the webhook all set up. But the thing to note is that this should only ever be done ONCE per user you set up, ideally through an admin panel “creation” interface where you specify any pertinent data and the Access Token, then the system runs this automatically. Calendly will automatically reject and fail any API call that attempts to make a duplicate record.

How to create a time tracking system that works even when website is closed

Recently, I was brought onto a project to help out with a timer issue. The client was wanting what is effectively a time-logging system, where their users can start a timer, pause the timer, resume and finalise. However, the added caveat to this is that it had to work with the user being tabbed-out for extended periods of time and also function between sessions (closed window/browser).

The previous iteration had been very elegantly written with JavaScript, and while it functioned perfectly, certain browsers were “shutting off” the background process after a couple of minutes of being tabbed out and closing the browser window itself naturally reset the timer. This meant we needed a new approach.

Instead, I built a very basic database structure to hold these timers, as if we wanted it to work while the browser is closed, we’ll have to store the information somewhere. The general fields I had for it were the following: Time Running (Seconds) [Number], Time Paused (Seconds) [Number], Start Date [Date], Last Resume [Date], Last Pause [Date], Paused [Yes/No] and Finalised [Yes/No].

The basic premise of this is that when users create a “fresh” timer, it would create a new database record where the “Start Date” and “Last Resume” were the Date/Time at which user started the timer and both durations were “0”. As Bubble’s “Current Date/Time” is locked in on page-load, I used a nifty little plugin called “Current Date/Time“ which, through a page element, keeps a constant track of the exact current Date/Time to the second. (This saves me having to write any calls to obtain it myself).

All I had to do from this point onwards was tell Bubble to take the current date/time from the plugin element, subtract the “Last Resume” date from this and format it as seconds. From here I could then perform several calculations to turn this into minutes and hours for the display. To ensure that pause/play also works in this case, I also was sure to add “+ Time Running (Seconds)” to each value.

Whenever the timer was paused, I marked the “Paused” Yes/No as “Yes”, the “Last Paused” Date as the Plugin’s time and “saved” the total number of seconds the timer has been running to the “Time Running” field. Whenever it was resumed, “Paused” because No, “Last Resume” became the current time and “Time Paused” was updated. By doing this, the timer display was calculating how many seconds since the “play” button was hit, then adding the number of seconds it had been playing previously.

By doing it in this way, using Timestamps, I didn’t have any reliance on processes constantly running in the background. Instead, whenever the user looked at it, it just calculated what the timer should display. As this was all saved in the database, it is also easy enough to reload any previous timer into the page should the user navigate away. You only need to add some relevant references, such as the database items it’s relevant to, for you to easily be able to call it back from the database.

This effectively created a timer that could function in the background for any length of time. I even tested this by leaving it playing for over a week, then came back to the page and found it had tracked the time perfectly. Naturally, it only tracks offline time if the timer isn’t paused when you leave the site, as it calculates it from the “Last Resume”.