<AbTestOptimizelyXExperiment experimentId />
npm install @s-ui/abtesting-optimizely-x``js`
`sh`
npm install @s-ui/abtesting-optimizely-x --save
Navigate to: https://app.optimizely.com/v2/ > Edit Experiment > API Names
`javascript`
import OptimizelyXExperiment from '@s-ui/abtesting-optimizely-x'jsx`
Component will obtain OptimizelyX's decision for given experimentId and display chosen variation.
If no variation is provided or OptimizelyX API is unavailable, defaultVariation will be displayed.
If you need to use an empty variation, do not use component as you will get a lot of warning messages in the console component and pass by the experiment's props.
`jsx`
import OptimizelyXExperiment, {EmptyVariation} from '@s-ui/abtesting-optimizely-x'
`jsx`
The following data is set in a plain object to the experiment context.
- All props passed to OptimizelyXExperiment (see limitations at Known issues section).
- experimentId: The experimentId of the experiment, e.g. 8470306415.true
- isActive: when a decision has been made by optimizely.true
- isDefault: when the chosen variation is the default one.true
- isVariation: when the chosen variation is not the default one.true
- isVariationA: when the chosen variation is A.true
- isVariationB: when the chosen variation is B.true
- ...
- isVariationN: when the chosen variation is N.true
- isWrapped: when the current component has OptimizelyXExperiment as a parent (direct or not).8463707014
- variationId: The variationId of the chosen variation, e.g. .A
- variationName: The variationName of the chosen variation, e.g. (more about this below).
So for a given experiment:
`js`
The experiment context can be consumed at any child level by using the useExperiment hook:
`js
import {useExperiment} from '@s-ui/abtesting-hooks'
const NiceComponent = () => {
const {isActive, isDefault, isVariation, ...} = useExperiment('myexperiment')
}
`
IMPORTANT: Note the 'myexperiment' value passed to name prop of the component which is also used as an argument in useExperiment consumer. This is the way for the package to keep a unique internal context instance per experiment in order to avoid undesired overridings when multiple experiment contexts live within the same hierarchy scope. So if you want multiple experiment contexts to coexist just pick different names for them and you will be ok.
You may need to check which variation has been chosen down in the children, specially when the experiment has 3 or more possible variations. For the sake of simplicity, OptimizelyXExperiment will automatically assign an uppercase letter for each variation based on the order of children, but you could override it by using variationName prop directly into a variation.
`js`
Considering the above example, if we look into TestedComponent we can access the chosen variationName from the experiment context through the useExperiment hook:
`js
import {useExperiment} from '@s-ui/abtesting-hooks'
const TestedComponent = () => {
const {variationName} = useExperiment('myexperiment')
// if 1st variation is chosen: variationName → "A"
// if 2nd variation is chosen: variationName → "B"
// if 3rd variation is chosen: variationName → "maneko" (overriden)
// if 4th variation is chosen: variationName → "D"
// ...
// if Nth variation is chosen: variationName → Nth letter in alphabet
console.log(variationName)
}
`
Also, boolean keys are provided for simplicity:
`js
import {useExperiment} from '@s-ui/abtesting-hooks'
const TestedComponent = () => {
const {
isVariationA,
isVariationB,
isVariationManeko,
isVariationD
} = useExperiment('myexperiment')
// consider 'B' variation is chosen by optimizely, then:
console.log(isVariationA) // → false
console.log(isVariationB) // → true
console.log(isVariationManeko) // → false
console.log(isVariationD) // → false
}
`
While developing in localhost you may need to test different variations:
`js`
In the above example, "Dogs" variation will be always displayed. You can also use variation name instead:
`js`
NOTE: Since this prop is meant to be used in development environment only, forceVariation is just ignored in production as a preventive measure.
This prop is similar to forceVariation prop, but it simulates an actual activation, so default variation is displayed first and then it gets swapped by the passed variation after X milliseconds (the number of milliseconds can be changed via forceActivationDelay prop). This is the closest behaviour to an actual experiment that you could configure in Optimizely's panel because you get the same "flash" effect. This way you can check that nothing gets broken despite the flash, without the need of actually configuring an experiment in Optimizely's panel.
`js`
In the above example, "Cats" variation will be displayed first, then after a few milliseconds "Dogs" variation will be definitely displayed. You can also use variation name instead:
`js`
NOTE: Since this prop is meant to be used in development environment only, forceActivation is just ignored in production as a preventive measure.
Wanna take a quick look into a variation? You can add forceExperiment query param to the URL on the address bar, providing experiment name and variation you want to activate as a value:
`
?forceExperiment=
For example, an experiment whose name is myexperiment with a biggerButton variation would look like this:`
?forceExperiment=myexperiment|biggerButton
Note that this gets stored into the session storage, so the variation will show up through the entire navigation process until the tab gets closed. This is intended to avoid unnecessarily repeating the process of adding the mentioned query param.
This way, UX or other roles can check variations whenever they like without the need of setting up and publishing the AB Test on Optimizely Panel, which is slower, cumbersome and wastes traffic from the plan.
OptimizelyX web API is used to obtain the decision, not the fullstack one. It means that on server side rendering, the default variation will be rendered as Optimizely is not available. Then, when component re-renders on browser, the decided variation will be displayed. So, user may experience some clipping, which could alter test results...
Moreover, depending on how you load Optimizely's snippet, the clipping may also happend in SPA mode (without SSR):
* If you load the snippet as blocking script in
(recommended by Optimizely itself), no clipping should appear on SPA, as Optimizely will be present on first render.
* If you load Optimizely later (async), the default variation will be rendered on first render. The component will wait for Optimizely until it's loaded (5 seconds max) and then render the decided variation. In that case, user may also experience some clipping.$3
All the props passed to OptimizelyXExperiment component will be automatically set on the experiment context. This is why experimentId is available in the context.
`js
``In the above example, propX and propY will be available in the context too, but if they change they will not be updated in the context due to technical limitations that would cause unnecessary renders and potentially create other issues.
Extra props can certainly be passed to OptimizelyXExperiment in order to get extra data in the experiment context, but keep in mind that they cannot change.