@launchdarkly/js-server-sdk-common
Version:
LaunchDarkly Server SDK for JavaScript - common code
121 lines • 6.1 kB
TypeScript
import { LDClientContext, subsystem, VoidFunction } from '@launchdarkly/js-sdk-common';
import { LDFeatureStore } from '../../api';
import TestDataFlagBuilder from './TestDataFlagBuilder';
/**
* A mechanism for providing dynamically updatable feature flag state in a simplified form to an SDK
* client in test scenarios.
*
* Unlike `FileData`, this mechanism does not use any external resources. It provides only the
* data that the application has put into it using the {@link TestData.update} method.
*
* ```
* // Import TestData from the integrations package of the SDK you are using.
* // This is a common implementation and may be used in multiple SDKs.
*
* const td = TestData();
* testData.update(td.flag("flag-key-1").booleanFlag().variationForAll(true));
* // Use the initialization mechanism specified by your SDK.
* const client = LDClient.init(sdkKey, { updateProcessor: td.getFactory() });
*
* // flags can be updated at any time:
* td.update(td.flag("flag-key-2")
* .variationForContext("user", "some-user-key", true)
* .fallthroughVariation(false));
* ```
*
* The above example uses a simple boolean flag, but more complex configurations are possible using
* the methods of the {@link TestDataFlagBuilder} that is returned by {@link TestData.flag}.
* {@link TestDataFlagBuilder} supports many of the ways a flag can be configured on the
* LaunchDarkly dashboard, but does not currently support
* 1. rule operators other than "in" and "not in", or
* 2. percentage rollouts.
*
* If the same `TestData` instance is used to configure multiple `LDClient` instances,
* any changes made to the data will propagate to all of the `LDClient`s.
*/
export default class TestData {
private _currentFlags;
private _currentSegments;
private _dataSources;
private _flagBuilders;
/**
* Get a factory for update processors that will be attached to this TestData instance.
* @returns An update processor factory.
*/
getFactory(): (clientContext: LDClientContext, featureStore: LDFeatureStore, initSuccessHandler: VoidFunction, errorHandler?: (e: Error) => void) => subsystem.LDStreamProcessor;
/**
* Creates or copies a {@link TestDataFlagBuilder} for building a test flag configuration.
*
* If the flag key has already been defined in this `TestData` instance,
* then the builder starts with the same configuration that was last
* provided for this flag.
*
* Otherwise, it starts with a new default configuration in which the flag
* has `true` and `false` variations, is `true` for all users when targeting
* is turned on and `false` otherwise, and currently has targeting turned on.
* You can change any of those properties and provide more complex behavior
* using the `TestDataFlagBuilder` methods.
*
* Once you have set the desired configuration, pass the builder to
* {@link TestData.update}.
*
* @param key the flag key
* @returns a flag configuration builder
*
*/
flag(key: string): TestDataFlagBuilder;
/**
* Updates the test data with the specified flag configuration.
*
* This has the same effect as if a flag were added or modified in the
* LaunchDarkly dashboard. It immediately propagates the flag changes to
* any `LDClient` instance(s) that you have already configured to use
* this `TestData`. If no `LDClient` has been started yet, it simply adds
* this flag to the test data which will be provided to any `LDClient`
* that you subsequently configure.
*
* Any subsequent changes to this `TestDataFlagBuilder` instance do not affect
* the test data unless you call `update` again.
*
* @param flagBuilder a flag configuration builder
* @return a promise that will resolve when the feature stores are updated
*/
update(flagBuilder: TestDataFlagBuilder): Promise<any>;
/**
* Copies a full feature flag data model object into the test data.
*
* It immediately propagates the flag change to any `LDClient` instance(s) that you have already
* configured to use this `TestData`. If no `LDClient` has been started yet, it simply adds this
* flag to the test data which will be provided to any LDClient that you subsequently configure.
*
* Use this method if you need to use advanced flag configuration properties that are not
* supported by the simplified {@link TestDataFlagBuilder} API. Otherwise it is recommended to use
* the regular {@link flag}/{@link update} mechanism to avoid dependencies on details of the data
* model.
*
* You cannot make incremental changes with {@link flag}/{@link update} to a flag that has been
* added in this way; you can only replace it with an entirely new flag configuration.
*
* @param flagConfig the flag configuration as a JSON object
* @return a promise that will resolve when the feature stores are updated
*/
usePreconfiguredFlag(inConfig: any): Promise<any>;
/**
* Copies a full segment data model object into the test data.
*
* It immediately propagates the change to any `LDClient` instance(s) that you have already
* configured to use this `TestData`. If no `LDClient` has been started yet, it simply adds
* this segment to the test data which will be provided to any LDClient that you subsequently
* configure.
*
* This method is currently the only way to inject segment data, since there is no builder
* API for segments. It is mainly intended for the SDK's own tests of segment functionality,
* since application tests that need to produce a desired evaluation state could do so more easily
* by just setting flag values.
*
* @param segmentConfig the segment configuration as a JSON object
* @return a promise that will resolve when the feature stores are updated
*/
usePreconfiguredSegment(inConfig: any): Promise<any>;
}
//# sourceMappingURL=TestData.d.ts.map