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.