Add an option to transform AS variants in the background

[shouichi]

Motivation / Background

ActiveStorage variants are transformed on the fly when they are needed
but sometimes we're sure that they are accessed and want to transform
them upfront.

Detail

preprocessed option is added when declaring variants.

class User < ApplicationRecord
  has_one_attached :avatar do |attachable|
    attachable.variant :thumb, resize_to_limit: [100, 100], preprocessed: true
  end
end

Additional information

See also #47387.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[hahmed]

eager_transform: true tbh i'm not really too sure about the naming here.

The variants are being loaded on demand, however they will be pushed to the job queue and processed in due course. In active record terms, when the records are eager loaded they are batched together with the original record(s). This naming is a bit too close to AR.

[shouichi]

How about transform_later or process_later?

[shouichi]

@hahmed is there anything I need to do to get this merged? Is renaming eager_transform to transform_later or process_later sufficient?

[hahmed]

@shouichi transform_later sounds good but maybe even transform: true would work? This is on my list to review, but won't be able to get to it for a couple of weeks unfortunately.

Would need someone from core/committer to review + merge, maybe try discord?

[shouichi]

Thank you! I'll share this PR in discord.

[casperisfine]

The feature makes sense to me, but I agree that the naming is weird. Maybe transform_immediately: true?

That said, CI is failing for legitimate reasons.

[shouichi]

• Options hash for variant method are passed to the variant processor. So I want to avoid a collision.
• I want to make it clear that the processing happens in the background.

So personally I prefer transform_later or process_later. It won't collide with the options for the variant processor (I believe). It's clear that the processing happens in the background because of the naming similarity with ActiveJob's perform_later.

Side note: ActiveStorage document uses the term "transform" and "process". I'm not sure which term to stick with.

[shouichi]

@hahmed @casperisfine I changed the option name to transform_later. Could you take a look?

[casperisfine]

I still think the naming is a bit weird. I do understand the reasoning of using _later to map with Active Job, but what is weird is that the default behavior is already "delayed" as it will be transformed on first access.

Hence why I think something in the lines of schedule_transform: true would be better.

[shouichi]

The term schedule gives me the impression that I can schedule the transformation at a specific time.

How about preprocessed: true?

[casperisfine]

How about preprocessed: true?

Not bad. Perhaps pretransform: true ? But may seem a bit weird. I'd be ok with either of these.

[casperisfine]

cc @byroot

[shouichi]

I decided to use preprocessed because there are far more search results than pretransform.

[tosbourn]

I'm really excited to use this feature; Any idea when it will get merged into stable? I had hoped to see it in 7.0.8

[skipkayhil]

this feature

New features get released with the next major version, so it will be available in 7.1 (7.0 is bugfix only)

[tomrossi7]

@shouichi I am looking to extend this with an option to transform immediately, create_on_attach. Is that something you would use in your ecosystem as well?

[shouichi]

Though the apps I manage don't need the feature, I can imagine some apps need one. For example, in a chat-like app, when someone posts an image, many users access the image thumbnail simultaneously. In that case, it makes sense to create a thumbnail before broadcasting.