Associates two users for analytics purposes.
This can be helpful in the situation where a person is represented by multiple LaunchDarkly users. This may happen, for example, when a person initially logs into an application-- the person might be represented by an anonymous user prior to logging in and a different user after logging in, as denoted by a different user key.
Retrieves the set of all flag values for a user.
Deprecated: use allFlagsState instead. Current versions of the client-side
SDK will not generate analytics events correctly if you pass the result of allFlags().
The end user requesting the feature flags.
A Node-style callback to receive the result (as an LDFlagSet). If omitted, you will receive a Promise instead.
If you provided a callback, then nothing. Otherwise, a Promise which will be resolved with the result as an LDFlagSet.
Builds an object that encapsulates the state of all feature flags for a given user. This includes the flag values and also metadata that can be used on the front end. This method does not send analytics events back to LaunchDarkly.
The most common use case for this method is to bootstrap a set of client-side
feature flags from a back-end service. Call the toJSON() method of the returned object
to convert it to the data structure used by the client-side SDK.
The end user requesting the feature flags.
Optional [[LDFlagsStateOptions]] to determine how the state is computed.
A Node-style callback to receive the result (as an LDFlagsState). If omitted, you will receive a Promise instead.
If you provided a callback, then nothing. Otherwise, a Promise which will be resolved with the result as an LDFlagsState.
Discards all network connections, background tasks, and other resources held by the client.
Do not attempt to use the client after calling this method.
Flushes all pending analytics events.
Normally, batches of events are delivered in the background at intervals determined by the
flushInterval property of LDOptions. Calling flush() triggers an immediate delivery.
A function which will be called when the flush completes. If omitted, you will receive a Promise instead.
If you provided a callback, then nothing. Otherwise, a Promise which resolves once flushing is finished. Note that the Promise will be rejected if the HTTP request fails, so be sure to attach a rejection handler to it.
Identifies a user to LaunchDarkly.
This simply creates an analytics event that will transmit the given user properties to LaunchDarkly, so that the user will be visible on your dashboard even if you have not evaluated any flags for that user. It has no other effect.
The user properties. Must contain at least the key property.
Tests whether the client has completed initialization.
If this returns false, it means that the client has not yet successfully connected to LaunchDarkly. It might still be in the process of starting up, or it might be attempting to reconnect after an unsuccessful attempt, or it might have received an unrecoverable error (such as an invalid SDK key) and given up.
True if the client has successfully initialized.
Tests whether the client is configured in offline mode.
True if the offline property is true in your LDOptions.
In the Node SDK, secureModeHash computes an HMAC signature of a user signed with the
client's SDK key. This is not possible in Electron because the SDK key is not available,
so secureModeHash will always return an empty string.
An empty string.
Tracks that a user performed an event.
LaunchDarkly automatically tracks pageviews and clicks that are specified in the Goals section of the dashboard. This can be used to track custom goals or other events that do not currently have goals.
The name of the event, which may correspond to a goal in A/B tests.
The user to track.
Optional additional information to associate with the event.
Determines the variation of a feature flag for a user.
The unique key of the feature flag.
The end user requesting the flag. The client will generate an analytics event to register this user with LaunchDarkly if the user does not already exist.
The default value of the flag, to be used if the value is not available from LaunchDarkly.
A Node-style callback to receive the result value. If omitted, you will receive a Promise instead.
If you provided a callback, then nothing. Otherwise, a Promise which will be resolved with the result value.
Determines the variation of a feature flag for a user, along with information about how it was calculated.
The reason property of the result will also be included in analytics events, if you are
capturing detailed event data for this flag.
For more information, see the SDK reference guide.
The unique key of the feature flag.
The end user requesting the flag. The client will generate an analytics event to register this user with LaunchDarkly if the user does not already exist.
The default value of the flag, to be used if the value is not available from LaunchDarkly.
A Node-style callback to receive the result (as an LDEvaluationDetail). If omitted, you will receive a Promise instead.
If you provided a callback, then nothing. Otherwise, a Promise which will be resolved with the result (as an LDEvaluationDetail).
Returns a Promise that tracks the client's initialization state.
The Promise will be resolved if the client successfully initializes, or rejected if client initialization has irrevocably failed (for instance, if it detects that the SDK key is invalid).
Note that you can also use event listeners (on) for the same purpose: the event "ready"
indicates success, and "failed" indicates failure.
A Promise that will be resolved if the client initializes successfully, or rejected if it fails. If successful, the result is the same client object.
Returns a Promise that tracks the client's initialization state.
Deprecated: please use waitForInitialization instead. The difference between that method
and this one is that waitUntilReady never rejects the Promise, even if initialization fails.
A Promise that will be resolved if the client initializes successfully.
Generated using TypeDoc
Interface for the Node SDK compatibility wrapper returned by createNodeSdkAdapter.
Keep in mind that the underlying implementation is still the client-side SDK, which has a single-current-user model. Therefore, when you call
variation(flagKey, user, defaultValue), it is really callingidentify(user)first, obtaining flag values for that user, and then evaluating the flag. This will perform poorly if you attempt to evaluate flags for a variety of different users in rapid succession.