You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
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:I wanted to open this issue and think on it. I think I like option 3.
The text was updated successfully, but these errors were encountered: