ActiveStorageが公表されてから1年以上経ちますが、いまだに伝統的手法(?)であるCarrierWaveに置き換わることはなく、どちらを使うか論争が続いているようです。（私は何となくActiveStorageを使っていました。）
基本的にバリデーションやクラウドストレージとの連携においては、手順の違いこそあれどちらもできますし、設定手順やコードの記述量もそれほど変わらないので、使用可否を判断する決定的な基準にはならなさそうです。
ですが、今回アプリ開発においてCarrieWaveを使おうと決めましたので、その理由をメモしておきます。
結論
- viewsをvue.jsで書く場合は、Carrier Waveを使う
理由1 erbを書かない場合はactive storageの強みを活かせない
- erbを使うか否かの違いは、HTML内に<%= %>を使えるかどうかです。
Active Storageは前提として、<%= %>でform_withで入力したりや@imageとかで画像表示をする時に、この中に画像の処理を記述することで、controllerのコード記述を少なく書けるのが特徴です。 - 言い換えれば、<%= %>を使わずに画像を処理・保存するとなると、どこで画像処理などのプログラムを記述すれば良いかわかりにくいです。（できなくはないですが、わざわざしんどい思いをしてactive storageを使うメリットがありません）
- その点、CarrierWaveを使う方法では、CarrierWave::Uploaderというクラスが生成され、ここに画像の処理するコードを記載すれば良いんだなとわかりやすいです。（正確には画像加工はMiniMagickの仕事ですが、まあ良しなに解釈してください）
理由2 active storageはデータ構造がわかりにくい
- active storageを導入すると、BlobとAttachment の2つのモデルが自動的に生成されて、画像データはBlobに保管してAttachmentで紐づけることになります。
- これが直感的に分かり易ければ良いのですが、画像を呼び出したり編集したりする時に、どうやって画像データを指定すれば良いのか非常にわかりにくいです。（vueから画像を呼び出すような使い方をしていればなおさら。）
- 一方でCarrierWaveを使うと、URL生成やファイル取得はCarrierwaveのUploaderで記述できますし、画像はAWS S3に直接アップして、モデルはURLだけ保持するような書き方が直感的にできます。
ActiveStorage vs CarrierWave論争
- 画像管理をActiveStorageからCarrierWaveへ乗り換えた話
- [Rails6] CarrierWaveでActive Record(Active Storage)を使用せずにGCSに画像をアップする方法
- Rails5.2から入る新機能ActiveStorageを使うべきか?
公平な目で調べましたが、active storage反対派が多いですね・・・
私はアプリ開発はherokuの無料枠内で開発していますので、データの書き換えを頻繁にされると困ります。
Active Storageでできること
Active Storageは使わないことにしましたが、Acive Storageを使えばスピード実装できるので便利な部分もあります。
- Active Adminで画像を保存できるようにする（ckeditorを使う）
開発時にはすごく使える技です。
- 画像の保存は生の状態で行い、表示の時にサイズを整える。（variantで指定）
私の設計
- 私はviewの中身をerbで書かずにvue.jsで書いています。その理由は、個人的なこだわりとして、viewsはテキストや画像の表示に特化するべきであると考えているため、RailsのviewsのようにHTML内にプログラムを書くやり方は好きではないからです。
- 言うまでもなくvueを使う場合は、HTML内に<%= form_with %>などは使えず、フロント側とバック側はaxiosを使ったAPIでやりとりをしています。
- 画像の保存はBase64でエンコードして保存、画像の表示は画像リンクを指定して表示させます。（このやり方は別記事で書きます）