---
title: Client-Side Feature Flags
description: Set up Datadog Feature Flags for client-side applications.
breadcrumbs: Docs > Feature Flags > Client-Side Feature Flags
---

# Client-Side Feature Flags

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ().
{% /alert %}

{% /callout %}

## Overview{% #overview %}

Set up Datadog Feature Flags for your applications. Follow the platform-specific guides below to integrate feature flags into your application and start collecting feature flag data:

- [Android](https://docs.datadoghq.com/feature_flags/client/android/)
- [Android TV](https://docs.datadoghq.com/feature_flags/client/android/)
- [Angular](https://docs.datadoghq.com/feature_flags/client/angular/)
- [iOS](https://docs.datadoghq.com/feature_flags/client/ios/)
- [JavaScript](https://docs.datadoghq.com/feature_flags/client/javascript/)
- [React](https://docs.datadoghq.com/feature_flags/client/react/)
- [React Native](https://docs.datadoghq.com/feature_flags/client/reactnative/)
- [tvOS](https://docs.datadoghq.com/feature_flags/client/ios/)
- [Unity](https://docs.datadoghq.com/feature_flags/client/unity/)

## Testing with in-memory providers{% #testing-with-in-memory-providers %}

Datadog supports these testing approaches:

- **Integration tests**: Point `DatadogProvider` at a dedicated test environment and control flag values from the Datadog UI. This exercises the real provider end-to-end, including the CDN-delivered flag assignments.
- **Unit tests**: Swap `DatadogProvider` for OpenFeature's standard `InMemoryProvider` (or an equivalent test stub, where no in-memory provider is available in the language) and set flag values directly in test code. This keeps tests hermetic and offline.

This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.

A typical test follows this pattern:

1. Build a map of flag keys to variants in your test setup.
1. Register an `InMemoryProvider` with that map through the OpenFeature API.
1. Call the OpenFeature client in the units being tested. The `InMemoryProvider` returns the flag assignments configured at test setup.
1. Reset the provider in test teardown to avoid cross-test state leakage.

See your platform's SDK page (select from the top of this page) for a concrete test example.

## Context attribute requirements{% #context-attribute-requirements %}

{% alert level="warning" %}
Evaluation context attributes must be flat primitive values (strings, numbers, booleans). Nested objects and arrays are **not supported** and will cause exposure events to be silently dropped.
{% /alert %}

Use flat attributes in your evaluation context:

```javascript
const evaluationContext = {
  targetingKey: 'user-123',
  userId: 'user-123',
  tier: 'premium',
  age: 25
};

await OpenFeature.setProviderAndWait(provider, evaluationContext);
```

Avoid nested objects and arrays:

```javascript
// These attributes will cause exposure events to be dropped
const evaluationContext = {
  targetingKey: 'user-123',
  user: { id: 'user-123' },        // nested object - NOT SUPPORTED
  features: ['beta', 'analytics']  // array - NOT SUPPORTED
};
```

## Further reading{% #further-reading %}

- [Learn about Feature Flags](https://docs.datadoghq.com/feature_flags.md)
- [Getting Started with Feature Flags](https://docs.datadoghq.com/getting_started/feature_flags.md)
- [Server-Side Feature Flags](https://docs.datadoghq.com/feature_flags/server.md)