Interface LDElectronMainClient

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.

Normally, batches of events are delivered in the background at intervals determined by the flushInterval property of LDOptions. Calling flush() triggers an immediate delivery.

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

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

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

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 users 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 LDElectronMainClient.setStreaming or LDElectronRendererClient.setStreaming.

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 LDElectronMainClient.on or LDElectronRendererClient.on).

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

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

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

Note that this will only work if you have set evaluationExplanations 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.

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().then(() => {
        doSomethingWithSuccessfullyInitializedClient();
    }).catch(err => {
        doSomethingForFailedStartup(err);
    });

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

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.

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();

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.