Angular SDK - OpenFeature

The @westyx-nexus/openfeature-provider-angular sub-package provides an OpenFeature Provider that wraps an existing NexusClient from @westyx-nexus/sdk-angular. No second connection is opened and no second cache is kept. The bridge subscribes to the same NexusClient that the rest of your application uses. Whenever the client replaces its in-memory snapshot (TTL poll or stream push), the provider emits ProviderEvents.ConfigurationChanged so the OpenFeature SDK re-evaluates.

Installation

The bridge is a separate npm package:

npm install @westyx-nexus/openfeature-provider-angular @openfeature/web-sdk

Your existing @westyx-nexus/sdk-angular package is the peer dependency - you already have it.

npm registry

Both packages are on the GitLab npm Package Registry. Add to your .npmrc:

@westyx-nexus:registry=https://gitlab.com/api/v4/projects/81978897/packages/npm/

Usage

Wiring up in `app.config.ts`

import { ApplicationConfig, inject, provideAppInitializer } from '@angular/core';
import { OpenFeature } from '@openfeature/web-sdk';
import { provideNexus, NEXUS_CLIENT_READY } from '@westyx-nexus/sdk-angular';
import { createOpenFeatureProvider } from '@westyx-nexus/openfeature-provider-angular';

export const appConfig: ApplicationConfig = {
  providers: [
    // 1. Nexus performs its blocking initial sync as an application initializer
    provideNexus({
      baseUrl: 'https://blue-ocean-a5rx7.westyx.dev',
      apiKey: 'wxp_...',
    }),
    // 2. OpenFeature is wired up to that client
    provideAppInitializer(async () => {
      // Angular starts every initializer before awaiting any of them, so the
      // client is awaited rather than injected here.
      const nexus = await inject(NEXUS_CLIENT_READY);
      return OpenFeature.setProviderAndWait(createOpenFeatureProvider(nexus));
    }),
  ],
};

The initializers run before Angular renders, so the cache is populated and setProviderAndWait has completed before the first evaluation.

Reading flags

Using @openfeature/angular-sdk:

import { useBooleanFlagValue } from '@openfeature/angular-sdk';

@Component({ ... })
export class MyComponent {
  showBanner = useBooleanFlagValue('banner.enabled', false);
}

Or using the raw OpenFeature client:

import { OpenFeature } from '@openfeature/web-sdk';

const client = OpenFeature.getClient();
const showBanner = client.getBooleanValue('banner.enabled', false);

NgModule-based apps

import { NgModule, inject, provideAppInitializer } from '@angular/core';
import { OpenFeature } from '@openfeature/web-sdk';
import { NexusModule, NEXUS_CLIENT_READY } from '@westyx-nexus/sdk-angular';
import { createOpenFeatureProvider } from '@westyx-nexus/openfeature-provider-angular';

@NgModule({
  imports: [
    NexusModule.forRoot({
      baseUrl: 'https://blue-ocean-a5rx7.westyx.dev',
      apiKey: 'wxp_...',
    }),
  ],
  providers: [
    provideAppInitializer(async () => {
      // Angular starts every initializer before awaiting any of them, so the
      // client is awaited rather than injected here.
      const nexus = await inject(NEXUS_CLIENT_READY);
      return OpenFeature.setProviderAndWait(createOpenFeatureProvider(nexus));
    }),
  ],
})
export class AppModule {}

Per-user targeting

When the evaluation context carries a targetingKey, a boolean evaluation is resolved for that user through the Nexus AB Testing add-on: the flag’s rollout percentage and cohort rules are applied to that identity, and the resolution reports TARGETING_MATCH.

await OpenFeature.setContext({ targetingKey: user.id, plan: 'pro', region: 'eu' });

// resolved for user.id, synchronously
const enabled = OpenFeature.getClient().getBooleanValue('checkout.v2', false);

Where the request happens

resolveBooleanEvaluation is synchronous in the OpenFeature Web SDK - there is no promise for it to await - and the Web SDK’s paradigm is a static evaluation context. So the provider asks the service when the context changes, not when a flag is read:

