Skip to content
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: withScope returns from wrapped function #3753

Closed
wants to merge 1 commit into from

Conversation

rhcarvalho
Copy link
Contributor

This is part of a larger work towards better scope management. See #3751.

This change makes Sentry.withScope and Hub.withScope easier to use with existing functions that return a non-void type.

The motivation is that withScope could be used to wrap existing functions and run them in a new scope without requiring a closure or mutating state outside of the wrapped function (since it had to be void).

While this does change the withScope signature, we're considering it relatively low risk of breaking downstream code as we're making it more general.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 25, 2021

size-limit report

Path Size
@sentry/browser - CDN Bundle (gzipped) 21.39 KB (+0.01% 🔺)
@sentry/browser - Webpack 22.41 KB (+0.02% 🔺)
@sentry/react - Webpack 22.44 KB (+0.02% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped) 28.88 KB (0%)

return 'ok';
};
const hub = new Hub();
const value = hub.withScope(someFn); // wraps someFn to run it in a new scope
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to write...

Suggested change
const value = hub.withScope(someFn); // wraps someFn to run it in a new scope
// wrapped wraps someFn to run it in a new scope
const wrapped = () => hub.withScope(someFn);
const value = wrapped();

... because we wanted withScope (and, eventually, Sentry.trace) to be easier to write wrapped versions of existing functions.

However, by delaying evaluation with () => ..., we're also delaying the evaluation of what is the current scope, which is not what one would typically want. Thus, the current form is only good for wrap-and-call existing functions.

This is part of a larger work towards better scope management.

This change makes Sentry.withScope and Hub.withScope easier to use with
existing functions that return a non-void type.

The motivation is that withScope could be used to wrap existing
functions and run them in a new scope without requiring a closure or
mutating state outside of the wrapped function (since it had to be
void).

While this does change the withScope signature, we're considering it
relatively low risk of breaking downstream code as we're making it more
general.
@rhcarvalho rhcarvalho force-pushed the rhcarvalho/withscope branch from f9c71ff to a498172 Compare June 29, 2021 15:35
@rhcarvalho rhcarvalho marked this pull request as ready for review June 29, 2021 15:37
@rhcarvalho rhcarvalho requested a review from kamilogorek as a code owner June 29, 2021 15:37
Copy link
Member

@AbhiPrasad AbhiPrasad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll wait till we get another web platform +1 before we merge

@rhcarvalho
Copy link
Contributor Author

@mitsuhiko || @HazAT || @kamilogorek could you please review?

@rhcarvalho
Copy link
Contributor Author

Probably not going to merge this as the current direction to introduce a Sentry.trace function doesn't rely on withScope (instead focusing on better Hub propagation), making this change unnecessary risk.

@rhcarvalho
Copy link
Contributor Author

Not going to merge this. It became unclear whether this change is necessary, in face of larger conceptual changes required to handle scope management different than what we have today.

More details on lessons learned shall go into getsentry/develop#356.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants