It's been over a year since ActiveStorage was announced, but it hasn't replaced the traditional method (?) CarrierWave, and there seems to be controversy over which one to use. (I was using Active Storage somehow.)
Basically, in cooperation with validation and cloud storage, you can do both with different procedures, and the setting procedure and the amount of code written do not change so much, so it is not a definitive criterion for judging whether it can be used or not It looks like it.
However, I decided to use Carrie Wave for application development this time, so I will make a note of the reason.
-** Use Carrier Wave when writing views in vue.js **
--The difference between using erb and not is whether you can use <% =%> in HTML. As a premise of Active Storage, when inputting with form_with with <% =%> or displaying an image with @image, the feature is that you can write less code description of the controller by describing the image processing in this. .. ――In other words, when it comes to processing and saving images without using <% =%>, it is difficult to know where to write a program for image processing. (It's not impossible, but there is no merit to use active storage with a lot of trouble.) ――In that respect, with the method using CarrierWave, a class called CarrierWave :: Uploader is generated, and it is easy to understand that you should write the code to process the image here. (To be exact, image processing is the job of MiniMagick, but please interpret it well)
--When active storage is introduced, two models, Blob and Attachment, are automatically generated, and the image data is stored in Blob and linked by Attachment. ――It would be nice if this was intuitively easy to understand, but it is very difficult to understand how to specify the image data when recalling or editing an image. (Especially if you use it like calling an image from vue.) ――On the other hand, if you use CarrierWave, you can write URL generation and file acquisition with Carrierwave's Uploader, upload images directly to AWS S3, and intuitively write a model that holds only the URL.
--The story of switching image management from Active Storage to Carrier Wave
--[Rails6] How to upload images to GCS without using Active Record (Active Storage) with CarrierWave
--Should you use the new Active Storage feature coming from Rails 5.2?
I examined it with a fair eye, but there are many opponents of active storage ...
I develop apps within the free frame of heroku, so I'm in trouble if I frequently rewrite data.
I decided not to use Active Storage, but there is a convenient part because it can be implemented speedily by using Acive Storage.
--Allow active Admin to save images (using ckeditor) ** This is a very useful technique during development. ** **
--Save the image in its raw state and adjust the size when it is displayed. (Specified by variant)
--I write the contents of view in vue.js instead of writing it in erb. The reason is that I personally think that views should be specialized in displaying text and images, so I don't like the way to program in HTML like Rails views. ――Needless to say, when using vue, <% = form_with%> etc. cannot be used in HTML, and the front side and back side communicate with API using axios. --Save the image by encoding with Base64, and display the image by specifying the image link. (I will write this method in another article)