Where and when do I set a targetingkey in the Evaluation context if a provider requires one?

[RobertDiebels]

I'm currently using the OpenFeature Angular SDK with the GoFeatureFlagProvider and it requires a targetingKey to be set on the OpenFeature Context.

However, I am unable to find where and when I should do this, as there is no documentation.
The documentation only specifies that it should be done using:

OpenFeature.setContext({targetingKey: "some-key"});

Can someone provide some guidance regarding this issue?

[lukas-reining]

Hey @RobertDiebels, you are right, we should add a section for this to the docs.
In general, the Web SDK which the Angular SDK is based on, follows the static context paradigm (https://openfeature.dev/docs/reference/concepts/sdk-paradigms#static-context-paradigms-client-side-sdks)

That means, that evaluation context will be set in the code at a central place using:

OpenFeature.setContext({targetingKey: "some-key"});

This should happen before the first evaluation in your case, as Go Feature Flag will fail without.
You can also set it, once you have the information, and check the evaluation reason for an error.

Do you need any more specific examples? Or any other suggestions?

Also, we could add a parameter to the SDK to receive the context, I will pick that up :)

[RobertDiebels]

Thanks for the answer @lukas-reining .

In our case we have several modules in a NX monorepo set up with Module Federation.
We are currently supplying the OpenFeature module in a non-root module and setting the context in that same module file as follows:

"Do you need any more specific examples? Or any other suggestions?"

(Doing this from memory as I'm not at work rn.)

import {OpenFeature, OpenFeatureModule} from '@openfeature/angular';

OpenFeature.setContext({targetingKey: "some-key"});

@Module({imports: [OpenFeatureModule.forRoot()]})
export class SubModule{}

This works for us, however, when we move the import to the root module, directives seem to no longer function.
We have tried to place the OpenFeature.setContext in a appInitizializer provider which did not work.
Eventually we will need to set the context when a user logs in, but for our POC this is enough.

"This should happen before the first evaluation in your case"

Does this mean that the targetinKey should be set once on application initialization (for anonymous users) and once as soon as a user logs in?
Because I thought I read somewhere that the targetingKey should be used to uniquely identify a user, ensuring that flags are kept consistent across applications. That would mean anonymous users who encounter a flag must also have a context.

[lukas-reining]

This works for us, however, when we move the import to the root module, directives seem to no longer function.

Hey, I am not able to replicate the problem. How does it show that it does not work? Are you getting errors? Or if not, what is the evaluationReason @RobertDiebels?

We have tried to place the OpenFeature.setContext in a appInitizializer provider which did not work.
Eventually we will need to set the context when a user logs in, but for our POC this is enough.

What did not work about this? Did you get an error?

Does this mean that the targetinKey should be set once on application initialization (for anonymous users) and once as soon as a user logs in?
Because I thought I read somewhere that the targetingKey should be used to uniquely identify a user, ensuring that flags are kept consistent across applications. That would mean anonymous users who encounter a flag must also have a context.

Yes, if you need to have working evaluations without the user beeing logged in, you should set some value (like a UUID) that you save in localstorage to be able to send that consistently with every page load for this user when they are not logged in.

So setting the targetingId to a "user static" UUID before the module is initialized and then setting it to the real user id would be the right way to go.
If you do not do A/B tests, you could also set the targeting id to a value like anonymous, but if you want to have gradual rollouts this would be problematic.

[lukas-reining]

Hey @RobertDiebels,we updated the SDK and the docs to show how setting context is intended: https://github.com/open-feature/js-sdk/tree/main/packages/angular/projects/angular-sdk#setting-evaluation-context

You now have the option to give the evaluation context to the module like shown in the following:

const initialContext = {
  user: {
    id: 'user123',
    role: 'admin',
  }
};

@NgModule({
  imports: [
    OpenFeatureModule.forRoot({
      provider: yourFeatureProvider,
      context: initialContext
    })
  ],
})
export class AppModule {}

Does that solve your issue?
I also tried to reproduce your issue with injecting the OpenFeatureModule at root level but it works for me using ApplicationConfig and standalone components like:

export const appConfig: ApplicationConfig = {
  providers: [
    provideZoneChangeDetection({ eventCoalescing: true }),
    provideRouter(routes),
    provideHttpClient(),
    provideAnimationsAsync(),
    importProvidersFrom(
      MsalModule.forRoot(....),
      ....
      OpenFeatureModule.forRoot({
        context: { host: window.location.host },
        provider: new OFREPWebProvider({
          baseUrl: environment.flagdOfrepUrl,
        }),
      })
    ),
  ],
};

but also for traditional AppModule.
In both setups, the directives are working for me even in nested situations.
The only thing you have to keep in mind is to import the directive into the components like:

@Component({
  selector: 'app-root',
  templateUrl: './my-component.component.html',
  styleUrl: './my-component.component.scss',
  imports: [
    BooleanFeatureFlagDirective,
    ....
  ],
})
export class MyComponent {
....
}

[lukas-reining]

It would be really helpful if you can confirm this working or give some more information about your issue @RobertDiebels :)

[RobertDiebels]

@lukas-reining

It would be really helpful if you can confirm this working or give some more information about your issue

I will try to see if I can still replicate this somewhere next week. If the issue still occurs I will set up a reproduction repo so you can verify, since our actual setup is more complex than the above.

You now have the option to give the evaluation context to the module like shown in the following:

This is excellent btw. thanks! Will make sure to add this.

[lukas-reining]

Thanks @RobertDiebels, that would be great!

[RobertDiebels]

@lukas-reining Would like to notify you that we've added the context solution you provided, and everything is working as expected. Much appreciated!