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

fix(reactivity): should not track effect in onScopeDispose #7265

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

rudyxu1102
Copy link
Contributor

@rudyxu1102 rudyxu1102 commented Dec 2, 2022

Fixes #6538

Comment on lines 129 to 161
activeEffectScope.cleanups.push(() => {
pauseTracking()
fn()
resetTracking()
})
Copy link
Contributor

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...

  1. Is there a reason to call pauseTracking() and resetTracking() inside each cleanup function, rather than doing it once in stop, either side of the for loop that invokes these functions?
  2. Do we need to handle error cases here? I notice that run uses try/finally for something similar. I'm thinking maybe resetTracking() should be in a finally block?

Copy link
Contributor Author

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.

Comment on lines +156 to +159
console.error(
'An error occurred while executing a cleanup function:',
e,
)
Copy link
Contributor

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:

  1. This error message would be included in production builds, impacting bundle size. Error messages generally aren't included in production builds.
  2. 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.

Copy link
Member

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.

Copy link

Size Report

Bundles

File Size Gzip Brotli
runtime-dom.global.prod.js 99.2 kB (+105 B) 37.6 kB (+59 B) 33.8 kB (+45 B)
vue.global.prod.js 157 kB (+105 B) 57.4 kB (+56 B) 51 kB (-44 B)

Usages

Name Size Gzip Brotli
createApp 54.5 kB (+10 B) 21.1 kB (+4 B) 19.3 kB (+15 B)
createSSRApp 58.5 kB (+10 B) 22.8 kB (+5 B) 20.7 kB (+3 B)
defineCustomElement 59.1 kB (+10 B) 22.6 kB (+5 B) 20.6 kB (+37 B)
overall 68.1 kB (+10 B) 26.2 kB (+5 B) 23.8 kB (-2 B)

Copy link

pkg-pr-new bot commented Aug 20, 2024

commit: 0034360

@vue/compiler-core

pnpm add https://pkg.pr.new/@vue/compiler-core@7265

@vue/compiler-dom

pnpm add https://pkg.pr.new/@vue/compiler-dom@7265

@vue/compiler-sfc

pnpm add https://pkg.pr.new/@vue/compiler-sfc@7265

@vue/compiler-ssr

pnpm add https://pkg.pr.new/@vue/compiler-ssr@7265

@vue/reactivity

pnpm add https://pkg.pr.new/@vue/reactivity@7265

@vue/runtime-core

pnpm add https://pkg.pr.new/@vue/runtime-core@7265

@vue/runtime-dom

pnpm add https://pkg.pr.new/@vue/runtime-dom@7265

@vue/server-renderer

pnpm add https://pkg.pr.new/@vue/server-renderer@7265

@vue/shared

pnpm add https://pkg.pr.new/@vue/shared@7265

vue

pnpm add https://pkg.pr.new/vue@7265

@vue/compat

pnpm add https://pkg.pr.new/@vue/compat@7265

Open in Stackblitz

@@ -115,6 +115,7 @@ export class EffectScope {

stop(fromParent?: boolean): void {
if (this._active) {
pauseTracking()
Copy link
Member

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()
      	  }
      	}
      }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs Review
Development

Successfully merging this pull request may close these issues.

Maximum recursive updates exceeded: when accessing a responsive variable in onScopeDispose
4 participants