rails / hotwire

Skroutz contributes to Hotwire's upstream

As we mentioned in a previous post, we have started to investigate Hotwire and its techniques, which claim to bring the speed of a single-page web application without writing any JavaScript. It seems that Hotwire, especially Turbo, keeps its promise by providing useful tools which make your application more dynamic, without having to write almost no custom JavaScript.

From our experience with Turbo so far, we found Turbo-Frames to be very handy and can be easily used out of the box. But, as Hotwire is a relatively new tool, we often come across to situations where something seems to be missing, or it doesn’t work as it is supposed to. Skroutz’s engineers always look for opportunities to contribute to open source projects, and this seemed to be a perfect opportunity, so we proceeded by opening some pull requests to the Hotwire’s repo.

Now, let’s take a look at the pull requests that have already been merged and see what problem, each one of them, tries to solve.

Including url in turbo:before-fetch-request event

Pull request #289 by Christos Trochalakis

Turbo fires the turbo:before-fetch-request before it issues a network request. Let’s say that we have multiple Turbo-Frame elements in the page and each one of them, uses a different endpoint to update its contents. Let’s also say that we have the following event listener attached to the document:

document.addEventListener('turbo:before-fetch-request', handleBeforeFetchRequest);

Before #289 got merged, we didn’t have a way to distinguish each one of those events. We just knew that some Turbo element issued a network request. By making available the url to which the network request gets issued, from the respective event, we can add any custom logic that handles the different urls.

For example, we can do this:

const handleBeforeFetchRequest = ({ detail: { url } }) => {
  switch (url) {
    // handle different urls
  }
}

Adding the target element to turbo:before-fetch-(request|response)events

Pull request #367 by John Kapantzakis

Docs update regarding #367

Similarly to turbo:before-fetch-request, turbo:before-fetch-response fires after the network request completes. Those events used to get fired on the document and we couldn’t identify the element that caused the network request / response, from an event listener attached to the document.

This PR adds the target element to the turbo:before-fetch-request and turbo:before-fetch-response events, so that we can listen for those events coming from specific elements, like this:

myTurboFrame.addEventListener('turbo:before-fetch-request', handleFetchRequest);

Introducing turbo:frame-render and turbo:frame-load events

Pull request #327 by John Kapantzakis

turbo:frame-load cherry-picked from #59

Docs update regarding #327

Lifecycle events were missing from Turbo-Frames until turbo:frame-render and turbo:frame-load were introduced, and gave us the opportunity to hook various handlers on those events.

These get fired as soon as the Turbo-Frame element has rendered its contents and when it has finished loading, respectively. Furthermore, these events get fired on the respective Turbo-Frame element, rather than on the document, making it easier to target specific elements.

myTurboFrame.addEventListener('turbo:frame-render', handleMyTurboFrameRender);

const handleMyTurboFrameRender = ({ target }) => {
  target.querySelectorAll('.elements-inside-frame').forEach((elem) => { ... })
}

Introducing test runner options

Pull request #311 by Christos Trochalakis

This PR doesn’t affect the tools that Turbo provides, directly, but it makes the development of Turbo’s features a lot easier, by adding some options to the testing process. Specifically, it adds the --grep and --environment options.

You can use the --grep option when you want to target a specific test case.

$ yarn test --grep 'triggers before-render and render events'

You can use the --environment option when you want to set the environment on which you want to perform the tests.

$ yarn test --environment 'Firefox'

Avoiding race condition between visit tests

Pull request #310 by Christos Trochalakis

This is another PR that improves the development experience of Turbo features by fixing a race condition that was happening when the page location was changed asynchronously and an event logs array was getting out of sync. You can inspect the PR for more details regarding the relevant changes.

Summary

Summing it up, here’s a list of the commits sent upstream so far: