Releases: optimizely/javascript-sdk
Releases · optimizely/javascript-sdk
Release 4.0.0-alpha.1
[4.0.0-alpha.1] - April 2, 2020
Breaking Changes:
- Removed
Promise
polyfill from browser entry point (417)
Release 3.6.0-alpha.1
[3.6.0-alpha.1] - March 4, 2020
New Features
- Changed
track()
to log a warning instead of an error when the event isn't in the datafile (#418)
Release 3.5.0
Release 3.4.1
[3.4.1] - January 28th, 2020
Bug fixes
- Added
getOptimizelyConfig
and related types to TypeScript type definitions(#390).
Release 3.4.0
[3.4.0] - January 21th, 2020
Bug fixes
- Fixed incorrect payload for decision notification triggered by calling getVariation on a feature test in a mutex group(#375)
New Features
- Added a new API to get project configuration static data.
- Call
getOptimizelyConfig()
to get a snapshot of project configuration static data. - It returns an
OptimizelyConfig
instance which includes a datafile revision number, all experiments, and feature flags mapped by their key values. - Added caching for
getOptimizelyConfig
-OptimizelyConfig
object will be cached and reused for the lifetime of the datafile. - For details, refer to our documentation page: https://docs.developers.optimizely.com/full-stack/docs/optimizelyconfig-javascript-node.
- Call
Removed Features
- Removed support for
'launched'
experiment status.- Previously, experiments with status
'running'
or'launched'
would return non-null
variations fromactivate
andgetVariation
, and generate impression events fromactivate
. - Now, only
'running'
experiments will return non-null
variations and generate impressions.
- Previously, experiments with status
Release 3.4.0-beta
[3.4.0-beta] - December 18th, 2019
Bug fixes
- Fixed incorrect payload for decision notification triggered by calling getVariation on a feature test in a mutex group(#375)
New Features
- Added a new API to get a project configuration static data.
- Call
getOptimizelyConfig()
to get a snapshot copy of project configuration static data. - It returns an
OptimizelyConfig
instance which includes a datafile revision number, all experiments, and feature flags mapped by their key values. - For details, refer to a documention page: https://docs.developers.optimizely.com/full-stack/docs/optimizelyconfig-javascript-node
- Call
Release 3.3.2
[3.3.2] - November 14th, 2019
Bug fixes
- Fixed error message that was being logged when a user was bucketed into empty space in an experiment or a mutual exclusion group. This is not an error. With the fix, the message indicates that the user was not included in any experiment (#366).
Release 3.3.1
[3.3.1] - October 25th, 2019
Bug fixes
- Fixed full screen error dialog appearing in local development for React Native apps when using the default logger. We now provide a default logger for React Native that does not call
console.error
.
Release 3.3.0
[3.3.0] - September 25th, 2019
New Features
- Added support for event batching via the event processor.
- Events generated by methods like
activate
,track
, andisFeatureEnabled
will be held in a queue until the configured batch size is reached, or the configured flush interval has elapsed. Then, they will be combined into a request and sent to the event dispatcher. - To configure event batching, include the
eventBatchSize
andeventFlushInterval
number properties in the object you pass tocreateInstance
. - Event batching is enabled by default.
eventBatchSize
defaults to10
.eventFlushInterval
defaults to30000
in Node and1000
in browsers.
- Events generated by methods like
- Added
localStorage
mitigation against lost events in the browser- When event requests are dispatched, they are written to
localStorage
, and when a response is received, they are removed fromlocalStorage
. - When the SDK is initialized for the first time in the browser, if any requests remain in
localStorage
, they will be sent, and removed fromlocalStorage
when a response is received.
- When event requests are dispatched, they are written to
- Updated the
close
method to return aPromise
representing the process of closing the instance. Whenclose
is called, any events waiting to be sent as part of a batched event request will be immediately batched and sent to the event dispatcher.- If any such requests were sent to the event dispatcher,
close
returns aPromise
that fulfills after the event dispatcher calls the response callback for each request. Otherwise,close
returns an immediately-fulfilledPromise
. - The
Promise
returned fromclose
is fulfilled with a result object containingsuccess
(boolean) andreason
(string, only when success isfalse
) properties. In the result object,success
istrue
if all events in the queue at the time close was called were combined into requests, sent to the event dispatcher, and the event dispatcher called the callbacks for each request.success
is false if an unexpected error was encountered during the close process.
- If any such requests were sent to the event dispatcher,
- Added non-typed
getFeatureVariable
method (#298) as a more idiomatic approach to getting values of feature variables.- Typed
getFeatureVariable
methods will still be available for use.
- Typed
Release 3.3.0-beta
[3.3.0-beta] - August 21st, 2019
New Features
- Added support for event batching via the event processor.
- Events generated by methods like
activate
,track
, andisFeatureEnabled
will be held in a queue until the configured batch size is reached, or the configured flush interval has elapsed. Then, they will be combined into a request and sent to the event dispatcher. - To configure event batching, include the
eventBatchSize
andeventFlushInterval
number properties in the object you pass tocreateInstance
. - Event batching is enabled by default.
eventBatchSize
defaults to10
.eventFlushInterval
defaults to30000
in Node and1000
in browsers.
- Events generated by methods like
- Added
localStorage
mitigation against lost events in the browser- When event requests are dispatched, they are written to
localStorage
, and when a response is received, they are removed fromlocalStorage
. - When the SDK is initialized for the first time in the browser, if any requests remain in
localStorage
, they will be sent, and removed fromlocalStorage
when a response is received.
- When event requests are dispatched, they are written to
- Updated the
close
method to return aPromise
representing the process of closing the instance. Whenclose
is called, any events waiting to be sent as part of a batched event request will be immediately batched and sent to the event dispatcher.- If any such requests were sent to the event dispatcher,
close
returns aPromise
that fulfills after the event dispatcher calls the response callback for each request. Otherwise,close
returns an immediately-fulfilledPromise
. - The
Promise
returned fromclose
is fulfilled with a result object containingsuccess
(boolean) andreason
(string, only when success isfalse
) properties. In the result object,success
istrue
if all events in the queue at the time close was called were combined into requests, sent to the event dispatcher, and the event dispatcher called the callbacks for each request.success
is false if an unexpected error was encountered during the close process.
- If any such requests were sent to the event dispatcher,
- Added non-typed
getFeatureVariable
method (#298) as a more idiomatic approach to getting values of feature variables.- Typed
getFeatureVariable
methods will still be available for use.
- Typed