;
}
...
}
```
{% endtab %}
{% tab title="Using React Native AsyncStorage" %}
```typescript
import AsyncStorage from '@react-native-async-storage/async-storage';
import { SplitFactory, InLocalStorage } from '@splitsoftware/splitio-react-native';
const factory: SplitIO.IBrowserSDK = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
storage: InLocalStorage({
prefix: 'MY_PREFIX',
expirationDays: 10,
clearOnInit: false,
wrapper: AsyncStorage
})
});
// Now use the SDK as usual
const client = factory.client();
```
{% endtab %}
{% endtabs %}
### Localhost mode
For testing, a developer can put code behind feature flags on their development machine without the SDK requiring network connectivity. To achieve this, the SDK can be started in **localhost** mode (aka off-the-grid or offline mode). In this mode, the SDK neither polls nor updates Harness servers. Instead, it uses an in-memory data structure to determine what treatments to show to the logged in customer for each of the features.
Define the feature flags you want to use in the `features` object map. All `getTreatment` calls for a feature flag now only return the one treatment (and config, if defined) that you have defined in the map. You can then change the treatment as necessary for your testing. To update a treatment or a config, or to add or remove feature flags from the mock cache, update the properties of the `features` object you've provided. The SDK simulates polling for changes and updates from it. Do not assign a new object to the `features` property because the SDK has a reference to the original object and will not detect the change.
Any feature that is not provided in the `features` map returns the [control treatment](/feature-management-experimentation/use-fme/feature-management/setup/control-treatment.md) if the SDK was asked to evaluate them.
You can use the additional configuration parameters below when instantiating the SDK in `localhost` mode.
| **Configuration** | **Description** | **Default value** |
| ---------------------------- | ------------------------------------------------------------------- | --------------------------------------------------- |
| scheduler.offlineRefreshRate | The refresh interval for the mocked features treatments. | 15 |
| features | A fixed mapping of which treatment to show for our mocked features. | {}
By default we have no mocked features.
|
To use the SDK in localhost mode, replace the SDK Key on `authorizationKey` property with `'localhost'`, as shown in the example below. Note that you can define in the `features` object a feature flag name and its treatment directly or use a map to define both a treatment and a dynamic configuration.
If you define just a string as the value for a feature flag name, any config returned by our SDKs will always be null. If you use a map, we return the specified treatment and the specified config (which can also be null).
{% tabs %}
{% tab title="JavaScript" %}
```javascript
import { SplitFactory } from '@splitsoftware/splitio-react-native';
var sdk = SplitFactory({
core: {
authorizationKey: 'localhost'
},
features: {
'reporting_v2': 'on', // example with just a string value for the treatment
'billing_updates': { treatment: 'visa', config: '{ "color": "blue" }' }, // example of a defined config
'show_status_bar': { treatment: 'off', config: null } // example of a null config
},
scheduler: {
offlineRefreshRate: 15 // 15 sec
}
});
var client = sdk.client();
// The following code will be evaluated once the engine finishes the initialization
client.on(client.Event.SDK_READY, function() {
// The sentence below will return 'on'
var t1 = client.getTreatment('reporting_v2')
// The sentence below will return an object with the structure of: {treatment:'visa',config:'{ "color":"blue" }'}
var t2 = client.getTreatmentWithConfig('billing_updates')
// The sentence below will return 'control' because that feature does not exist
var t3 = client.getTreatmentWithConfig('navigation_bar_changes')
});
```
{% endtab %}
{% tab title="TypeScript" %}
```typescript
import { SplitFactory } from '@splitsoftware/splitio-react-native';
const sdk: SplitIO.IBrowserSDK = SplitFactory({
core: {
authorizationKey: 'localhost'
},
features: {
'reporting_v2': 'on', // example with just a string value for the treatment
'billing_updates': { treatment: 'visa', config: '{ "color": "blue"}' } // example of a defined config
'show_status_bar': { treatment: 'off', config: null } // example of a null config
},
scheduler: {
offlineRefreshRate: 15 // 15 sec
}
});
const client: SplitIO.IBrowserClient = sdk.client();
// The following code will be evaluated once the engine finishes the initialization
client.on(client.Event.SDK_READY, () => {
// The sentence below will return 'on'
const t1: SplitIO.Treatment = client.getTreatment('reporting_v2');
// The sentence below will return an object with the structure of: {treatment:'visa',config:'{ "color":"blue" }'
const t2: SplitIO.Treatment = client.getTreatmentWithConfig('billing_updates');
// The sentence below will return 'control' because that feature does not exist
const t3: SplitIO.Treatment = client.getTreatmentWithConfig('navigation_bar_changes');
});
```
{% endtab %}
{% endtabs %}
{% hint style="info" %}
**TESTING WITH JEST**
We recommend using the SDK in localhost mode for your tests.
For example, you can mock the module import (see [Jest documentation](https://jestjs.io/docs/jest-object#jestmockmodulename-factory-options) for details) to instantiate the SDK in localhost mode as shown below:
```javascript
jest.mock('@splitsoftware/splitio-react-native', () => {
const splitio = jest.requireActual('@splitsoftware/splitio-react-native');
return {
...splitio,
SplitFactory: () => {
return splitio.SplitFactory({
core: {
authorizationKey: 'localhost',
},
// Mock your feature flags and treatments here
features: {
feature_flag_1: 'on',
}
});
},
};
});
```
It is not recommended to use the default (online) mode of the SDK in your tests because it slows them down and increases their instability due to network latencies. However, if you must use it, you need to polyfill the [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API), which is used by the SDK but not provided by Jest and Node.js. [`isomorphic-fetch`](https://www.npmjs.com/package/isomorphic-fetch) is a good option for that.
{% endhint %}
### Manager
Use the Split Manager to get a list of features available to the SDK factory client.
To instantiate a Manager in your code base, use the same factory that you used for your client.
{% tabs %}
{% tab title="JavaScript" %}
```javascript
var factory = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
}
});
var manager = factory.manager();
manager.once(manager.Event.SDK_READY, function() {
// Once it's ready, use the manager
});
```
{% endtab %}
{% tab title="TypeScript" %}
```typescript
const factory: SplitIO.IBrowserSDK = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
}
});
const manager: SplitIO.IManager = factory.manager();
manager.once(manager.Event.SDK_READY, function() {
// Once it's ready, use the manager
});
```
{% endtab %}
{% endtabs %}
The Manager then has the following methods available.
{% tabs %}
{% tab title="JavaScript" %}
```javascript
/**
* Returns the feature flag registered with the SDK of this name.
*
* @return SplitView or null.
*/
var splitView = manager.split('name-of-feature-flag');
/**
* Retrieves the feature flags that are currently registered with the
* SDK.
*
* returns a List of SplitViews.
*/
var splitViewsList = manager.splits();
/**
* Returns the names of feature flags registered with the SDK.
*
* @return a List of Strings of the feature flag names.
*/
var splitNamesList = manager.names();
```
{% endtab %}
{% tab title="TypeScript" %}
```typescript
/**
* Returns the feature flag registered with the SDK of this name.
*
* @return SplitView or null.
*/
const splitView: SplitIO.SplitView = manager.split('name-of-feature-flag');
/**
* Retrieves the feature flags that are currently registered with the
* SDK.
*
* returns a List of SplitViews.
*/
const splitViewsList: SplitIO.SplitViews = manager.splits();
/**
* Returns the names of feature flags registered with the SDK.
*
* @return a List of Strings of the feature flag names.
*/
const splitNamesList: SplitIO.SplitNames = manager.names();
```
{% endtab %}
{% endtabs %}
The `SplitView` object referenced above has the following structure:
```typescript
type SplitView = {
name: string,
trafficType: string,
killed: boolean,
treatments: Array,
changeNumber: number,
configs: {
[treatmentName: string]: string
},
defaultTreatment: string,
sets: Array,
impressionsDisabled: boolean
}
```
### Listener
FME SDKs send impression data back to Harness servers periodically and as a result of evaluating feature flags. To additionally send this information to a location of your choice, define and attach an *impression listener*. For that purpose, the SDK's configurations have a parameter called `impressionListener` where an implementation of `ImpressionListener` could be added. This implementation **must** define the `logImpression` method and it receives data in the following schema.
| **Name** | **Type** | **Description** |
| ------------------ | -------- | ------------------------------------------------------------------------------------------------------ |
| impression | Object | Impression object that has the feature, key, treatment, label, etc. |
| attributes | Object | A map of attributes passed to `getTreatment`/`getTreatments` (if any). |
| sdkLanguageVersion | String | The version of the SDK. In this case the language is `reactnative` plus the version currently running. |
{% hint style="info" %}
**NOTE**
There are two additional keys on this object, `ip` and `hostname`. They are not captured on the client side but kept for consistency.
{% endhint %}
### Implement custom impression listener
Here is an example of how implement a custom impression listener.
{% tabs %}
{% tab title="JavaScript" %}
```javascript
function logImpression(impressionData) {
// do something with the impression data.
}
var factory = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
impressionListener: {
logImpression: logImpression
}
});
```
{% endtab %}
{% tab title="TypeScript" %}
```typescript
class MyImprListener implements SplitIO.IImpressionListener {
logImpression(impressionData: SplitIO.ImpressionData) {
// do something with impressionData
}
}
const factory: SplitIO.IBrowserSDK = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
impressionListener: {
logImpression: new MyImprListener()
}
});
```
{% endtab %}
{% endtabs %}
An impression listener is called asynchronously from the corresponding evaluation, but is almost immediate.
Even though the SDK does not fail if there is an exception in the listener, do not block the call stack.
### Logging
To trim as many bits as possible from the user application builds, we divided the logger in implementations that contain the log messages for each log level: `ErrorLogger`, `WarnLogger`, `InfoLogger`, and `DebugLogger`. Higher log level options contain the messages for the lower ones, with DebugLogger containing them all. Thus, to enable descriptive SDK logging you need to plug in a logger instance as shown below:
{% tabs %}
{% tab title="Logger instance" %}
```javascript
import { SplitFactory, DebugLogger } from '@splitsoftware/splitio-react-native';
const sdk = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
debug: DebugLogger() // other options are `InfoLogger`, `WarnLogger` and `ErrorLogger`
});
```
{% endtab %}
{% endtabs %}
You can also enable the SDK logging via a boolean or log level value as `debug` settings, and change it dynamically by calling the SDK Logger API.
However, in any case where the proper logger instance is not plugged in, instead of a human readable message you'll get a code and optionally some params for the log itself. While these logs would be enough for the Split support team, if you find yourself in a scenario where you need to parse this information, you can check the constant files in our javascript-commons repository (where you have tags per version if needed) under the [logger folder](https://github.com/splitio/javascript-commons/blob/master/src/logger/).
{% tabs %}
{% tab title="Logger API" %}
```javascript
import { SplitFactory } from '@splitsoftware/splitio-react-native';
const sdk = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
debug: true // other options are 'ERROR', 'WARN', 'INFO' and 'DEBUG
});
// Or you can use the Logger API methods which have an immediate effect.
sdk.Logger.setLogLevel('WARN'); // Acceptable values are: 'DEBUG', 'INFO', 'WARN', 'ERROR', 'NONE'
sdk.Logger.enable(); // equivalent to `setLogLevel('DEBUG')`
sdk.Logger.disable(); // equivalent to `setLogLevel('NONE')`
```
{% endtab %}
{% endtabs %}
By default, the SDK uses the `console.log` method to output log messages for all log levels.
Since v1.4.0 of the SDK, you can provide a custom logger to handle SDK log messages by setting the `logger` configuration option or using the `factory.Logger.setLogger` method.
The logger object must implement the `SplitIO.Logger` interface, which is compatible with the `console` object and logging libraries such as `winston`, `pino`, and `log4js`. The interface is defined as follows:
```typescript
interface Logger {
debug(message: string): any;
info(message: string): any;
warn(message: string): any;
error(message: string): any;
}
```
The following example passes the `console` object as a logger, so that `console.error`, `console.warn`, `console.info`, and `console.debug` methods are called rather than the default `console.log` method.
{% tabs %}
{% tab title="Using Console as Logger" %}
```typescript
import { SplitFactory, DebugLogger } from '@splitsoftware/splitio-react-native';
const sdk = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
// Enable logs to call the corresponding custom logger methods
debug: DebugLogger(),
logger: console
});
```
{% endtab %}
{% endtabs %}
### Configure fallback treatments
Fallback treatments let you define a treatment value (and optional configuration) to be returned when a flag cannot be evaluated. By default, the SDK returns `control`, but you can override this globally or for individual flags at the SDK level.
This is useful when you want to:
* Maintain a predictable user experience during outages or evaluation failures (avoid unexpected `control` in production)
* Protect critical user flows by returning a safe, stable treatment (for example, forcing `off` during an incident)
* Customize behavior per flag so each evaluation inherits appropriate safe defaults if something goes wrong
#### Global fallback treatment
Set a global fallback treatment when initializing the SDK factory. This value is returned whenever any flag cannot be evaluated.
```javascript
// Initialize SDK with global fallback treatment
const factory = SplitFactory({
core: {
authorizationKey: 'YOUR_CLIENT_SIDE_SDK_KEY',
key: 'USER_ID'
},
fallbackTreatments: {
global: {
treatment: 'global-treatment',
config: '{"global": true}'
},
}
});
const client = factory.client();
```
#### Flag-level fallback treatment
You can also set a fallback treatment per flag when calling `getTreatment` or `getTreatmentWithConfig`. This flag-level fallback always takes precedence over the global fallback treatment, so if both are defined, the SDK will return the flag-level value when that flag cannot be evaluated.
```javascript
// Initialize SDK with a per-flag fallback treatment
const factory = SplitFactory({
core: {
authorizationKey: 'YOUR_CLIENT_SIDE_SDK_KEY',
key: 'USER_ID'
},
fallbackTreatments: {
byFlag: {
'my_feature': {
treatment: 'flag-level-treatment',
config: '{"global": false}'
},
'my_other_feature': 'off'
}
}
});
const client = factory.client();
```
For more information, see [Fallback treatments](/feature-management-experimentation/use-fme/feature-management/setup/fallback-treatment.md).
### Advanced use cases
This section describes advanced use cases and features provided by the SDK.
#### Instantiate multiple SDK clients
FME supports the ability to release based on multiple traffic types. For example, with traffic types, you can release to `users` in one feature flag and `accounts` in another. If you are unfamiliar with using multiple traffic types, refer to the [Traffic type guide](/feature-management-experimentation/management-and-administration/traffic-types.md) for more information.
Each SDK factory client is tied to one specific customer ID at a time, so if you need to roll out feature flags by different traffic types, instantiate multiple SDK clients, one for each traffic type. For example, you may want to roll out the feature `user-poll` by `users` and the feature `account-permissioning` by `accounts`.
You can do this with the example below.
{% tabs %}
{% tab title="JavaScript" %}
```javascript
var factory = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'CUSTOMER_ACCOUNT_ID',
// Instantiate the sdk once and provide the ID for one of the
// traffic types that you plan to release to. It doesn't
// matter which you pick to start off with.
},
});
// When you call factory.client(), the sdk will create a client
// using the Account ID passed in during the factory creation in the `key` field.
var account_client = factory.client();
// To create another client for a User instead, just pass in a User ID (of traffic type user).
// Note: this is only valid after at least one client has been initialized.
var user_client = factory.client('CUSTOMER_USER_ID');
// check treatment for user-poll and CUSTOMER_USER_ID
var user_poll_treatment = user_client.getTreatment('user-poll');
// check treatment for account-permissioning and CUSTOMER_ACCOUNT_ID
var account_permissioning_treatment = account_client.getTreatment('account-permissioning');
// track events for accounts
user_client.track('account', 'PAGELOAD', 7.86);
// or track events for users
account_client.track('user', 'ACCOUNT_CREATED');
```
{% endtab %}
{% tab title="TypeScript" %}
```typescript
const sdk: SplitIO.IBrowserSDK = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'CUSTOMER_ACCOUNT_ID'
// Instantiate the sdk once and provide the ID for one of the
// traffic types that you plan to release to. It doesn't
// matter which you pick to start off with.
},
});
// When you call factory.client(), the sdk will create a client
// using the Account ID passed in during the factory creation in the `key` field.
const account_client: SplitIO.IBrowserClient = factory.client();
// To create another client for a User instead, just pass in a User ID (of traffic type user).
// Note: this is only valid after at least one client has been initialized.
const user_client: SplitIO.IBrowserClient = factory.client('CUSTOMER_USER_ID');
// check treatment for user-poll and CUSTOMER_USER_ID
const user_poll_treatment: SplitIO.Treatment =
user_client.getTreatment('user-poll');
// check treatment for account-permissioning and CUSTOMER_ACCOUNT_ID
const account_permissioning_treatment: SplitIO.Treatment =
account_client.getTreatment('account-permissioning');
// track events for accounts
user_client.track('account', 'PAGELOAD', 7.86);
// or track events for users
account_client.track('user', 'ACCOUNT_CREATED');
```
{% endtab %}
{% endtabs %}
{% hint style="info" %}
**NUMBER OF SDK INSTANCES**
While the SDK does not put any limitations on the number of instances that can be created, we strongly recommend keeping the number of SDKs down to **one** or **two**.
{% endhint %}
#### Subscribe to events
You can listen for four different events from the SDK.
* `SDK_READY_FROM_CACHE`. This event fires when the SDK is ready to evaluate treatments. If the SDK is configured to use a persistent cache using the `InLocalStorage` module (see [Configure cache behavior](#configure-cache-behavior)), it will attempt to use a locally cached version of your rollout plan from a previous session. If data is cached, this event fires almost immediately, since access to the cache is fast, but data might be stale. Otherwise, it fires together with the `SDK_READY` event when the SDK downloads the rollout plan from Harness servers.
* `SDK_READY`. This event fires once the SDK is ready to evaluate treatments using the most up-to-date version of your rollout plan, downloaded from Harness servers.
* `SDK_READY_TIMED_OUT`. This event fires if the SDK could not download the data from Harness servers (`SDK_READY` event), within the time specified by the `startup.readyTimeout` configuration parameter. This event does not indicate that the SDK initialization was interrupted. The SDK continues downloading the rollout plan and fires the `SDK_READY` event when finished. This delayed `SDK_READY` event may happen with slow connections or large rollout plans with many feature flags, segments, or dynamic configurations.
* `SDK_UPDATE`. This event fires whenever your rollout plan is changed. Listen for this event to refresh your app whenever a feature flag or segment is changed in Harness FME.
The syntax to listen for each event is shown below:
{% tabs %}
{% tab title="JavaScript" %}
```javascript
function whenReady() {
const treatment = client.getTreatment('FEATURE_FLAG_NAME');
if (treatment === 'on') {
// insert on code
} else if (treatment === 'off') {
// insert off code
} else {
// insert control code (usually the same as default treatment)
}
}
client.once(client.Event.SDK_READY, () => {
// The client is ready to evaluate treatments with the latest feature flag definitions synchronized from the server
whenReady();
});
client.once(client.Event.SDK_READY_TIMED_OUT, () => {
// This callback will be called after `startup.readyTimeout` seconds (10 seconds by default)
// if and only if the client is not ready for that time.
// You can still call `getTreatment()` but it could return `CONTROL`.
});
client.on(client.Event.SDK_UPDATE, () => {
// Fired each time the client state changes.
// For example, when a feature flag or a segment changes.
});
client.once(client.Event.SDK_READY_FROM_CACHE, () => {
// The client is ready to evaluate treatments, but not necessarily with the latest feature flag definitions synchronized from the server.
// Fired after the SDK could confirm the presence of the FME data.
// This event can fire really quickly, if data is cached from a previous session.
// Keep in mind that data might be stale, this is NOT a replacement of SDK_READY.
});
```
{% endtab %}
{% endtabs %}
**Using readiness state and promises**
The `SDK_READY_FROM_CACHE`, `SDK_READY`, and `SDK_READY_TIMED_OUT` events fire only once. Therefore, if an event listener is attached after the event has already fired, it will never be triggered.
For this reason, you can check the SDK readiness state using the `client.getStatus()` method to determine whether the SDK is ready to evaluate treatments, among other things:
```javascript
const {
isReady, // true if the SDK_READY event was emitted
isReadyFromCache, // true if the SDK_READY_FROM_CACHE event was emitted
hasTimedout, // true if the SDK_READY_TIMED_OUT event was emitted
lastUpdate // timestamp of the most recent event
} = client.getStatus();
if (isReady) {
whenReadyCallback();
} else {
client.on(client.Event.SDK_READY, whenReadyCallback);
}
```
As an alternative to event listeners, you can also use the client promise methods `whenReady` and `whenReadyFromCache` to wait for the SDK to become ready.
* The `whenReadyFromCache()` promise resolves once the `SDK_READY_FROM_CACHE` event is emitted, or rejects if the `SDK_READY_TIMED_OUT` event is emitted first.
* The `whenReady()` promise resolves when the `SDK_READY` event is emitted, or rejects if the `SDK_READY_TIMED_OUT` event is emitted first. Subsequent calls to `client.whenReady()` may return a new promise with a different settled state. For instance, a resolved promise if the SDK becomes ready after the `SDK_READY_TIMED_OUT` event was triggered first.
{% tabs %}
{% tab title="whenReadyFromCache()" %}
```javascript
client.whenReadyFromCache().then(() => {
// SDK_READY_FROM_CACHE event has been emitted
const treatment = client.getTreatment("FEATURE_FLAG_NAME");
console.log("Treatment = " + treatment);
}).catch((e) => {
// SDK_READY_TIMED_OUT event has been emitted
console.error("SDK_READY_TIMED_OUT event emitted");
});
```
{% endtab %}
{% tab title="whenReady()" %}
```javascript
client.whenReady().then(() => {
// SDK_READY event has been emitted
const treatment = client.getTreatment("FEATURE_FLAG_NAME");
console.log("Treatment = " + treatment);
}).catch((e) => {
// SDK_READY_TIMED_OUT event has been emitted
console.error("SDK_READY_TIMED_OUT event emitted");
});
```
{% endtab %}
{% endtabs %}
#### User consent
The SDK allows you to disable the tracking of events and impressions until user consent is explicitly granted or declined.
The `userConsent` configuration parameter lets you set the initial consent status of the SDK instance, and the factory method `UserConsent.setStatus(boolean)` lets you grant (enable) or decline (disable) dynamic data tracking.
There are three possible initial states:
* `'GRANTED'`: The user grants consent for tracking events and impressions. The SDK sends them to Harness FME servers. This is the default value if `userConsent` param is not defined.
* `'DECLINED'`: The user declines consent for tracking events and impressions. The SDK does not send them to Harness FME servers.
* `'UNKNOWN'`: The user neither grants nor declines consent for tracking events and impressions. The SDK tracks them in its internal storage, and eventually either sends them or not if the consent status is updated to `'GRANTED'` or `'DECLINED'` respectively.
The status can be updated at any time with the `UserConsent.setStatus` factory method.
Working with user consent is demonstrated below.
```javascript
var factory = SplitFactory({
core: {
authorizationKey: 'YOUR_SDK_KEY',
key: 'key'
},
// Overwrites the initial consent status of the factory instance, which is 'GRANTED' by default.
// 'UNKNOWN' status represents that the user has neither granted nor declined consent for tracking data,
// so the SDK will locally track data but not send it to Harness FME servers until consent is changed to 'GRANTED'.
userConsent: 'UNKNOWN'
});
// `getStatus` method returns the current consent status.
factory.UserConsent.getStatus() === factory.UserConsent.Status.UNKNOWN;
// `setStatus` method lets you update the factory consent status at any time.
// Pass `true` for 'GRANTED' and `false` for 'DECLINED'.
factory.UserConsent.setStatus(true); // Consent status changed from 'UNKNOWN' to 'GRANTED'. Data will be sent to Harness FME servers.
factory.UserConsent.getStatus() === factory.UserConsent.Status.GRANTED;
factory.UserConsent.setStatus(false); // Consent status changed from 'GRANTED' to 'DECLINED'. Data will not be sent to Harness FME servers.
factory.UserConsent.getStatus() === factory.UserConsent.Status.DECLINED;
```
#### Usage with React SDK
The [React SDK](/feature-management-experimentation/new-to-fme/sdks-and-customer-deployed-components/client-side-sdks/client-side-standard-sdks/react-sdk.md) is a wrapper around the JavaScript SDK that provides a more React-friendly API based on React components and hooks. You can use the React Native SDK [with the React SDK in your React Native application](/feature-management-experimentation/new-to-fme/sdks-and-customer-deployed-components/client-side-sdks/client-side-standard-sdks/react-sdk.md#usage-with-react-native-sdk).
For an example application detailing how to configure and instantiate the Split React Native SDK, see the [React Native & Expo examples GitHub repository](https://github.com/splitio/react-native-sdk-example).