Turboでプログレスの更新は難しいかも
先週は風邪をひいてしまいしばらくダウンしていた。
開発のモチベーションはなかなかあがらないなか、風邪をひいてまるまる一週間近く停滞していた。
趣味で書いているコードは基本的に一度離れるとあとから手をつけたくなくなる性分なので、基本的には一気にひとつのプロジェクトを開発するようにはしている。 今回はたまたま同じコードで得た気づきを残そうかと思う。
他のブログでも度々話題にあげているとおり、私はよくプログレスバーを使うことが多い。 実装によってまちまちなのだが、最近はStimulusとActionCableを用いてプログレスバーなんかを実装した。 おおむね挙動は満足している。
もしそれをTurboで実装したらどうだろうか。
バックエンドはRails 7.1で、Expressのサーバーを介してfetchした結果をupdateして、broadcast_replace_later_to
で更新するみたいなコードだ。
実装そのものはとても単純である。 StimulusのようにDOMを直接操作しないので、変更に強い。 ただページ遷移などを繰り返すといくつか挙動が怪しいときがある。
キューが実行中のまま次のキューが延々と積み重なってスタックしてしまう。 私の場合は1秒毎の画面更新を行うので、1秒ごとにエンキューされ続ける。 通常時であれば一瞬でタスクが完了するので気にならないものの、こうなってしまうと他のジョブを実行しようとしても現在行われているタスクが完了するまでは次のタスクに移行できない。 こういう時を想定するとジョブに優先度という概念や、別プロセスでworkerを実行するということが理解できる気がする。
調べてみると Sidekiq.strict_args!(false)
というコードを追加しておくとうまくいくようだ。
ただリンク先を見てみるとSidekiqのActiveJob側がstrict_args
に対応するというPRもあるようなので、もしかすると気休めかもしれない。
問題の挙動が直った気もするが、再現しにくくなっただけで完全に防げるというわけでもない気がする。
少なくとも最新のRailsにアップデートするまではこのコードを加えておいてもいいかもしれない。