chore(reactivity): effectScope.ts variable declarations optimized and remove useless code in effect.ts

[heggria]

This PR primarily modifies effectScope.ts, attempting to replace multiple let declarations within for loops with a single let declaration to enhance performance and maintain consistency with the stop function's style. Additionally, it removes redundant code from effect.ts.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	99 kB (-25 B)	37.5 kB (+1 B)	33.8 kB (+45 B)
vue.global.prod.js	157 kB (-25 B)	57.3 kB (+2 B)	51 kB (+47 B)

Usages

Name	Size	Gzip	Brotli
createApp	54.5 kB (-25 B)	21.1 kB (-1 B)	19.3 kB (-1 B)
createSSRApp	58.4 kB (-25 B)	22.8 kB (-3 B)	20.7 kB (-14 B)
defineCustomElement	59.1 kB (-25 B)	22.6 kB (-1 B)	20.6 kB (-5 B)
overall	68.1 kB (-25 B)	26.2 kB (-3 B)	23.8 kB (-47 B)

[pkg-pr-new]

commit: 5fd1a69

@vue/compiler-core

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

@vue/compiler-dom

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

@vue/compiler-sfc

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

@vue/compiler-ssr

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

@vue/reactivity

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

@vue/runtime-core

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

@vue/runtime-dom

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

@vue/server-renderer

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

@vue/shared

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

vue

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

@vue/compat

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

Open in Stackblitz

[heggria]

The decrease in batchDepth can be written in two ways. While the second method (--x) is simpler in terms of code, it doesn't quite match the coding style used elsewhere (where x-- is predominantly used). I'm not sure if it's worth making this change. I really appreciate the suggestion!

// type 1
batchDepth--
if (batchDepth > 0) {
  return
}

// type 2
if (--batchDepth > 0) {
  return
}

[edison1105]

@heggria
This change is incorrect. When batchDepth is 1, both type 1 and type 2 will early return. It's not consistent with the following logic.

  if (batchDepth > 1) {
    batchDepth--
    return
  }

  batchDepth--
  //...

[heggria]

@heggria This change is incorrect. When batchDepth is 1, both type 1 and type 2 will early return. It's not consistent with the following logic.

  if (batchDepth > 1) {
    batchDepth--
    return
  }

  batchDepth--
  //...

@edison1105 Thank you so much for your comment! However, after carefully examining and running the code, I reached the conclusion that the results are the same.

• In the original code, the operation batchDepth - 1 is executed regardless of which logic branch is taken. Here are the different scenarios:

  • When batchDepth === 2, batchDepth is greater than 1, so it becomes 1 and the function returns early.

  • When batchDepth === 1, batchDepth is not greater than 1, so it becomes 0 and the function continues.

  • When batchDepth === 0, batchDepth is not greater than 1, so it becomes -1 and the function continues.

• In both type 1 and type 2, the operation batchDepth - 1 is executed before any logic branch is taken. Here are the scenarios:

  • When batchDepth === 2, batchDepth becomes 1, which is greater than 0, and the function returns early.

  • When batchDepth === 1, batchDepth becomes 0, which is not greater than 0, and the function continues.

  • When batchDepth === 0, batchDepth becomes -1, which is not greater than 0, and the function continues.

Therefore, aside from the difference in timing between when batchDepth changes and when the function returns, I believe these two code implementations are equivalent. Since this is a synchronous function, there shouldn’t be any additional side effects.

Once again, thank you for taking the time to review my PR!

[edison1105]

uh... sorry, I think I got my thoughts mixed up just now. 😓
I prefer type 2 by the way.

[heggria]

uh... sorry, I think I got my thoughts mixed up just now. 😓 I prefer type 2 by the way.

No worries, it happens to all of us. 😊 The code is now using type 2. Thanks for your suggestion!