Update Opticks to support Optimizely's JS SDK v5.3.2

.changeset/silly-schools-hunt.md

@@ -0,0 +1,14 @@
+---
+'opticks': major
+---
+
+Upgrade Opticks optimizely integration to support Optimizely's JS SDK v5.3.2
+
+Non-breaking changes:
+
+- `getOrSetCachedFeatureEnabled` is renamed to `getToggleDecisionStatus`
+
+Breaking changes:
+
+- `__checkIfUserIsInAudience`, an internal from Optimizely got updated to `checkIfUserIsInAudience`. Hence you need the version 5.3.2 of the JS SDK to run this version of opticks properly
+- Removed deprecated `booleanToggle` and `getEnabledFeatures` and all mentions of it

README.md

@@ -14,24 +14,18 @@ The library consists of two related concepts:
 
 At the heart of our experimentation framework is the `toggle` function.
 
-- `toggle` toggles that switch between multiple experiment variants (a/b/c/...)
-- `booleanToggle` toggles that turn functionality on or off (feature flags)
+A toggle allows you to switch between multiple experiment variants (a/b/c/...)
+and also turn functionality on or off (feature flags)
 
 It can be used in a variety of ways:
 
 1.  Reading the value of the toggle (boolean, or a/b/c for multi toggles )
 1.  Execute code or for a variant of a multi toggle
 1.  Execute code when a boolean toggle is on
 
-We use React at FindHotel and some of the code examples use JSX, but the code
+We use React at vio.com and some of the code examples use JSX, but the code
 and concept is compatible with any front-end framework or architecture.
 
-The `booleanToggle` is the simplest toggle type to use for feature flagging, but
-it's also the least flexible. As of version 2.0 `toggle` is the default and
-recommended for both a/b/c experiments and feature flags. If you're only ever
-interested in feature flags, read more about [Boolean
-Toggles](docs/booleanToggles.md).
-
 ### Opticks vs other experimentation frameworks
 
 The main reason for using the Opticks library is to be able to clean your code
@@ -64,9 +58,9 @@ See the [Optimizely integration documentation](docs/optimizely-integration.md).
 
 ## Toggles
 
-Toggles can be used to implement a/b/c style testing, instead of on/off values
-as with `booleanToggle`, we specify multiple variants of which one is active at
-any time. By convention the variants are named `a` (control), `b`, `c` etc.
+Toggles can be used to implement a/b/c style MVT testing and on/off feature flags as well.
+We specify multiple variants of which only one is active at any time.
+By convention the variants are named `a` (control), `b`, `c` etc.
 
 ### Reading values
 
@@ -133,7 +127,7 @@ experimentId, then the values for `a`, `b`, etc.
 For instance:
 
 ```
-// simple boolean switch: (you could use a BooleanToggle as well)
+// simple boolean switch
 const shouldDoSomething = toggle('foo', false, true)
 
 // multiple variants as strings

docs/dead-code-removal.md

@@ -14,7 +14,7 @@ winners:
 - winning values are kept
 - for functions, the function body is kept
 
-For the losing boolean toggles and losing multi toggle variants:
+For the losing multi toggle variants:
 
 - losing toggles are pruned
 - if the losing side is a JSXExpression, we clean it up including the variables
@@ -36,15 +36,13 @@ information.
 
 ## Running the codemods
 
-There two codemods supplied with Opticks, one for Boolean Toggles, one for
-Toggles, they can be found in the `src/transform` directory.
+There is a codemod supplied with Opticks, that can be found in the `src/transform` directory.
 
 In order to clean all "losing" branches of the code, the codemods need to know
-which toggle you're modifying, whether the toggle (for Boolean Toggles) or which
-variation (for Multi Toggles) "won".
+which toggle you're modifying, and which variation "won".
 
 Assuming you're running the codemods directly from the Opticks directory in your
-`node_modules`, to declare the `b` side of the `foo` Multi Toggle the winner and
+`node_modules`, to declare the `b` side of the `foo` Toggle the winner and
 prune all losing code in the `src` directory, run the script as follows:
 
 ```shell
@@ -74,28 +72,17 @@ npm run clean:toggle -- --toggle=foo --winner=b
 
 The codemods are designed to work with TypeScript and they expect the `tsx` parser to be used. You can override the parser option from the consuming project to parse code other than TypeScript, but not all patterns might be cleaned up as intended.
 
-### Boolean Toggles
-
-Boolean Toggle clean up works in a similar way, noting the winner accepts a
-string value `'true'` or `'false'`:
-
-```shell
-npm run clean:booleanToggle -- --toggle=foo --winner='true'
-```
-
 ### Overriding the library import settings
 
 By default the codemods make assumptions on the name of the imports to clean,
 namely:
 
 ```typescript
-import {booleanToggle} from 'opticks'
-// or
 import {toggle} from 'opticks'
 ```
 
 You can override these values via:
-`--functionName=myLocalNameForMultiOrBooleanToggle` and
+`--functionName=myLocalNameToggle` and
 `--packageName=myNameForOpticks`
 
 ## Cleaning Examples and Recipes
@@ -132,7 +119,7 @@ const result = toggle('toggleFoo') // 'b'
 ```
 
 A more interesting experiment would execute conditional code based on a multi
-toggle. The trick here is that like Boolean Toggles, toggles accepts
+toggle. The trick here is that toggles accept
 functions that will be executed only for a particular experiment branch.
 
 For example:
@@ -225,8 +212,7 @@ of business logic.
 ### Conditional rendering
 
 The simplest way to render something conditionally is to assign a boolean to a
-variable. Though this is probably better done with a boolean toggle, it's
-possible with a toggle as well:
+variable.
 
 ```typescript
 const shouldRenderIcon = toggle('SomethingWithIcon', false, true)

docs/optimizely-integration.md

@@ -93,11 +93,9 @@ forwarded to Optimizely with each call.
 ### The DataFile
 
 The Opticks Optimizely integration makes some assumptions on how the experiments
-are set up. Optimizely supports two types of flags, "Feature Flags" (Boolean
-Toggles in Opticks) and Experiments (Multi Toggles in Opticks).
+are set up. Optimizely supports two types of flags, "Feature Flags" and Experiments .
 The Opticks library uses certain conventions to wrap both concepts in a
-predictable API, where experiment variations are in the `a`, `b`, `c` format and
-Boolean Toggles return only `true` or `false`.
+predictable API, where experiment variations are in the `a`, `b`, `c` format.
 
 The following is subject to change, but right now Opticks uses both Feature
 Flags and the Experiments concepts of the Optimizely SDK which means you'll need

docs/simple-integration.md

@@ -7,16 +7,6 @@ concern itself with generating a list of toggles or experiments, as there are
 many libraries and services out there doing it well already. It should be easy
 to write an adapter for whichever experimentation service or tool you're using.
 
-## Boolean Toggles
-
-### Setting Toggles
-
-```
-setBooleanToggles({ foo: true, bar: false })
-```
-
-## Multi Toggles
-
 ### Setting Toggles
 
 ```

packages/lib/package.json

@@ -33,10 +33,10 @@
   "author": "Jop de Klein",
   "license": "ISC",
   "peerDependencies": {
-    "@optimizely/optimizely-sdk": "~4.4.3"
+    "@optimizely/optimizely-sdk": "5.3.2"
   },
   "devDependencies": {
-    "@optimizely/optimizely-sdk": "~4.4.3",
+    "@optimizely/optimizely-sdk": "5.3.2",
     "@types/jest": "^29.4.0",
     "jest": "^29.4.0",
     "ts-jest": "^29.0.5",