You can setup and configure project widgets through our admin panel, but the widget has many more "hidden" options than what meets the eye. Let's look at some of them!

Setup on your page

If you setup a project widget through our admin, you can generate an embed that looks something along these lines:

<div id="bookingjs"></div>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js" defer></script>
<script src="https://cdn.timekit.io/booking-js/v1/booking.min.js" defer></script>
<script>
  window.timekitBookingConfig = {
    widgetId: '6a6c24ce-41a6-4114-9c15-de9ec3d92630'
  }
</script>


Here's what happens when you paste it on a webpage:

  1. jQuery is loaded & the widget library is loaded from our CDN servers
  2. Based on the unique widgetId, it will fetch the corresponding config from our servers with all the settings you made through our admin
  3. If you supply additional config settings, it will merge them into the config it got from our server above. This means that you can overwrite or add extra settings to the project widget through code!
  4. The widget is rendered in all its glory

Step #3 is the key here. Let's explore how this works.

Adding additional config settings

First, go ahead and check out our readme for booking.js on Github - it serves as a reference for all possible options you can throw at it.

Now, do you see the window.timekitBookingConfig part in the example above? This is a JavaScript object that contains configuration settings that the project widget will use.

Let's start of easy by changing the display name that's shown on the project widget header:

<script>
  window.timekitBookingConfig = {
    widgetId: '6a6c24ce-41a6-4114-9c15-de9ec3d92630',
    name: 'Marty McFly'
  }
</script>

That's it! Even though you already specified a display name through our admin, the value that you provide here takes precedence, i.e. "Marty McFly" is shown.

Passing extra parameters to the API calls

The project widget is essentially just a pretty UI that calls our API for data. The API requests are handled by the widget internals, but you can specify extra parameters that should be sent along the requests. 

Sounds like gibberish to you? Here's an example of how to use the start  parameter of our FindTime endpoint to specify from which point in time that the availability algorithm should start to look for timeslots:

<script>
  window.timekitBookingConfig = {
    widgetId: '6a6c24ce-41a6-4114-9c15-de9ec3d92630',
    timekitFindTime: {
      start: '3 days'
    }
  }
</script>

The above will ensure that you have 3 days of buffer time before available timeslots are shown. 

There are two config keys which correspond 1:1 with our API endpoints which you can override:

Common use-cases

There's quite a lot of "hidden" features you can unlock with this approach. Here's some of the most popular:

Most of the above is already documented in the readme for booking.js on Github but we're working on more easy-to-digest articles that explore each of them in detail 🙌

Did this answer your question?