-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: use mutate context hook #1031
Conversation
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:
I'll look into the licensing issue. |
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
@@ -136,5 +139,74 @@ describe('OpenFeatureProvider', () => { | |||
await waitFor(() => expect(screen.queryByText('👍')).toBeInTheDocument(), { timeout: DELAY * 2 }); | |||
}); | |||
}); | |||
|
|||
describe('useMutateContext', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@beeme1mr I have set this up. In this scenario, it will update both <TestComponents />
. Is that the expected behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you're correct. Is there something wrong with my example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 === 'bob@flags.com'
, 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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you cleared it up! i think testing is all set then unless we need more cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, looks that way to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you! :)
I left one comment to be considered.
…ange Co-authored-by: Lukas Reining <lukas.reining@codecentric.de> Signed-off-by: Will C. <iam@willchou.dev>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Will Chou <w.chou06@gmail.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Minor refactors, but mostly adding js-doc after #1031. --------- Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
🤖 I have created a release *beep* *boop* --- ## [0.4.7](react-sdk-v0.4.6...react-sdk-v0.4.7) (2024-10-29) ### ✨ New Features * avoid re-resolving flags unaffected by a change event ([#1024](#1024)) ([b8f9b4e](b8f9b4e)) * implement tracking as per spec ([#1020](#1020)) ([80f182e](80f182e)) * use mutate context hook ([#1031](#1031)) ([ec3d967](ec3d967)) ### 🧹 Chore * add js docs for context mutator hook ([#1045](#1045)) ([def3fe8](def3fe8)) * import type lint rule and fixes ([#1039](#1039)) ([01fcb93](01fcb93)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Signed-off-by: OpenFeature Bot <109696520+openfeaturebot@users.noreply.github.com>
This PR
New hook for mutating context instead of using the global object
Related Issues
Fixes #968
Notes
Follow-up Tasks
How to test