FFL-2753 Add browser CoreProvider by sameerank · Pull Request #336 · DataDog/openfeature-js-client

sameerank · 2026-07-10T14:55:56Z

Summary

Add an opt-in browser CoreProvider that evaluates a caller-supplied FlagsConfiguration without fetching or polling configuration.

This PR also extends the shared core configuration/evaluation layer so portable configuration can carry and evaluate rules-based config:

@datadog/flagging-core now supports a rulesBased slot in FlagsConfiguration and configurationFromString() / configurationToString().
@datadog/flagging-core exports the shared evaluate(...) helper used by browser OpenFeature providers.
@datadog/openfeature-browser exports CoreProvider and keeps the existing DatadogProvider API unchanged.
Browser evaluation now uses matching precomputed assignments first, then rules-based evaluation when available.
Precomputed-only configurations no longer resolve against a mismatched context.
extraLogging remains part of Datadog flag configuration data, but is not exposed through OpenFeature flagMetadata.

Why

FFL-2753 is the browser provider layer for the portable configuration / dynamic context work. Customers can bootstrap or otherwise provide a generic configuration wire payload and use CoreProvider to evaluate locally. When that payload includes rules-based configuration, OpenFeature context changes are handled locally without a network round trip.

Behavior

CoreProvider implements the browser OpenFeature Provider interface.
initialize() validates the initial configuration/context and follows OpenFeature's async lifecycle signature.
onContextChange() validates the new context synchronously and lets OpenFeature handle thrown lifecycle errors.
setConfiguration() replaces the active config and emits Ready, ConfigurationChanged, or Error because it is a provider-owned mutator rather than an OpenFeature lifecycle callback.
Precomputed configs are only used when their stored context matches the evaluation context. If rules-based config is also available, it is used as the fallback path.
The existing DatadogProvider no-config fallback behavior is preserved.

Release Plan

Because @datadog/openfeature-browser now imports the shared evaluate(...) helper from @datadog/flagging-core, publish a new @datadog/flagging-core version first. Then update the browser package to depend on that released core version before publishing @datadog/openfeature-browser.

The existing DatadogProvider behavior is preserved; the new CoreProvider remains opt-in.

Validation

node .yarn/releases/yarn-4.10.3.cjs workspace @datadog/flagging-core test --watchman=false
node .yarn/releases/yarn-4.10.3.cjs workspace @datadog/flagging-core typecheck
node .yarn/releases/yarn-4.10.3.cjs workspace @datadog/openfeature-browser test --watchman=false
node .yarn/releases/yarn-4.10.3.cjs workspace @datadog/openfeature-browser typecheck
node .yarn/releases/yarn-4.10.3.cjs workspace @datadog/openfeature-browser build
node .yarn/releases/yarn-4.10.3.cjs prettier --check packages/browser/src/openfeature/core-provider.ts
git diff --check

dd-oleksii · 2026-07-13T11:26:46Z

