feat: use mutate context hook

[wichopy]

This PR

New hook for mutating context instead of using the global object

Related Issues

Fixes #968

Notes

Follow-up Tasks

How to test

[beeme1mr]

Could you please sign off on your commits? It's basically a way to tell the CNCF that you're willing and able to donate this code.

To add your Signed-off-by line to every commit in this branch:

• Ensure you have a local copy of your branch by checking out the pull request locally via command line.
• In your local branch, run: git rebase HEAD~5 --signoff
• Force push your changes to overwrite the branch: git push --force-with-lease origin wichopy/968

For future commits, you can add -s when running git commit.

I'll look into the licensing issue.

[beeme1mr]

These tests look great but could you please add one more for the following setup?

<OpenFeatureProvider domain={DOMAIN1}>
  <React.Suspense fallback={<div>{FALLBACK}</div>}>
    <TestComponent name="Will" />
    <OpenFeatureProvider>
      <React.Suspense fallback={<div>{FALLBACK}</div>}>
        <TestComponent name="Todd" />
      </React.Suspense>
    </OpenFeatureProvider>
  </React.Suspense>
</OpenFeatureProvider>

The nested component should update the global context.

[wichopy]

@beeme1mr I have set this up. In this scenario, it will update both <TestComponents />. Is that the expected behaviour?

[beeme1mr]

I'd like a test that ensures that updating context in the nested component updates the global context and not the domain scoped context. The other component probably isn't necessary in the test.

[wichopy]

The reason I'm asking is it seems like something is wrong, shouldn't domain scoped children be unchanged even if the global context changes?

[beeme1mr]

Yes, you're correct. Is there something wrong with my example?

[toddbaert]

See: https://github.com/open-feature/js-sdk/pull/1031/files#r1801753490

[wichopy]

@toddbaert adding a property to set global or not doesn't solve the issue I brought up though.

I've added a test with the global context having a different flag key and variants than the domain scoped one. The domain and global provider context evaluators both listen to user === '[email protected]', but now only the global context flag variant changes instead of both global and domain scoped.

When the providers are the same (same flag keys and variants) they both update when global context is nested under domain context. Did I find a bug or is this desired behaviour?

[toddbaert]

I'm not 100% sure I understand your last comment. But I can confirm what @beeme1mr said here:

Basically, domain-scoped context is only managed separately if it's explicitly set for the domain.

Basically, if you don't set a context for domain X, it will use the default context. If you DO set a context for domain X, it uses that context (this is analogous to how providers are bound to domains as well. Does that clear things up?

My point about the option was somewhat separate: just that users might want to update either of these from their component, and either is valid.

[wichopy]

i think you cleared it up! i think testing is all set then unless we need more cases.

[toddbaert]

Yes, looks that way to me.

[lukas-reining]

Looks good, thank you! :)
I left one comment to be considered.

[toddbaert]

LGTM @wichopy ! Thanks so much! I might make some additional small doc changes before we release, and we have some other features soon ready so I'll wait until they are all done, but this will be released soon.