I do agree that keeping it to one view is best in this case, but wanted to show you how to go about passing data from the “controller space” into background jobs:
This is the example, which implements it:
- Create a
device_variantin aCurrentmodel, i.e.
class Current < ActiveSupport::CurrentAttributes
attribute :device_variant
end
- Set
device_varianton the controller level in a before action
Current.device_variant = request.variant
- Add the current parameter to all jobs - see the
#serializefrom the example
def serialize
super.merge('device_variant' => Current.device_variant)
end
- Finally, access
device_variantas in the example code, or I think it should also be available directly in the job withself.arguments, but I haven’t tried it.