Trigger	What the provider does
`OpenFeature.setContext(...)`	Fetches the targeted values, and the Web SDK awaits it before the next evaluation.
`setProviderAndWait` with a context already carrying a targeting key	Fetches during `initialize`, so the first render is already targeted.
The client reports a configuration change (stream push or TTL poll)	Re-asks for the same identity, so a flag edited in the console reaches a targeted evaluation too.
A context change that alters neither the targeting key nor any string attribute	Nothing. A context object rebuilt with the same contents is a re-render, not a new question.
An evaluation	Nothing. It reads what the fetch produced.

One round trip covers every flag in the snapshot, so a page reading twenty flags costs one request, and concurrent triggers for the same identity coalesce into one. A snapshot with more than 200 flags is split into successive calls, which is the endpoint’s documented cap.

Attributes are strings

The service’s cohort matcher compares strings with eq / neq / in, so only string context fields are sent. A non-string field is left out and reported at debug level rather than converted - a coerced value that matches no rule is harder to diagnose than an absent one. Format at the call site (String(age), not age) and you know exactly what the rule is matched against. targetingKey is sent as the identity, never also as an attribute.

Reasons you will see

Reason	When
`STATIC`	No targeting key in the context - the synced snapshot is the answer. Also when the AB Testing add-on is not active for the project, where the snapshot is authoritative.
`TARGETING_MATCH`	A targeted answer for this identity. Percentage rollouts and cohort matches both report this: the endpoint returns a boolean per key and nothing that would distinguish them, so `SPLIT` cannot be reported honestly.
`STALE`	A targeting key is in force but there is no targeted answer for this flag - the request failed, or the flag entered the snapshot after the last fetch. The value is real, just not freshly targeted, and no error is reported: per the specification an error resolution returns the default value, which would hide a flag that is genuinely on behind one failed request.
`DEFAULT` + `FLAG_NOT_FOUND`	The service does not define this flag. No request is made - the endpoint answers `false` for a key it does not know, which is indistinguishable from “exists and off”.

If the add-on is not active

Projects without the AB Testing add-on get a 403 from the endpoint. The provider serves the snapshot with a STATIC reason and stops asking for five minutes at a time (addonSuppressionMs), so an inactive add-on costs one request per window rather than one per context change. It is a throttle, not a latch: buying the add-on starts producing targeted results within the window, with nothing to restart, and any success clears it immediately.

Provider options

createOpenFeatureProvider(nexus, {
  logger: console,
  addonSuppressionMs: 300_000,
});

Option	Default	Notes
`logger`	OpenFeature’s `DefaultLogger`	Where the provider’s diagnostics go: a dropped non-string context field, a failed targeted fetch, an inactive add-on. The fetch happens in `onContextChange` and `initialize`, and the Web SDK hands a logger only to the resolve methods - so the calls with something to report have none in scope, which is why this option exists. The default discards `debug`; pass `console` to see them.
`addonSuppressionMs`	`300000`	How long to stop calling the endpoint after the service reports the add-on inactive. Validated at construction; a negative or non-finite value is rejected naming the option and the value.

There is deliberately no cache-lifetime option, unlike the server-side bridges. The targeted values are replaced on a context change and on a configuration change - both events rather than deadlines - so a time-to-live would have nothing to govern.

Flag resolution

OpenFeature method	Nexus lookup	Result
`getBooleanValue(key, default)`	`client.hasFlag(key)`, then the targeted values or `client.getFlag(key)`	See Reasons you will see. `variant` is `"true"` or `"false"`.
`getStringValue(key, default)`	`client.getConfig(key)`	`STATIC` if present and a string; `DEFAULT` + `FLAG_NOT_FOUND` if absent or JSON `null`; `ERROR` + `TYPE_MISMATCH` otherwise.
`getNumberValue(key, default)`	`client.getConfig(key)`	`STATIC` if present and a number, or a `bigint` a `number` holds exactly; `DEFAULT` + `FLAG_NOT_FOUND` if absent or JSON `null`; `ERROR` + `TYPE_MISMATCH` otherwise - including for a numeric string, which is not a number.
`getObjectValue(key, default)`	`client.getConfig(key)`	`STATIC` if present and an object or array; `DEFAULT` + `FLAG_NOT_FOUND` if absent or JSON `null`; `ERROR` + `TYPE_MISMATCH` for a primitive. No `variant`: a composite value has no short semantic identifier.