+  constructor(options: CoreProviderOptions) {
+    this.events = new OpenFeatureEventEmitter()
+    this.flagsConfiguration = options.configuration
+    this.status = hasEvaluatableConfiguration(options.configuration) ? ProviderStatus.READY : ProviderStatus.ERROR


status is deprecated / unused, so we can leave it out

Suggested change

this.status = hasEvaluatableConfiguration(options.configuration) ? ProviderStatus.READY : ProviderStatus.ERROR

efb2034 removes the CoreProvider status field

dd-oleksii · 2026-07-13T11:32:20Z

+    this.status = ProviderStatus.READY
+  }
+
+  async onContextChange(_oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> {


minor: does it make sense to make initialize and onContextChange sync?

Suggested change

async onContextChange(_oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> {

onContextChange(_oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> {

Good call for onContextChange. The web provider signature allows sync context changes:

onContextChange?(oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> | void;

https://github.com/open-feature/js-sdk/blob/bc470dca88afa26462b2513e2d106df324e7ba46/packages/web/src/provider/provider.ts#L34

So I can remove async there and change the return type to void, which also avoids OpenFeature treating rules-based context changes as async reconciliation.

For initialize though, I believe we still need to return a promise to match the shared provider contract:

initialize?(context?: EvaluationContext): Promise<void>;

https://github.com/open-feature/js-sdk/blob/bc470dca88afa26462b2513e2d106df324e7ba46/packages/shared/src/provider/provider.ts#L128

The SDK calls .then(...) on the returned value to mark the provider ready, so a truly sync initialize(): void would not be compatible with the current OpenFeature implementation.

https://github.com/open-feature/js-sdk/blob/bc470dca88afa26462b2513e2d106df324e7ba46/packages/shared/src/open-feature.ts#L256-L258

9cf1ccc makes CoreProvider context changes synchronous

dd-oleksii · 2026-07-13T11:34:24Z

+    const error = getConfigurationError(this.flagsConfiguration, this.context)
+    if (error) {
+      this.status = ProviderStatus.ERROR
+      this.events.emit(ProviderEvents.Error, { error })


Why do we emit an event here but not on ready path?

f151909 removes the explicit error emit from onContextChange, so CoreProvider treats OpenFeature lifecycle methods consistently:

initialize(...) updates context and throws if invalid; OpenFeature handles provider readiness/error lifecycle.

onContextChange(...) updates context and throws if invalid; OpenFeature handles the context-change error lifecycle.

setConfiguration(...) still emits Ready, ConfigurationChanged, or Error because that method is our own provider API, not an OpenFeature lifecycle callback.

dd-oleksii · 2026-07-13T11:35:42Z

+    if (!hasEvaluatableConfiguration(this.flagsConfiguration)) {
+      return {
+        value: defaultValue,
+        reason: 'ERROR',
+        errorCode: 'PROVIDER_NOT_READY' as ErrorCode,
+      }
+    }


nitpick: this check looks like something that evaluate should handle

f011597 moves missing configuration fallback into evaluate

A follow up 9c4e415 fixes the consequence of this change: CoreProvider should return PROVIDER_NOT_READY when it has no configuration, but the pre-existing DatadogProvider tests expected the old behavior: return the caller’s default value with reason DEFAULT before fetched config is available. Or should I switch them both to PROVIDER_NOT_READY? I hesitate because changing the server side evaluation feels like creeping beyond the scope of what we're trying to do here

dd-oleksii · 2026-07-13T11:36:43Z

+  private getEvaluationContext(context: EvaluationContext): EvaluationContext {
+    if (Object.keys(context).length > 0 || Object.keys(this.context).length === 0) {
+      return context
+    }
+    return this.context
+  }


why is this needed? have you seen openfeature sdk passing the wrong context?

Yep, unnecessary. 21195fb removes getEvaluationContext and relies on the OpenFeature to pass the right evaluation context into the provider resolve methods

dd-oleksii · 2026-07-13T11:43:45Z

        flagMetadata: {
          allocationKey: 'allocation-123',
          doLog: true,
+          extraLogging: { experiment: true },


major:

extraLogging is deprecated.

it's Record<string, string> (boolean not allowed).

flagMetadata only allows boolean, string, and number values (nested object is not allowed)

1ad76ed removes extraLogging from flag metadata

dd-oleksii · 2026-07-13T11:49:46Z

+import { configurationFromString, CoreProvider } from '@datadog/openfeature-browser'
+import { OpenFeature } from '@openfeature/web-sdk'
+
+const configuration = configurationFromString(window.__DD_FLAGS_CONFIGURATION__)


minor: users might get confused about __DD_FLAGS_CONFIGURATION__ — what's that and how it is set. Maybe we should hint that it's just a string and they should transfer it however they want, or say that __DD_FLAGS_CONFIGURATION__ is set by SSR process?

Suggested change

const configuration = configurationFromString(window.__DD_FLAGS_CONFIGURATION__)

const configuration = configurationFromString("...flags configuration string...")

34b3e80 updates the portable configuration string example

dd-oleksii · 2026-07-13T11:50:56Z

+await OpenFeature.setContext({ targetingKey: 'user-123', plan: 'enterprise' })
+
+const client = OpenFeature.getClient()
+const enabled = await client.getBooleanValue('new-checkout', false)


minor: web evalulation methods are sync:

Suggested change

const enabled = await client.getBooleanValue('new-checkout', false)

const enabled = client.getBooleanValue('new-checkout', false)

9371b90 documents browser evaluations as synchronous

dd-oleksii · 2026-07-13T11:52:29Z

            allocationKey: allocation.key,
            variationType: variantTypeToFlagValueType(flag.variationType),
            doLog: !!allocation.doLog,
+            extraLogging: selectedSplit.extraLogging,


major: extraLogging is deprecated and violates flagMetadata spec requirements (only string, boolean, and number values are allowed — not nested object)

dd-oleksii · 2026-07-13T11:54:29Z

+  error: () => {},
+}

 export function evaluate<T extends FlagValueType>(


minor: are we able to move evaluation function to the core package?

Sure, moved in 86081da

Will have to do a 2.0.1 release for @datadog/flagging-core and update the @datadog/openfeature-browser dependency before we can release

FFL-2753 Add browser CoreProvider

cdada42

sameerank marked this pull request as ready for review July 10, 2026 21:29

sameerank requested a review from a team as a code owner July 10, 2026 21:29

sameerank requested review from dd-oleksii and pavlokhrebto and removed request for a team July 10, 2026 21:29

dd-oleksii reviewed Jul 13, 2026

View reviewed changes

sameerank added 12 commits July 14, 2026 08:01

Remove CoreProvider status field

efb2034

Make CoreProvider context changes synchronous

9cf1ccc

Let OpenFeature handle context change errors

f151909

Move missing configuration fallback into evaluate

f011597

Use OpenFeature evaluation context directly

21195fb

Remove extraLogging from flag metadata

1ad76ed

Clarify portable configuration string example

34b3e80

Document browser evaluations as synchronous

9371b90

Move browser evaluation helper to core

86081da

Preserve DatadogProvider default fallback

9c4e415

Avoid networked provider setup in local tests

47e49b0

Fix CoreProvider formatting

6a3d86c

sameerank requested a review from dd-oleksii July 15, 2026 13:57

	async onContextChange(_oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> {
	onContextChange(_oldContext: EvaluationContext, newContext: EvaluationContext): Promise<void> {

	const configuration = configurationFromString(window.__DD_FLAGS_CONFIGURATION__)
	const configuration = configurationFromString("...flags configuration string...")

	const enabled = await client.getBooleanValue('new-checkout', false)
	const enabled = client.getBooleanValue('new-checkout', false)

Uh oh!

Conversation

sameerank commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Behavior

Release Plan

Validation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sameerank Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sameerank Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sameerank commented Jul 10, 2026 •

edited

Loading

sameerank Jul 14, 2026 •

edited

Loading

sameerank Jul 14, 2026 •

edited

Loading