Consider promoting variants to something more complex?

Variants are pretty simplistic, and don't understand anything about themselves. This is maybe a naive implementation and to be more flexible, variants could be expanded to be an object.

When a variant is registered, it's really being defined as two callback chains. One callback chain for the variant callbacks (e.g. before_variant(:red)), and one callback that's referred to as the variant steps (this is what can be overridden when running the experiment (e.g. experiment.on(:red) { "overridden red" }).

Because of this, variants are largely viewed as a name, and a "functionality." I use the term functionality here, because since it's just a callback, the functionality could be a proc/lambda, or a method, and can be overridden.

class MyExperiment < ActiveExperiment::Base
  control { }
  variant(:red) { }
end

MyExperiment.variants # => {:control=>:control_variant, :red=>:red_variant}

That's variant name => variant callback chain. I realized when adding the Unleash adapter, variants could have additional information/metadata associated with them, and it would be nice to have a place to put that information. For Unleash, variants have payload, and weights etc. ActiveExperiment shifts the variant weights and that logic off to the rollout, but I wonder if it's not a bad idea to introduce the concept of a variant being a Variant early.

So, what would that look like? Maybe pass some options through? Accept a class that inherits from a base Variant class? I want to explore this more, but some ideas:

class MyExperiment < ActiveExperiment::Base
  variant(:a_block) { "a block" } 
  variant(:a_method, :my_variant_method)

  # option 1?
  variant :an_instance, MyCustomVariant.new(payload: "foo") { "a variant block" }

  # option 2?
  variant :an_instance_via_proc, :my_variant_method, using: { MyCustomVariant.new(payload: "foo", name: :an_instance_via_proc) } 

  # option 3?
  variant(:with_options, options: { payload: "foo", weight: 30 }, using: MyCustomVariant)

  private

  def my_variant_method
    "my_variant_method"
  end
end

I wanted to open this issue and think on it. I think I like option 3.

Start by reading the variant registration API and the Unleash adapter referenced in the issue, then trace how variant callback chains, steps, payloads, and weights are represented. The issue needs a settled design among the proposed Variant options before implementation can be considered done.