Boolean flags come from feature flags; string, number and object evaluations come from config values. Config values are never targeted - evaluate-ab is a flag concept, so there is no such thing as a targeted config value. Inside a resolved object or array, an integer beyond Number.MAX_SAFE_INTEGER is carried as its exact decimal string, at any depth - OpenFeature’s JsonValue has no numeric slot that holds it exactly, and the decimal string is the lossless one, so the resolved value survives JSON.stringify. Ordinary numbers are untouched; parse the string with BigInt(value) where the magnitude matters. A TYPE_MISMATCH message names the type that arrived, so it is actionable without opening the configuration.

Live updates

The provider calls client.subscribe(listener) in initialize() and stores the returned unsubscribe function. When the NexusClient replaces its snapshot the listener fires, the provider emits ProviderEvents.ConfigurationChanged, and the OpenFeature SDK re-evaluates - so any UI using @openfeature/angular-sdk re-renders. The client’s listener also fires for a stream state transition, for a 304 and for the billing and quarantine flags, none of which changed a flag; the provider compares client.snapshotRevision and acts only on a real configuration change, so a reconnect costs no request and triggers no re-render. The same listener re-asks for the targeted values. That refresh emits a second ConfigurationChanged only when the values actually moved: announcing an unchanged refresh would re-render every component bound to a flag on every sync. onClose() unsubscribes the listener and drops the stored identity.

`NexusClientLike` interface

The provider’s constructor accepts a NexusClientLike interface rather than the concrete NexusClient class, so the package needs no build-time dependency on @westyx-nexus/sdk-angular - an Angular library’s typings live in its build output. Any object satisfying it works:

export interface NexusClientLike {
  getFlag(key: string, defaultValue?: boolean): boolean;
  hasFlag(key: string): boolean;
  getFlagKeys(): string[];
  getConfig(key: string): unknown;
  readonly snapshotRevision: number;
  subscribe(listener: () => void): () => void;
  evaluateAB(
    keys: string[],
    userId: string,
    attributes?: Record<string, string>,
  ): Promise<Record<string, boolean>>;
}

The real NexusClient inherits every member from the shared browser core.

Version

Latest release: v0.17.0. The bridge requires @westyx-nexus/sdk-angular v0.17.0 or newer - it is declared as a peer dependency, so npm will tell you if the two are out of step. The floor follows the release, so a consumer never resolves an SDK older than the bridge that wraps it. @openfeature/core is a direct dependency of the bridge. @openfeature/web-sdk declares it as a peer and imports it at runtime, so it must be present; it is resolved for you.

Overview

Backend SDKs

Browser SDKs

OpenFeature Providers

Angular SDK - OpenFeature

Installation

npm registry

Usage

Wiring up in `app.config.ts`

Reading flags

NgModule-based apps

Per-user targeting

Where the request happens

Attributes are strings

Reasons you will see

If the add-on is not active

Provider options

Flag resolution

Live updates

`NexusClientLike` interface

Version

​Installation

​npm registry

​Usage

​Wiring up in app.config.ts

​Reading flags

​NgModule-based apps

​Per-user targeting

​Where the request happens

​Attributes are strings

​Reasons you will see

​If the add-on is not active

​Provider options

​Flag resolution

​Live updates

​NexusClientLike interface

​Version

Installation

npm registry

Usage

Wiring up in `app.config.ts`

Reading flags

NgModule-based apps

Per-user targeting

Where the request happens

Attributes are strings

Reasons you will see

If the add-on is not active

Provider options

Flag resolution

Live updates

`NexusClientLike` interface

Version