UNPKG

@launchdarkly/js-server-sdk-common

Version:
121 lines 6.1 kB
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