2.9.1

[2.9.1] - 2019-02-08

Fixed:

• The previous release of ldclient-react was broken: the package did not contain the actual files. The packaging script has been fixed. There are no other changes.

2.9.0

[2.9.0] - 2019-02-01

Added:

• The new ldclient-react package provides a convenient mechanism for using the LaunchDarkly SDK within the React framework.
• The new getUser() method returns the current user object.
• The client options can now have a logger property that defines a custom logging mechanism. The default is still to use console.warn and console.error; you could override this to send log messages to another destination or to suppress them. See LDLogger and createConsoleLogger in the TypeScript definitions.

Changed:

• The SDK now uses an additional package, ldclient-js-common, consisting of code that is also used by other LaunchDarkly SDKs. This is automatically loaded as a dependency of ldclient-js so you should notice any difference. However, the source code has been reorganized so that this project is now a monorepo containing multiple packages.

2.8.0

[2.8.0] - 2018-12-03

Added:

• The use of a streaming connection to LaunchDarkly for receiving live updates can now be controlled with the new client.setStreaming() method, or the equivalent boolean streaming property in the client configuration. If you set this to false, the client will not open a streaming connection even if you subscribe to change events (you might want to do this if, for instance, you just want to be notified when the client gets new flag values due to having switched users). If you set it to true, the client will open a streaming connection regardless of whether you subscribe to change events or not (the flag values will simply be updated in the background). If you don't set it either way then the default behavior still applies, i.e. the client opens a streaming connection if and only if you subscribe to change events.

Fixed:

• If the client opened a streaming connection because you called on('change', ...) one or more times, it will not close the connection until you call off() for all of your event listeners. Previously, it was closing the connection whenever off('change') was called, even if you still had a listener for 'change:specific-flag-key'.
• The client's logic for signaling a change event was using a regular Javascript === comparison, so it could incorrectly decide that a flag had changed if its value was a JSON object or an array. This has been fixed to use deep equality checking for object and array values.

2.7.5

[2.7.5] - 2018-11-21

Fixed:

• When using the event-source-polyfill package to allow streaming mode in browsers with no native EventSource support, the polyfill was using a default read timeout of 45 seconds, so if no updates arrived within 45 seconds it would log an error and reconnect the stream. The SDK now sets its own timeout (5 minutes) which will be used if this particular polyfill is active. LaunchDarkly normally sends a heartbeat every 3 minutes, so you should not see a timeout happen unless the connection has been lost.
• The SDK's use of the "Base64" package caused problems for build tools that strictly enforce the lowercase package name rule. It now uses the "base64-js" package instead. (#124)

2.7.4

Due to a build error, this release was not usable and has been removed from npm.

2.7.3

[2.7.3] - 2018-11-09

Fixed:

• The TypeScript definitions were incorrectly restricting the possible values for event types in on() and off(). Also, added documentation for event types which were not documented before. (#122)

2.7.2

[2.7.2] - 2018-10-17

Fixed:

• Disconnecting from the stream does not close the browser tab anymore.
  (Thanks, Sawtaytoes.)
• The configuration property evaluationReasons was misnamed as evaluationExplanations in the TypeScript definitions.

2.7.1

[2.7.1] - 2018-09-27

Fixed:

• Event posts did not include the HTTP header that specifies the SDK version. They now do again. Note that the sendLDHeaders option does not affect this; if the header is turned off for flag requests, it should still be sent in events, since events always require a CORS preflight check anyway (and are delivered asynchronously, so the OPTIONS request does not slow down page loads).

2.7.0

[2.7.0] - 2018-09-19

Added:

• New client method waitForInitialization returns a Promise, like waitUntilReady; but while waitUntilReady will be resolved as soon as client initialization either succeeds or fails, waitForInitialization will be resolved only if initialization succeeds, and will be rejected (with an error object) if it fails.
• New config option fetchGoals (default: true) allows you to control whether the client will request A/B testing parameters from LaunchDarkly. If you do not use A/B testing, you may wish to disable this to reduce the number of HTTP requests.
• New config option sendLDHeaders (default: true) allows you to control whether the client will add a custom header to LaunchDarkly HTTP requests (to indicate the SDK version). You may wish to disable this behavior if you have performance concerns, as it causes browsers to make an additional CORS preflight check (since it is no longer a simple request).

2.6.0

[2.6.0] - 2018-09-07

Added:

• The new configuration option evaluationReasons causes LaunchDarkly to report information about how each feature flag value was determined; you can access this information with the new client method variationDetail. The new method returns an object that contains both the flag value and a "reason" object which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.

Changed:

• In streaming mode, the client will attempt to reconnect if it receives an HTTP error status from LaunchDarkly. Previously, it would only retry if the connection was lost.