-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(core): Add withIsolationScope
#10141
Conversation
size-limit report 📦
|
packages/core/src/exports.ts
Outdated
@@ -208,6 +209,15 @@ export function withScope<T>( | |||
return getCurrentHub().withScope(rest[0]); | |||
} | |||
|
|||
/** | |||
* TODO |
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 there's still something missing 😅
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.
Thank you!
*/ | ||
export function withIsolationScope<T>(callback: (isolationScope: Scope) => T): T { | ||
return runWithAsyncContext(() => { | ||
return callback(getIsolationScope()); |
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.
to sanity check: runWithAsyncContext
forks the hub for the new async local storage and hence isolation and current scope, correct?
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.
Technically the answer to your question is no. runWithAsyncContext
only forks the hub when there is an async context strategy set. In the browser this is not the case so the isolation scope will always be the same. This may seem odd, but as a side-effect will prevent users, who think async context keeping works in the browser, from running into race conditions.
(Side note: This is also the reason why I didn't add any forking tests in the core package, simply because we cannot make this assumption.)
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.
Right sorry, it's the async context strategy that takes care of it.
This adds a global API
withIsolationScope<T>((isolationScope: Scope) => T): T
.withIsolationScope()
will fork the currentisolationScope
and the currentscope
. The callback is passed the isolation scope that is active within the callback.withIsolationScope()
is mostly intended for developing SDKs and is generally not recommended to be used by SDK consumers directly.This function makes use of the provided async context strategy in the SDK. In the browser, this means it does effectively nothing as of now.
For reviewers:
This PR looks a bit goofy because it is literally wrapping
runWithAsyncContext
, however, this is probably exactly what we want this function to do until we have fully deprecated the hub.We cannot make assertions in the
core
package thatwithIsolationScope()
will fork the current isolation scope as this requires an async context strategy, which core by itself doesn't set. This is why the tests in the core package look a bit slim.