どうやらTurbolinkが非同期通信に悪影響を与えていた模様(Rails, JavaScript)

今回取り組んだのはいいね機能の非同期通信。

非同期通信は4日前からずっと未解決の問題があった。
それはJS形式のリクエストが送れないこと。

link_toやform_withではデフォルトでJSリクエストが送信される。
しかしなぜかブラウザがリロードされるHTML形式のリクエストが送られてしまい、この問題の原因究明に悩まされた。

今日素のJavaScriptで非同期通信を実装していたらその原因を突き止めることができた。この問題の原因はTurbolinkにあった。

※10/29追記
form_withがHTML形式のリクエストを送信する根本の原因はTurbolinkではなくRails6.1のデフォルトの設定にあることが判明しました。
参照記事：Rails6.1以降のform_withのデフォルトはlocal: tureだった！

Turbolinkは一度訪れたことがある画面や戻るボタンを押した時にキャッシュをうまいこと残してくれて画面遷移を高速にしてくれるライブラリだ。

しかしログを観察していると、このライブラリは画面遷移をするときに
コンパイル済みのJSファイルを読み込んでいなかったのだ。

試しに画面遷移した直後に非同期通信を実装済みの機能を使ってみたら、予想通り動作しなかった。このTurbolinkを一部無効化して再度動作確認をしたら正常に動作した。

そして今までできなかったJS形式の通信に挑戦してみたら正常に動作させることができた。

↓JS形式で送信されたリクエスト

↓HTML形式で送信されたリクエスト

やっとのことでJqueryを用いた非同期通信に取り組むことができた。

現在は変数の受け渡し時に書く、locals: { favorites: @favorites, job: @job })
のような記述にまだ慣れが必要そうだ。

明日も引き続きJqueryの扱い方を学んで、非同期通信の拡充を目指したい。