Interface LDClient

Returns a map of all available flags to the current context's values.

Shuts down the client and releases its resources, after delivering any pending analytics events. After the client is closed, all calls to variation will return default values, and it will not make any requests to LaunchDarkly.

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.

Returns the client's current context.

This is the context that was most recently passed to identify, or, if identify has never been called, the initial context specified when the client was created.

Identifies a context to LaunchDarkly.

Unlike the server-side SDKs, the client-side JavaScript SDKs maintain a current context state, which is set at initialization time. You only need to call identify() if the context has changed since then.

Changing the current context also causes all feature flag values to be reloaded. Until that has finished, calls to variation will still return flag values for the previous context. You can use a callback or a Promise to determine when the new flag values are available.

Deregisters an event listener. See on for the available event types.

Registers an event listener.

The following event names (keys) are used by the client:

• "ready": The client has finished starting up. This event will be sent regardless of whether it successfully connected to LaunchDarkly, or encountered an error and had to give up; to distinguish between these cases, see below.
• "initialized": The client successfully started up and has valid feature flag data. This will always be accompanied by "ready".
• "failed": The client encountered an error that prevented it from connecting to LaunchDarkly, such as an invalid environment ID. All flag evaluations will therefore receive default values. This will always be accompanied by "ready".
• "error": General event for any kind of error condition during client operation. The callback parameter is an Error object. If you do not listen for "error" events, then the errors will be logged with console.log().
• "change": The client has received new feature flag data. This can happen either because you have switched contexts with identify, or because the client has a stream connection and has received a live change to a flag value (see below). The callback parameter is an LDFlagChangeset.
• "change:FLAG-KEY": The client has received a new value for a specific flag whose key is FLAG-KEY. The callback receives two parameters: the current (new) flag value, and the previous value. This is always accompanied by a general "change" event as described above; you can listen for either or both.

The "change" and "change:FLAG-KEY" events have special behavior: by default, the client will open a streaming connection to receive live changes if and only if you are listening for one of these events. This behavior can be overridden by setting streaming in LDOptions or calling LDClient.setStreaming.

Specifies whether or not to open a streaming connection to LaunchDarkly for live flag updates.

If this is true, the client will always attempt to maintain a streaming connection; if false, it never will. If you leave the value undefined (the default), the client will open a streaming connection if you subscribe to "change" or "change:flag-key" events (see LDClient.on).

This can also be set as the streaming property of LDOptions.

Track page events to use in metrics (goals) or Experimentation.

LaunchDarkly automatically tracks pageviews and clicks that are specified in the Metrics section of their dashboard. This can be used to track custom metrics or other events that do not currently have metrics.

Determines the variation of a feature flag for the current context.

In the client-side JavaScript SDKs, this is always a fast synchronous operation because all of the feature flag values for the current context have already been loaded into memory.

Determines the variation of a feature flag for a context, along with information about how it was calculated.

Note that this will only work if you have set evaluationReasons to true in LDOptions. Otherwise, the reason property of the result will be null.

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.

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).

    // using Promise then() and catch() handlers
    client.waitForInitialization(5).then(() => {
        doSomethingWithSuccessfullyInitializedClient();
    }).catch(err => {
        doSomethingForFailedStartup(err);
    });

    // using async/await
    try {
        await client.waitForInitialization(5);
        doSomethingWithSuccessfullyInitializedClient();
    } catch (err) {
        doSomethingForFailedStartup(err);
    }
Copy

It is important that you handle the rejection case; otherwise it will become an unhandled Promise rejection, which is a serious error on some platforms. The Promise is not created unless you request it, so if you never call waitForInitialization() then you do not have to worry about unhandled rejections.

Note that you can also use event listeners (on) for the same purpose: the event "initialized" indicates success, and "failed" indicates failure.

Returns a Promise that tracks the client's initialization state.

The returned Promise will be resolved once the client has either successfully initialized or failed to initialize (e.g. due to an invalid environment key or a server error). It will never be rejected.

    // using a Promise then() handler
    client.waitUntilReady().then(() => {
        doSomethingWithClient();
    });

    // using async/await
    await client.waitUntilReady();
    doSomethingWithClient();
Copy

If you want to distinguish between these success and failure conditions, use waitForInitialization instead.

If you prefer to use event listeners (on) rather than Promises, you can listen on the client for a "ready" event, which will be fired in either case.