-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
fix(reactivity): should not track effect in onScopeDispose
#7265
base: main
Are you sure you want to change the base?
Conversation
activeEffectScope.cleanups.push(() => { | ||
pauseTracking() | ||
fn() | ||
resetTracking() | ||
}) |
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 very familiar with this part of the codebase, but I did have a couple of thoughts...
- Is there a reason to call
pauseTracking()
andresetTracking()
inside each cleanup function, rather than doing it once instop
, either side of thefor
loop that invokes these functions? - Do we need to handle error cases here? I notice that
run
usestry
/finally
for something similar. I'm thinking mayberesetTracking()
should be in afinally
block?
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.
Updated, thanks for your reivew.
console.error( | ||
'An error occurred while executing a cleanup function:', | ||
e, | ||
) |
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.
This isn't what I had in mind when I suggested handling the error cases. I just meant putting the resetTracking()
call in a finally
block to ensure it always gets called. Perhaps there are more complete ways to handle errors, but that feels like it's out of scope for the tracking changes being proposed in this PR.
There are a couple of problems with the error handling being proposed here:
- This error message would be included in production builds, impacting bundle size. Error messages generally aren't included in production builds.
- Catching the errors will prevent them being handled by
app.config.errorHandler
.
For example, consider this Playground:
Notice that clicking the button triggers the errorHandler
. Contrast that with how it behaves with this PR:
I don't think this is desirable.
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 agree with @skirtles-code.
Size ReportBundles
Usages
|
commit: @vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
|
@@ -115,6 +115,7 @@ export class EffectScope { | |||
|
|||
stop(fromParent?: boolean): void { | |||
if (this._active) { | |||
pauseTracking() |
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 changes should like below:
stop(fromParent?: boolean): void {
if (this._active) {
try{
pauseTracking()
//...
} finally {
resetTracking()
}
}
}
Fixes #6538