render_async Adds Support for Rails Turbo
Tags: rails, ruby
Published: 2021-03-13 20:51:29

---
title: render_async Adds Support for Rails Turbo
published: true
date: 2021-02-23 00:00:00 UTC
tags: rails, ruby
canonical_url: https://pragmaticpineapple.com/render-async-adds-support-for-rails-turbo/
---

This blog post will explain all new features and how they came to be in the latest [2.1.9 version](https://github.com/renderedtext/render_async/releases/tag/2.1.9).

![Turbo](https://pragmaticpineapple.com/static/e8f6002245e679b6343e9e1af5f7f77e/1c72d/cover.jpg "Turbo")

Photo by [Charlotte Coneybeer](https://unsplash.com/@she_sees?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/turbo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

We will start of with the new Turbo support.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#%EF%B8%8F-turbo-support)⚡️ Turbo support

 ![Turbo dancing](https://pragmaticpineapple.com/f8aae8d149e81a19302d9ba1cc0d17ca/turbo-kid.gif)

 render\_async joins the Turbo party

The new [Turbo](https://github.com/hotwired/turbo-rails) is actually a continuation of the [Turbolinks](https://github.com/turbolinks/turbolinks). If you forgot about Turbolinks - it allows you to bring a single-page experience into your application without too much fuss.

What Turbo is doing is following up on the idea of Turbolinks with more concepts. With Turbolinks, you can navigate the pages, and the Turbolinks would cache them, so you feel that everything is smooth like in a single-page app. Moving around the browser’s history like that was revolutionary back in the day (I believe it is still interesting).

But how does it really work? The parts of the page are cached so when you navigate back to the page, you instantly get a preview until the actual page request is finished. This draws the illusion of a single-page app. Now, this concept is extracted into _Turbo Drive_. The [Turbo Drive](https://turbo.hotwire.dev/handbook/drive)part of the Turbo is what we are interested in.

But how does it really work? The pages are cached, so when you navigate back to the page, you instantly get a preview until the actual page request finishes. By showing a preview of the page, Turbolinks draws the illusion of a single-page app. Now, this concept moved into Turbo Drive. And we are precisely interested in the 
 [Turbo Drive](https://turbo.hotwire.dev/handbook/drive) part of the Turbo.

All this magical rendering is where render\_async comes in. Since render\_async makes async requests after the page loads, we have to support this somehow. When you visit a page that has Turbo enabled and is cached inside Turbo, you will first get a preview of the page. In the meantime, a request is sent to the backend to get the new version of the page. Then, when the new version arrives, it will replace it with the preview version.

To handle these effects and make render_async work, we first suggested to put `data-turbolinks-track="reload"` or now `data-turbo-track="reload"` to the render\_async calls. These data attributes stop Turbo from doing its magic, which is not something every user wants. Then, a clever contribution from [Mbuckley0](https://github.com/Mbuckley0) made it possible to have the Turbo functionality and have render\_async working.

The idea is to have render\_async work after `turbo:load` happens - or in plain words - when Turbo loads the page. But, we also need to stop render\_async from performing when the preview is showing with the Turbolinks. All you need to do is set the `turbo` configuration like so:

```rb
RenderAsync.configure do |config|
  config.turbo = true # Enable this option if you are using Turbo
end
```

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#-future-turbo-work)🔮 Future Turbo work

Yes, the render\_async is working with the Turbo. But, we want to make it work better. Right now, there is a slight itch that’s been bugging other users and me. After you get the Turbo preview and the page replaces the preview, the render\_async call performs and replaces the preview values.

It probably sounds a bit confusing, so I will show a GIF that should illustrate it better:

![render_async Turbo loading issue](https://pragmaticpineapple.com/e76dc7285145c61582c9d95d051be40d/render-async-turbo.gif)

Notice how when we click on either of the links, we get the preview of the page with the ”`render_async here :wave:`” text. Then, the page is fetched from the backend and render\_async is triggered once more. At that point, we see the ”`...Loading /render_async/wave`” part. And finally, after the wave request finishes, the page is back to its state as in the preview.

A future improvement would be if we could skip the showing of the loading indicator for render\_async. It would be nice to show a preview inside the render\_async container until render\_async fetches the freshest data from the request.

If you have any ideas or would love to contribute, let me know on our [Discord server](https://discord.gg/SPfbeRm) or ping me on [Twitter here](https://twitter.com/nikolalsvk). Thanks a lot.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#-minor-bug-fix)🐛 Minor bug fix

There was a problem with the configuration options in the gem. We fixed it easily by a simple rename, but the weird thing is how it was almost unnoticed. You are good now to use various [configuration options](https://github.com/renderedtext/render_async#configuration-options).

There were also small updates to the documentation, but nothing too drastic there - just small typo fixes.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#final-thoughts)Final thoughts

That is it for this version. Thanks, everyone, for contributing. Consider joining the [Discord server](https://discord.gg/SPfbeRm), that way, we can make it even better.

Also, feel free to share this on Twitter with friends and coworkers below:

{% twitter 1364196876350853128 %}

 <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

I will see you in the next one, cheers.