Tech Racho エンジニアの「?」を「!」に。
  • Ruby / Rails関連

Rails: HotwireのTurbo Streamsとリダイレクトのどちらを使うか?(翻訳)

概要

元サイトの許諾を得て翻訳・公開いたします。

日本語タイトルは内容に即したものにしました。

Rails: HotwireのTurbo Streamsとリダイレクトのどちらを使うか?(翻訳)

リダイレクトとTurbo Streamsのどちらを使うかで迷ったことはありますか?

常にリダイレクトを使うべきなのか、それとも常にTurbo Streamsを使うべきなのでしょうか?

以下の機能を見てみましょう。これはカンバンのダッシュボード内で、状態を表すテーブル間のタスクを移動します。

カンバンの例

この機能を実装するのに、リダイレクト方式(下左)またはTurbo Streams方式(下右)のどちらかを利用できます。

🔗 最初にリダイレクト方式を見てみる

リダイレクト方式は、開発者にとって楽で、テスト可能で、何よりも生産性が高いという特徴があります。

こうした手堅いメリットがあるので、とても使いたい気持ちになりますし、私もリダイレクトは用途によっては悪くない選択だと思います。さらに、新しいRailsでは最初にリダイレクト方式を選んでおく方がよさそうです。私がリダイレクトで本当に気に入っているのは、このささやかなメリットなのです(同僚のTomekもこのささやかなメリットに気付きました)。数年前にRailsアプリで伝統的なSSR(サーバーサイドレンダリング)に踏みとどまり、当時流行ったSPA(シングルページアプリケーション)に飛びついていなければ、Railsアプリケーションを更新するだけで、手間を(ほとんど)かけずにUXを改善できます。

🔗 問題が生じた場合

kanbanエンドポイントはテーブルをレンダリングするためのものだとします。タスクがあるテーブルから別のテーブルに移動すると、このエンドポイントでフローをリダイレクトします。このkanbanエンドポイントのレスポンスが遅くなると問題が発生します。

遅くなる理由は何でしょうか?🤔
(遅くならないことってあるんでしょうかね?😛)

アプリケーションのページは、時とともに機能が積み上げられて肥大化していく傾向があります(すべてのページがそうとは限りませんが)。小さな機能をぽつりぽつりと追加していくうちに、特定のページに機能をインクルードすることが重要であることが判明したりします。やがて、ページで読み込まれるデータが大量になってレンダリングに長時間かかるようになってしまいます。

そうなると、短時間で完了するはずの操作が成功してからリダイレクトが発生すると、サーバーは全クエリを実行して、ページ全体をレンダリングするために必要な全データを取得しなければならなくなり、UXは低下してしまいます。
改善方法はあるはずです!

ユーザーにしてみれば、あるテーブルから別のテーブルに行が移動して、状態が更新されればそれでよいのです。

これと同じような状況になったら、リダイレクトの代わりにTurbo Streamsを使うのが最適です。

🔗 他に注目すべき2つの側面

パフォーマンス以外にも注意すべき点がいくつかあります。

🔗 1: 送信されるデータの総量

リダイレクト方式にすると、ページ全体がネットワーク経由で送信されます。それで問題にならないページもありますが、冒頭で述べたように、ページの機能やデータや複雑さは時とともに増大する傾向があります。ネットワーク経由で送信されるデータ量が多すぎることに気づいたら、一度確認したうえでTurbo Streamsの利用を検討するのがよいでしょう。

🔗 2: スクロール位置を維持するかどうか(morphを使わない場合)

morph機能は、Turboを最新バージョンにアップグレードしていないと利用できません。そのため、この小さなGIFで発生したのと同じような操作をページで行うたびに、スクロール位置を維持せずに最上部までスクロールします。この振る舞いはおそらくユーザーから見えずに済みますが、もし見えてしまう場合は、Turbo Streamsで解決できるでしょう。

🔗 3: 精密な制御が必要かどうか

サーバーの応答方法を精密に制御したい場合は、Turbo Streams方式が最適です。

🔗 結論

個人的には、自分が携わるアプリケーションならTurbo Streams方式を使う方が好みです。しかしその主な理由は、最新でないレガシーアプリケーションだからです。

まっさらのアプリケーションであればリダイレクト方式を検討するでしょう。私が本記事で書きたかったのはこのことだったのです 😉。

また、リダイレクト方式は開発者の幸せにつながる点も好みですし、TurboとRailsが目指す一般的な方向性もよいと思います。

私にとって開発者の幸せが最大化されるとき、それはJavaScriptを使わずにアプリケーションをインタラクティブにできるときなのです 😂。

つまり、これは実に大きなメリットなのです(Stimulusのコードが若干入ってくる点を別にすれば)。

関連記事

イベント設計のシンプルなヒューリスティック「誰が誰を呼ぶべきか?」(翻訳)


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。